Biologische Sequenzen von UniProt in PostgreSQL

Was ist der beste Weg, um biologische UniProt-Sequenzen in PostreSQL zu speichern?

Datendetails

• Wir ziehen 12 Millionen Sequenzen von UniProt ein - diese Zahl wird sich wahrscheinlich alle 3-10 Monate verdoppeln.
• Die Länge einer Sequenz kann zwischen 10 und 50 Milliarden Zeichen variieren
• Weniger als 1% der Sequenzen sind länger als 10.000 Zeichen
  • Würde es die Leistung verbessern, die längeren Sequenzen separat zu speichern?
• Eine Sequenz kann entweder ein Protein- oder ein DNA-Alphabet sein
  • Das DNA-Alphabet besteht aus 5 Zeichen (A, T, C, G oder -).
  • Das Protein-Alphabet hat ungefähr 30 Zeichen.
  • Es macht uns nichts aus, die Sequenzen der beiden verschiedenen Alphabete in verschiedenen Spalten oder sogar verschiedenen Tabellen zu speichern. Würde das helfen?

Datenzugriffsdetails

Um den Kommentar von Jeremiah Peschka zu beantworten:

• Auf Protein- und DNA-Sequenzen würde zu unterschiedlichen Zeiten zugegriffen
• Müsste nicht innerhalb der Sequenz suchen (dies erfolgt außerhalb von db)
• Würde Äther auf einzelne Zeilen gleichzeitig zugreifen oder Sätze von Zeilen nach IDs herausziehen. Wir müssten keine Zeilen scannen. Alle Sequenzen werden von anderen Tabellen referenziert - in der Datenbank sind mehrere biologisch und chronologisch bedeutsame Hierarchien vorhanden.

Abwärtskompatibilität

Es wäre schön, weiterhin die folgende Hashing-Funktion (SEGUID - SEquence Globally Unique IDentifier) ​​auf die Sequenzen anwenden zu können .

CREATE OR REPLACE FUNCTION gfam.get_seguid(p_sequence character varying)
  RETURNS character varying AS
$BODY$
declare
  result varchar := null;
  x integer;
begin

  select encode(gfam.digest(p_sequence, 'sha1'), 'base64')
  into   result;

  x := length(result);
  if substring(result from x for 1) = '=' then

     result := substring( result from 1 for x-1 );

  end if;

  return result;

end;
$BODY$
  LANGUAGE 'plpgsql' VOLATILE
  COST 100;

Bei der Untersuchung der Funktionen bei PostBio gibt es anscheinend verschiedene Codierungsmöglichkeiten. Da diese Erweiterungen jedoch für die Suche optimiert sind, verweisen sie mehrfach auf die einfache Verwendung des textDatentyps.

Laut Dokumentation :

Lange Zeichenfolgen werden vom System automatisch komprimiert, sodass die physischen Anforderungen auf der Festplatte möglicherweise geringer sind. Sehr lange Werte werden auch in Hintergrundtabellen gespeichert, damit sie den schnellen Zugriff auf kürzere Spaltenwerte nicht beeinträchtigen. In jedem Fall beträgt die längste mögliche Zeichenfolge, die gespeichert werden kann, etwa 1 GB.

Daher sollte es für Ihre Leistungsziele ausreichen , die Tabelle in einen eigenen, sehr großen Tabellenbereich auf dedizierter Hardware zu stellen. Wenn 1 GB für Ihre Daten zu klein ist, sollte das int_interval von ProtBio eine hervorragende Leistung bieten:

Ein Sequenzmerkmal entspricht einem Triplett (id, orient, ii), wobei id eine Sequenzkennung ist (möglicherweise der Primärschlüssel für eine Sequenztabelle), orient ein Boolescher Wert ist, der angibt, ob sich das Merkmal in derselben oder einer entgegengesetzten Ausrichtung der Sequenz befindet. und ii ist das int_interval, das das Merkmal als Teilsequenz darstellt.

Das Codieren der Sequenz in sha1 scheint eine sehr schmerzhafte Methode zum Erstellen einer GUID zu sein, wenn man die möglichen Längen der Sequenz berücksichtigt.

Wenn die verschiedenen Sequenzen nicht miteinander zusammenhängen, speichern Sie sie für maximale Leistung in verschiedenen Tablespaces auf verschiedenen Festplatten.

Ich denke, 50 Milliarden Zeichen werden wahrscheinlich die Grenzen dessen überschreiten, was Sie mit PostgreSQL tun können, ohne Ihre Datensätze auf irgendeine Weise aufzuteilen. Ich vermute, Sie müssen einen Weg finden, um die Dinge auf irgendeine Weise auseinanderzubrechen. Ich weiß nicht, welche Art von Postbio-Codierung erlaubt, aber ...

Schnelle Berechnungen hier: 5 Zeichen erfordern 3 Bit zum Codieren, aber 4 Bit erleichtern die Suche, da zwei Zeichen pro Byte codiert werden können. Andererseits kann 3 ausreichend sein, wenn Sie nach Gruppen mit 10 oder mehr Buchstaben suchen, da Sie 10 Zeichen pro 4 Bytes ausführen können. 50 Milliarden Zeichen sind für die Suche nach kurzen Zeichenfolgen optimiert und benötigen ca. 25 GB Speicherplatz, weit über das hinaus, was Sie in einer einzelnen Spalte tun können. Komprimierung kann helfen, aber das ist eine enorme Komprimierungsskala, die über die minimale unkomprimierte Binärdarstellung hinaus erforderlich istum auf 1 GB zu kommen. Optimiert für längere Suchvorgänge erhalten wir nur 20 GB. Ich denke, selbst wenn Sie genetische Informationstypen hätten, hätten Sie die Dinge aufgebrochen. Proteine ​​mit dieser Komplexität werden eine noch größere Herausforderung sein, da das Beste, auf das Sie hoffen können, die 5-Bit-Notation ist, was bedeutet, dass Sie 6 pro 32 haben, was bedeutet, dass Ihr bester Fall für die Speicherung 30 GB pro Spalte beträgt. Wenn Sie also keine Komprimierung erhalten können, kann dies erneut hilfreich sein, es ist jedoch eine hohe Komprimierungsrate erforderlich. Ich habe gute Komprimierungsraten gesehen, aber denken Sie daran, dass Sie möglicherweise Druck machen.

Meine Empfehlung ist es, sich dieses Problems bewusst zu sein und einige Tests mit realen Daten durchzuführen. Seien Sie darauf vorbereitet, Ihre Messwerte in einigen Fällen zu zerlegen.