Séquences biologiques d'UniProt dans PostgreSQL

Quelle est la meilleure façon de stocker des séquences biologiques UniProt dans PostreSQL?

Détails des données

• Nous retirons 12 millions de séquences d' UniProt - ce nombre est susceptible de doubler tous les 3 à 10 mois.
• La longueur d'une séquence peut varier de 10 à 50 milliards de caractères
• Moins de 1% des séquences dépassent 10 000 caractères
  • Cela améliorerait-il les performances de stocker séparément les séquences plus longues?
• Une séquence peut être de l'alphabet protéine ou ADN
  • L'alphabet ADN comporte 5 caractères (A, T, C, G ou -).
  • L'alphabet des protéines aura environ 30 caractères.
  • Cela ne nous dérange pas de stocker les séquences des deux alphabets différents dans des colonnes différentes ou même des tableaux différents. Est-ce que cela aiderait?

Détails d'accès aux données

Pour répondre au commentaire de Jeremiah Peschka:

• Les séquences de protéines et d'ADN seraient accessibles à différents moments
• N'aurait pas besoin de rechercher dans la séquence (cela se fait en dehors de db)
• L'éther accèderait-il à des lignes uniques à la fois ou retirerait des ensembles de lignes par ID. Nous n'aurions pas besoin de scanner les lignes. Toutes les séquences sont référencées par d'autres tables - plusieurs hiérarchies biologiquement et chronologiquement significatives existent dans la base de données.

Rétrocompatibilité

Il serait intéressant de pouvoir continuer à appliquer la fonction de hachage suivante (SEGUID - SEquence Globally Unique IDentifier) ​​aux séquences.

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;

En explorant les fonctions de PostBio, il semble qu'elles aient deux manières de coder. Cependant, étant donné que ces extensions sont optimisées pour la recherche, elles font plusieurs références à la simple utilisation du texttype de données.

Selon la documentation :

Les longues chaînes sont compressées automatiquement par le système, de sorte que les exigences physiques sur le disque peuvent être moindres. Les valeurs très longues sont également stockées dans des tables d'arrière-plan afin qu'elles n'interfèrent pas avec un accès rapide à des valeurs de colonne plus courtes. Dans tous les cas, la chaîne de caractères la plus longue pouvant être stockée est d'environ 1 Go.

Par conséquent, en plaçant la table dans son propre très grand espace de table sur du matériel dédié, cela devrait suffire pour vos objectifs de performances. Si 1 Go est trop petit pour vos données, l'int_interval de ProtBio devrait fournir d'excellentes performances:

Une caractéristique de séquence correspond à un triplet (id, orient, ii) où id est un identifiant de séquence (éventuellement la clé primaire pour une table de séquence), orient est un booléen indiquant si la caractéristique est dans la même orientation ou une orientation contraire de la séquence, et ii est l'int_interval représentant la caractéristique en tant que sous-séquence.

Le codage de la séquence dans sha1 semble être un moyen très douloureux de créer un GUID, compte tenu des longueurs potentielles de la séquence.

Si les différentes séquences ne sont pas liées, stockez-les sur différents espaces de table sur différents disques pour des performances maximales.

Je pense que 50 milliards de caractères repousseront probablement les limites de ce que vous pouvez faire avec PostgreSQL sans diviser vos enregistrements d'une manière ou d'une autre. Je suppose que vous devrez trouver un moyen de séparer les choses d'une manière ou d'une autre. Je ne sais pas quel type d'encodage postbio permet mais ...

Calculs rapides ici: 5 caractères requièrent 3 bits pour encoder, mais 4 bits faciliteront la recherche car deux caractères peuvent être encodés par octet. D'un autre côté, 3 peut être suffisant si vous recherchez des groupes de 10 lettres ou plus, car vous pouvez faire 10 caractères par 4 octets. Ainsi optimisé pour les recherches de chaînes courtes, 50 milliards de caractères prennent environ 25 Go de stockage, bien au-delà de ce que vous pouvez faire dans une seule colonne. La compression peut aider, mais c'est une énorme échelle de compression requise au-delà de la représentation binaire minimale non compresséeafin de descendre à 1 Go. Optimisé pour des recherches plus longues, nous n'obtenons que 20 Go. donc je pense que même si vous aviez des types d'informations génétiques, vous auriez éclaté les choses. Les protéines à cette complexité seront encore plus difficiles car le meilleur que vous puissiez espérer est la notation 5 bits, ce qui signifie que vous en avez 6 pour 32, ce qui signifie que votre meilleur cas de stockage est de 30 Go par colonne. Donc, à moins que vous ne puissiez obtenir la compression, cela peut à nouveau aider, mais c'est un taux de compression élevé requis. J'ai vu de bons taux de compression, mais gardez à l'esprit que vous pouvez le pousser.

Ma recommandation est donc consciente de ce problème et effectue des tests avec des données réelles. Soyez prêt à décomposer vos lectures dans certains cas.