Sequenze biologiche di UniProt in PostgreSQL

Qual è il modo migliore per archiviare sequenze biologiche UniProt in PostreSQL?

Dettagli dei dati

• Prendiamo 12 milioni di sequenze da UniProt - questo numero probabilmente raddoppierà ogni 3-10 mesi.
• La lunghezza di una sequenza può variare da 10 a 50 miliardi di caratteri
• Meno dell'1% delle sequenze sono più lunghe di 10 mila caratteri
  • Migliorerebbe le prestazioni per memorizzare separatamente le sequenze più lunghe?
• Una sequenza può essere di alfabeto proteico o DNA
  • L'alfabeto DNA ha 5 caratteri (A, T, C, G o -).
  • L'alfabeto proteico avrà circa 30 caratteri.
  • Non ci importa di memorizzare le sequenze dei due diversi alfabeti in colonne diverse o persino in tabelle diverse. Sarebbe d'aiuto?

Dettagli di accesso ai dati

Per rispondere al commento di Geremia Peschka:

• Le sequenze di proteine ​​e DNA sarebbero accessibili in momenti diversi
• Non sarebbe necessario effettuare una ricerca all'interno della sequenza (eseguita al di fuori di db)
• Eterebbe l'accesso a singole file alla volta o estrarrebbe gruppi di righe per ID. Non avremmo bisogno di scansionare le righe. Tutte le sequenze sono referenziate da altre tabelle - esistono diverse gerarchie biologicamente e cronologicamente significative nel database.

Compatibilità con le versioni precedenti

Sarebbe bello poter continuare ad applicare le seguenti funzioni di hashing (SEGUID - SEquence Globally Unique IDentifier) ​​alle sequenze.

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;

Esplorando le funzioni di PostBio sembra che abbiano un paio di modi per codificare. Tuttavia, dato che tali estensioni sono ottimizzate per la ricerca, fanno più riferimenti semplicemente all'uso del texttipo di dati.

Secondo la documentazione :

Le stringhe lunghe vengono compresse automaticamente dal sistema, quindi i requisiti fisici sul disco potrebbero essere inferiori. I valori molto lunghi vengono anche memorizzati in tabelle di sfondo in modo che non interferiscano con un accesso rapido a valori di colonna più brevi. In ogni caso, la stringa di caratteri più lunga possibile che può essere memorizzata è di circa 1 GB.

Pertanto, inserendo la tabella nel proprio tablespace molto ampio su hardware dedicato dovrebbe essere sufficiente per i propri obiettivi di prestazione. Se 1 GB è troppo piccolo per i tuoi dati, int_interval di ProtBio dovrebbe fornire prestazioni eccellenti:

Una funzione di sequenza corrisponde a una tripletta (id, orient, ii) in cui id è un identificatore di sequenza (possibilmente la chiave primaria per una tabella di sequenza), orient è un valore booleano che indica se la funzione è nello stesso orientamento o contrario della sequenza, e ii è int_interval che rappresenta la funzione come sottosequenza.

La codifica della sequenza in sha1 sembra essere un modo molto doloroso di creare un GUID, considerando le lunghezze potenziali della sequenza.

Se le diverse sequenze non sono correlate, archiviarle su diversi tablespace su dischi diversi per ottenere le massime prestazioni.

Penso che 50 miliardi di personaggi probabilmente spingeranno i limiti di ciò che puoi fare con PostgreSQL senza dividere i tuoi record in qualche modo. Ho il sospetto che dovrai trovare un modo per spezzare le cose in qualche modo. Non so che tipo di codifica consenta Postbio ma ...

Calcoli rapidi qui: 5 caratteri richiedono 3 bit da codificare, ma 4 bit semplificheranno la ricerca poiché è possibile codificare due caratteri per byte. D'altra parte, 3 potrebbe essere sufficiente se stai cercando gruppi di 10 o più lettere poiché potresti fare 10 caratteri per 4 byte. Così ottimizzato per le ricerche di stringhe brevi, 50 miliardi di caratteri occupano circa 25 GB di spazio di archiviazione, ben oltre ciò che si può fare in una singola colonna. La compressione può aiutare, ma si tratta di un'enorme scala di compressione richiesta oltre alla minima rappresentazione binaria non compressaper scendere a 1 GB. Ottimizzato per ricerche più lunghe, otteniamo solo 20 GB. quindi penso che anche se tu avessi tipi di informazioni genetiche, avresti rotto le cose. Le proteine ​​con quella complessità saranno ancora più una sfida poiché il meglio che puoi sperare è la notazione a 5 bit, il che significa che ne hai 6 per 32, il che significa che il tuo caso migliore per la memorizzazione è di 30 GB per colonna. Quindi, a meno che tu non riesca a ottenere la compressione, può essere di nuovo utile, ma è richiesto un elevato tasso di compressione. Ho riscontrato buoni tassi di compressione, ma tieni presente che potresti spingerlo.

Quindi la mia raccomandazione è essere consapevoli di questo problema e fare alcuni test con dati reali. Preparati a scomporre le tue letture in alcuni casi.