Es scheint eine Menge Redundanz in PDB-Dateien zu geben. Diese Dateien können natürlich mit Allzweck-Komprimierungsprogrammen wie gzip komprimiert werden, aber ich kann nicht umhin, mir vorzustellen, dass diese Tools eine erhebliche Menge an Redundanz in PDB-Dateien übersehen. Gibt es Kompressoren, die speziell auf PDB-Dateien abzielen? Wenn nicht, was sind einige Aspekte von PDB-Dateien, die für eine Komprimierung geeignet sind?
Betrachtet man eine typische PDB-Datei, fallen sofort einige Redundanzen auf. Andere Redundanzen sind weniger offensichtlich. Betrachten Sie diesen Auszug aus zwei Resten von 1MOB (Myoglobin):
ATOM 332 N LYS A 42 16.481 27.122 -10.033 1.00 11.15 N
ATOM 333 CA LYS A 42 15.926 28.134 -9.159 1.00 8.64 C
ATOM 334 C LYS A 42 16.970 29.081 -8.512 1.00 16.74 C
ATOM 335 O LYS A 42 16.687 30.075 -7.799 1.00 11.84 O
ATOM 336 CB LYS A 42 15.093 27.489 -8.043 1.00 18.03 C
ATOM 337 CG LYS A 42 13.731 26.888 -8.502 1.00 19.65 C
ATOM 338 CD LYS A 42 12.679 27.912 -8.953 1.00 17.94 C
ATOM 339 CE LYS A 42 11.438 27.406 -9.703 1.00 24.82 C
ATOM 340 NZ LYS A 42 10.474 28.567 -9.803 1.00 19.81 N
ATOM 341 N PHE A 43 18.218 28.599 -8.544 1.00 12.28 N
ATOM 342 CA PHE A 43 19.311 29.318 -7.919 1.00 11.81 C
ATOM 343 C PHE A 43 20.223 30.024 -8.949 1.00 10.95 C
ATOM 344 O PHE A 43 21.201 29.462 -9.450 1.00 10.08 O
ATOM 345 CB PHE A 43 20.138 28.301 -7.137 1.00 9.30 C
ATOM 346 CG PHE A 43 19.494 27.689 -5.877 1.00 9.53 C
ATOM 347 CD1 PHE A 43 19.572 28.376 -4.679 1.00 12.01 C
ATOM 348 CD2 PHE A 43 18.837 26.465 -5.923 1.00 10.54 C
ATOM 349 CE1 PHE A 43 18.993 27.861 -3.536 1.00 9.59 C
ATOM 350 CE2 PHE A 43 18.261 25.959 -4.775 1.00 8.62 C
ATOM 351 CZ PHE A 43 18.341 26.666 -3.597 1.00 7.89 C
Diese beiden Reste belegen als Klartext 1.638 Bytes; Wenn sie mit gzip komprimiert werden, belegen sie 467 Bytes. Als Referenz wird das Format von ATOM-Datensätzen in PDB-Dateien unter wwpdb.org/documentation/format33/sect9.html#ATOM definiert.
Fast alle Daten im obigen Auszug erscheinen redundant. Es erscheinen das erste Feld (ATOM), zweites Feld (Atomindex, zB 332 in der ersten Zeile), sechstes Feld (Restindex, zB 42), zehntes Feld (Belegung, zB 1.00) und letztes Feld (Elementname, zB N). eindeutig fremd. Das vierte Feld (Restname) könnte von drei Zeichen auf 1 Zeichen oder einfach auf eine ganze Zahl gekürzt werden. Ich bin kein Experte für Datenkomprimierung, aber ich kann mir vorstellen, dass gzip den größten Teil dieser Redundanz aufnimmt.
Etwas weniger offensichtlich scheinen auch die Atomnamen für jeden Rest unnötig zu sein. Nach meinem Verständnis ist die atomare Zusammensetzung der Rückgrate aller Reste immer gleich und wird in PDB-Dateien als "N", "CA", "C", "O" dargestellt. Dasselbe gilt für die atomare Zusammensetzung der jeweiligen Seitenketten der Reste: Eine Lysin-Seitenkette ist immer "CB", "CG", "CD", "CE", "NZ" und eine Phenylalanin-Seitenkette ist immer "CB", " CG", "CD1", "CD2", "CE1", "CE2", "CZ".
Eine subtilere Redundanz, die jedoch die Komprimierbarkeit erheblich erhöhen könnte, scheint in den Atomkoordinaten selbst zu liegen. Wäre es beispielsweise im Rückgrat möglich, die X-, Y- und Z-Koordinaten jedes Restatoms (12 Datenpunkte: 4 Atome * 3 Koordinaten) abzuleiten, wenn nur ihre Phi-, Psi- und Omega - Diederwinkel (3 Datenpunkte) gegeben sind? Könnte das Anwenden von Diederwinkeln auf Atome in Seitenketten in ähnlicher Weise die Notwendigkeit beseitigen, die 3D-Koordinaten dort explizit aufzulisten?
Könnte "Temperaturfaktor" (das vorletzte Feld im Auszug) verlustfrei entfernt oder auf nicht offensichtliche Weise komprimiert werden? Was sind einige andere mögliche Optimierungen, die verwendet werden könnten, um PDB-Dateien effizienter zu komprimieren? Gibt es offensichtlich schwerwiegende Auswirkungen dieser verschiedenen Komprimierungstechniken auf die Geschwindigkeit eines hypothetischen Dekomprimierers, um zurück in das offizielle PDB-Format zu konvertieren? Wurden diese Fragen in der Literatur oder einem bestehenden PDB-spezifischen Komprimierungsprogramm beantwortet?
Vielen Dank im Voraus für Antworten oder Feedback.
Bearbeiten :
Angesichts der Tatsache, dass anscheinend keine PDB-spezifischen Dateikomprimierer verfügbar sind, nehme ich an, dass mein spezifisches Ziel darin besteht, einen zu entwickeln. Eine mögliche Anwendung, die ich dafür sehe, ist die signifikante Verkürzung der Fresh Times-to-Rendering in bestimmten Anwendungsfällen browserbasierter molekularer Visualisierungsprogramme, z. B. Jmol , ChemDoodle Web Components oder GLmol . Eine andere Anwendung könnte die Zeit und die Größe der Daten verringern, die zum Herunterladen von Archiven von PDB-Dateien wie den hier beschriebenen erforderlich sind .
Dies würde natürlich eine Möglichkeit erfordern, die gepackten PDB-Dateien effizient zu dekomprimieren, aber dieser Kompromiss zwischen Dekomprimierungszeit und Downloadzeit scheint zumindest in einigen Nischenanwendungen nützlich zu sein.
Bearbeiten 2 :
In einem Kommentar fragt Nico: „Wie würde das Komprimieren der Datei die Renderzeit verringern?“. Das Verringern der gzippten PDB-Dateigröße (z. B. um die Hälfte oder mehr) und damit das Verringern der zum Herunterladen der Datei erforderlichen Zeit würde die Zeit zwischen dem Anfordern der PDB-Datei von einem Remote-Server und dem Rendern der Struktur durch ein molekulares Visualisierungsprogramm, das auf einem ausgeführt wird, verkürzen Client-Maschine. Bitte entschuldigen Sie, wenn die Verwendung von „Fresh Time-to-Rendering“ in diesem Zusammenhang unklar war.
Eine verlustfreie Komprimierung könnte auch das Kodieren der PDB-Datei in ein Objekt (z. B. JSON) umfassen, das für das Visualisierungsprogramm schneller zu analysieren ist, und auf diese Weise die Renderzeiten verkürzen. Wenn Sie sich weiter umsehen, wenn die Anwendung nur die Anzeige der 3D-Struktur erfordert und nicht auch Daten über bestimmte Atome und Reste speichert, dann scheint die Verwendung einer Binärnetzkomprimierung (z. B. webgl-loader ) die Zeit zum Rendern wahrscheinlich noch weiter zu verkürzen.
Sie treffen einige Annahmen, die wahrscheinlich nicht für alle PDB-Dateien gelten. Zum Beispiel:
Der Temperaturfaktor ist ein experimentell ermittelter Wert, dafür gibt es keine offensichtliche Kompression. Sie können es getrost verwerfen, wenn Sie diese Daten nicht benötigen, und zB hat es in NMR-Strukturen ohnehin keine Bedeutung.
Der Vorteil des PDB-Formats ist, dass so ziemlich jedes Programm (theoretisch) damit umgehen kann, obwohl die Implementierungen variieren und subtile Inkompatibilitäten eine Menge Kopfschmerzen verursachen können. Die Größe von PDB-Dateien ist fast nie ein Problem, daher gibt es keine nennenswerte Motivation, das Format in dieser Hinsicht zu verbessern.
Das PDB-Dateiformat wurde in den Anfängen der Computertechnik so spezifiziert, dass es auf Lochkarten passt. Es hat also einige Mängel, die dazu geführt haben, dass Generationen von Wissenschaftlern das Spaltenformat mit fester Breite verflucht haben. Inzwischen wurde es von einem XML-ähnlichen Format abgelöst: PDBML. Natürlich ist XML weniger platzsparend als ein Spaltenlayout, sodass Sie sehen können, dass der Speicherplatz nicht das Hauptanliegen war, sondern die Möglichkeit, die Dateien zu analysieren. Nichtsdestotrotz gibt die PDBML-Seite an, dass sie drei Arten von Download-Dateien anbieten: „vollständig markierte Dateien, Dateien ohne Atom-Datensätze, Dateien mit einer platzsparenderen Codierung von Atom-Datensätzen“ – Sie können also überprüfen, was sie in letzterem tun Fall.
Was Ihre Vorschläge betrifft: Theoretisch könnten Sie nur Diederwinkel verwenden. Die numerischen Fehler würden sich jedoch ansammeln, wenn Sie die 3D-Koordinaten rekonstruieren, und unterschiedliche Softwarearchitekturen geben Ihnen unterschiedliche Genauigkeit. Also: Explizit ist besser als implizit in wissenschaftlichen Dateiformaten.
Ich greife eine alte Frage wieder auf, aber ich habe diese Frage von ein paar jungen Bioinformatikern gehört und musste noch ein paar Punkte zum Komprimieren von PDB-Dateien berücksichtigen.
Der erste ist, dass viele PDB-Dateien (einschließlich aller auf der PDB-Site gehosteten PDBs) etwa 300-400 Zeilen mit Metadaten am Anfang der Datei haben. Dies macht etwa 10-20 % der gesamten Dateigröße aus. Auch viele PDBs haben ANISOU-Datensätze, aber sie sind ungefähr so redundant.
Zweitens, selbst wenn Sie es mit rohen Koordinatendaten zu tun haben, unterschätzen Sie meiner Meinung nach, wie gut GZIP bereits funktioniert. Sagen wir einfach, die Hälfte dieser Spaltendaten ist irgendwie völlig redundant und wir können sie einfach alle wegkomprimieren. Als nächstes codieren wir die 5 Zahlen (x, y, z, q, b) binär mit 2 Bytes für jede Zahl (was nicht einmal genug Platz für die praktische Verwendung ist, aber wir sind hier optimistisch). Wir haben also 80 Spalten auf 10 Spalten komprimiert, was 12,5 % der ursprünglichen Größe entspricht. Wenn Sie gzip auf ein paar einfachen PDBs ausführen (nachdem Sie nur die ATOM-Datensätze ausgelesen haben), erreicht es 23,0% der ursprünglichen Größe. Wenn uns die Dateigröße wirklich wichtig wäre, könnten wir bzip2 verwenden, das 16,4 % erreicht.
Unser magisches Komprimierungstool ist nur doppelt so gut wie gzip, was schön ist, aber gzip ist bereits viermal besser als unkomprimierte pdbs. Wenn wir uns genug Sorgen machen würden, würden wir einfach bzip2 verwenden, das nur 30 % größer ist als diese hypothetische Mindestgröße. Und sobald wir alle Atomspezifikationen wieder da drin haben, bin ich sicher, dass sie praktisch identisch sind. Unter dem Strich ist bzip2 für viele Dateitypen, insbesondere Textdateien, bereits sehr nahe an der maximalen theoretischen Komprimierungsgrenze. Für Genomsequenzierungsdaten, die um Größenordnungen größer und redundanter sind, haben die Leute nur geringfügige Änderungen am zugrunde liegenden Algorithmus vorgenommen.
Ich habe die gesamte PDB-Datenbank heruntergeladen und analysiert (etwas veraltet, aber sie umfasst 75 KB Strukturen und 14 GB, gzip-komprimiert) und weiß es zu schätzen, dass ich sie weiter verkleinern möchte, glauben Sie mir. Auf dieser Ebene macht die Komprimierung einen Unterschied in der Analysezeit, indem nur Daten von der Festplatte (oder einem NFS-Server) gelesen werden. Glücklicherweise lesen viele (wenn nicht die meisten) pdb-Tools gzip-verpackte pdbs nativ (leider nicht der Fall für bzip-verpackte Dateien). Perl, Python und jede andere wichtige Bioinformatiksprache haben einfache APIs zum automatischen Dekomprimieren von gzip-Dateien, wenn sie geöffnet werden. Gegen die Allgegenwart von gzip lohnt es sich nicht wirklich, über eine kleine Verbesserung der Komprimierung nachzudenken. Auch hier würden wir, wenn es uns wichtig wäre, stattdessen einfach alles verwenden, um bzip2 zu verwenden.
Die Zukunft ist eher wie PDBML, was ich irgendwie verachte. Aber es ist viel vollständiger und einfacher zu parsen (da es XML-Parser für alle wichtigen Sprachen gibt), selbst wenn die Dateien selbst um eine Größenordnung größer sind. Ich mag sie nicht (und meistens XML im Allgemeinen), weil sie in praktischer Hinsicht nicht für Menschen lesbar sind. Aber gleichzeitig schlage ich nicht vor, dass wir einfach zu einem 120-Spalten-PDB-Format wechseln, nur um die Einschränkungen des PDB-Formats zu beseitigen.
Es würde auch niemals funktionieren, nur Diederwinkel zu verwenden, und nicht wegen der numerischen Genauigkeit. Es gibt eine kleine, aber signifikante Abweichung in den Bindungslängen und -winkeln, die dazu führen würde, dass die Koordinaten am Ende der Kette um Angström abweichen. Es würde bei ANISOU, REMARK und anderen Platten nicht helfen. Und es wäre ehrlich gesagt ein großer Schmerz, dafür neue Parser zu schreiben.
Ich weiß, die Frage ist alt, aber fürs Protokoll: Die RCSB PDB arbeitet derzeit an einem Projekt, um die PDB-Strukturdaten mit einem neuen Dateiformat namens MMTF (MacroMolecular Transmission Format) zu komprimieren.
Das Format verwendet MessagePack für die Serialisierung und führt eine benutzerdefinierte Komprimierung durch, wodurch ein ~ 5-facher Vorteil gegenüber gzippten mmCIF-Dateien erreicht wird. Derzeit passt das gesamte PDB-Archiv in 7 GB. Am wichtigsten ist, dass die Parsing-Zeit dank des binären Formats drastisch reduziert wird.
Sie können alles darüber auf der Website lesen: http://mmtf.rcsb.org
Verrückter Wissenschaftler
Niko
gkadam
jqp
Marcin