Secuencias biológicas de UniProt en PostgreSQL

¿Cuál es la mejor manera de almacenar secuencias biológicas UniProt en PostreSQL?

Detalles de datos

• Extraemos 12 millones de secuencias de UniProt ; es probable que este número se duplique cada 3-10 meses.
• La longitud de una secuencia puede variar de 10 a 50 mil millones de caracteres.
• Menos del 1% de las secuencias tienen más de 10 mil caracteres.
  • ¿Mejoraría el rendimiento para almacenar las secuencias más largas por separado?
• Una secuencia puede ser de proteína o de alfabeto de ADN
  • El alfabeto de ADN tiene 5 caracteres (A, T, C, G o -).
  • El alfabeto de proteínas tendrá alrededor de 30 caracteres.
  • No nos importa almacenar las secuencias de los dos alfabetos diferentes en columnas diferentes o incluso en tablas diferentes. ¿Eso ayudaría?

Detalles de acceso a datos

Para responder al comentario de Jeremiah Peschka:

• Se accedería a las secuencias de proteínas y ADN en diferentes momentos
• No necesitaría buscar dentro de la secuencia (eso se hace fuera de db)
• ¿Podía acceder Ether a filas individuales a la vez o extraer conjuntos de filas por ID? No necesitaríamos escanear filas. Todas las secuencias están referenciadas por otras tablas: existen varias jerarquías biológicamente y cronológicamente significativas en la base de datos.

Compatibilidad al revés

Sería bueno poder continuar aplicando la siguiente función de hash (SEGUID - IDENTIFICADOR DE SECUENCIA Globalmente Única) a las secuencias.

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;

Al explorar las funciones en PostBio , parece que tienen un par de formas de codificación. Sin embargo, dado que esas extensiones están optimizadas para la búsqueda, hacen múltiples referencias a simplemente usar el texttipo de datos.

De acuerdo con la documentación :

El sistema comprime las cadenas largas automáticamente, por lo que el requisito físico en el disco puede ser menor. Los valores muy largos también se almacenan en tablas de fondo para que no interfieran con el acceso rápido a valores de columna más cortos. En cualquier caso, la cadena de caracteres más larga posible que se puede almacenar es de aproximadamente 1 GB.

Por lo tanto, colocar la tabla en su propio espacio de tabla muy grande en hardware dedicado debería ser suficiente para sus objetivos de rendimiento. Si 1 GB es demasiado pequeño para sus datos, el int_interval de ProtBio debería proporcionar un rendimiento excelente:

Una característica de secuencia corresponde a un triplete (id, orient, ii) donde id es un identificador de secuencia (posiblemente la clave principal para una tabla de secuencia), orient es un booleano que indica si la característica está en la misma orientación o en sentido contrario de la secuencia, y ii es el int_interval que representa la característica como una subsecuencia.

Codificar la secuencia en sha1 parece ser una forma muy dolorosa de hacer un GUID, considerando las longitudes potenciales de la secuencia.

Si las diferentes secuencias no están relacionadas, almacénelas en diferentes espacios de tabla en diferentes discos para obtener el máximo rendimiento.

Creo que 50 mil millones de caracteres probablemente superarán los límites de lo que puede hacer con PostgreSQL sin dividir sus registros de alguna manera. Sospecho que tendrá que encontrar alguna manera de separar las cosas de alguna manera. No sé qué tipo de codificación permite Postbio pero ...

Cálculos rápidos aquí: 5 caracteres requieren 3 bits para codificar, pero 4 bits facilitarán la búsqueda ya que se pueden codificar dos caracteres por byte. Por otro lado, 3 puede ser suficiente si está buscando grupos de 10 o más letras, ya que podría hacer 10 caracteres por 4 bytes. Optimizado para búsquedas de cadenas cortas, 50 mil millones de caracteres ocupan aproximadamente 25 gb de almacenamiento, mucho más de lo que puede hacer en una sola columna. La compresión puede ayudar, pero esa es una gran escala de compresión requerida más allá de la mínima representación binaria sin comprimirpara bajar a 1GB. Optimizado para búsquedas más largas, obtenemos solo 20 GB. así que creo que incluso si tuvieras tipos de información genética, habrías roto las cosas. Las proteínas de esa complejidad serán un desafío aún mayor, ya que lo mejor que puede esperar es una notación de 5 bits, lo que significa que tiene 6 por 32, lo que significa que su mejor caso para el almacenamiento es de 30 GB por columna. Entonces, a menos que pueda obtener Compresión, puede ayudar nuevamente, pero se requiere una gran tasa de compresión. He visto buenas tasas de compresión, pero tenga en cuenta que puede estar presionando.

Por lo tanto, mi recomendación es tener en cuenta este problema y hacer algunas pruebas con datos reales. Ser parepared para descomponer sus lecturas en algunos casos.