Ich plane, Scans von einem Massenspektrometer in einer MySQL-Datenbank zu speichern und möchte wissen, ob das Speichern und Analysieren dieser Datenmenge aus der Ferne möglich ist. Ich weiß, dass die Leistung je nach Umgebung sehr unterschiedlich ist, aber ich suche nach der ungefähren Größenordnung: Dauern Abfragen 5 Tage oder 5 Millisekunden?
Eingabeformat
Jede Eingabedatei enthält einen einzelnen Lauf des Spektrometers. Jeder Lauf besteht aus einer Reihe von Scans, und jeder Scan enthält eine geordnete Reihe von Datenpunkten. Es gibt einige Metadaten, aber der größte Teil der Datei besteht aus 32- oder 64-Bit-Arrays (Ints oder Floats).
Host-System
| ---------------- + ------------------------------- | | OS | Windows 2008 64-Bit | | MySQL-Version | 5.5.24 (x86_64) | | CPU | 2x Xeon E5420 (insgesamt 8 Kerne) | | RAM | 8 GB | | SSD-Dateisystem | 500 GiB | | HDD RAID | 12 TiB | | ---------------- + ------------------------------- |
Auf dem Server werden einige andere Dienste ausgeführt, deren Prozessorzeit vernachlässigbar ist.
Dateistatistik
| ------------------ + -------------- | | Anzahl der Dateien | ~ 16.000 | | Gesamtgröße | 1,3 TiB | | Mindestgröße | 0 Bytes | | max größe | 12 GiB | | meine | 800 MiB | | Median | 500 MiB | | Gesamtdatenpunkte | ~ 200 Milliarden | | ------------------ + -------------- |
Die Gesamtzahl der Datenpunkte ist eine sehr grobe Schätzung.
Vorgeschlagenes Schema
Ich habe vor, die Dinge "richtig" zu machen (dh die Daten wie verrückt zu normalisieren) und hätte dann eine runs
Tabelle, eine spectra
Tabelle mit einem Fremdschlüssel für runs
und eine datapoints
Tabelle mit einem Fremdschlüssel für spectra
.
Die 200-Milliarden-Datenpunkt-Frage
Ich werde mehrere Spektren und möglicherweise sogar mehrere Läufe analysieren, was zu Abfragen führt, die Millionen von Zeilen berühren könnten. Angenommen, ich indiziere alles richtig (was ein Thema für eine andere Frage ist) und versuche nicht, Hunderte von MiB über das Netzwerk zu mischen, ist es für MySQL aus der Ferne plausibel, damit umzugehen?
zusätzliche Information
Die Scandaten stammen aus Dateien im XML-basierten
mzML- Format. Das Fleisch dieses Formats befindet sich in den
<binaryDataArrayList>
Elementen, in denen die Daten gespeichert sind. Jeder Scan erzeugt> = 2 <binaryDataArray>
Elemente, die zusammen ein zweidimensionales (oder mehr) Array des Formulars bilden [[123.456, 234.567, ...], ...]
.
Diese Daten sind einmal beschreibbar, sodass die Aktualisierungsleistung und die Transaktionssicherheit keine Bedenken darstellen.
Mein naiver Plan für ein Datenbankschema lautet:
runs
Tabelle
| Spaltenname | Typ | | ------------- + ------------- | | id | PRIMÄRSCHLÜSSEL | | start_time | TIMESTAMP | | name | VARCHAR | | ------------- + ------------- |
spectra
Tabelle
| Spaltenname | Typ | | ---------------- + ------------- | | id | PRIMÄRSCHLÜSSEL | | name | VARCHAR | | index | INT | | spectrum_type | INT | | Darstellung | INT | | run_id | AUSLÄNDISCHER SCHLÜSSEL | | ---------------- + ------------- |
datapoints
Tabelle
| Spaltenname | Typ | | ------------- + ------------- | | id | PRIMÄRSCHLÜSSEL | | spectrum_id | AUSLÄNDISCHER SCHLÜSSEL | | mz | DOPPELT | | num_counts | DOPPELT | | index | INT | | ------------- + ------------- |
Ist das vernünftig?
Wie Sie vielleicht schlussfolgern konnten, bin ich der Programmierer, nicht der Biologe im Labor, also kenne ich die Wissenschaft nicht annähernd so gut wie die tatsächlichen Wissenschaftler.
Hier ist eine Darstellung eines einzelnen Spektrums (Scan) der Art von Daten, mit denen ich mich befassen werde:
Ziel der Software ist es herauszufinden, wo und wie bedeutend die Peaks sind. Wir verwenden ein proprietäres Softwarepaket, um dies herauszufinden, aber wir möchten unser eigenes Analyseprogramm (in R) schreiben, damit wir wissen, was zum Teufel unter den Laken vor sich geht. Wie Sie sehen, ist die überwiegende Mehrheit der Daten uninteressant, aber wir möchten keine potenziell nützlichen Daten löschen, die unser Algorithmus übersehen hat. Sobald wir eine Liste wahrscheinlicher Peaks haben, mit denen wir zufrieden sind, wird der Rest der Pipeline diese Peak-Liste anstelle der unformatierten Liste von Datenpunkten verwenden. Ich nehme an, dass es ausreichend wäre, die Rohdatenpunkte als großen Blob zu speichern, damit sie bei Bedarf erneut analysiert werden können, aber nur die Peaks als eindeutige Datenbankeinträge behalten. In diesem Fall würde es nur ein paar Dutzend Peaks pro Spektrum geben.