Sequências biológicas do UniProt no PostgreSQL

Qual é a melhor maneira de armazenar sequências biológicas UniProt no PostreSQL?

Detalhes dos dados

• Obtemos 12 milhões de sequências do UniProt - esse número provavelmente dobrará a cada 3-10 meses.
• O comprimento de uma sequência pode variar de 10 a 50 bilhões de caracteres
• Menos de 1% das sequências têm mais de 10 mil caracteres
  • Melhoraria o desempenho para armazenar seqüências mais longas separadamente?
• Uma sequência pode ser do alfabeto Protein ou DNA
  • O alfabeto de DNA possui 5 caracteres (A, T, C, G ou -).
  • O alfabeto de proteínas terá cerca de 30 caracteres.
  • Não nos importamos de armazenar as seqüências dos dois alfabetos diferentes em colunas diferentes ou mesmo em tabelas diferentes. Isso ajudaria?

Detalhes de acesso a dados

Para responder ao comentário de Jeremiah Peschka:

• As seqüências de proteínas e DNA seriam acessadas em diferentes momentos
• Não precisaria procurar na sequência (isso é feito fora do banco de dados)
• O éter acessaria linhas únicas por vez ou retiraria conjuntos de linhas por IDs. Não precisaríamos varrer linhas. Todas as seqüências são referenciadas por outras tabelas - existem várias hierarquias com significado biológico e cronológico no banco de dados.

Compatibilidade com versões anteriores

Seria bom poder continuar aplicando a seguinte função de hash (SEGUID - ID global identificador exclusivo global da sequência) às seqüências.

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;

Explorando as funções no PostBio , parece que elas têm algumas maneiras de codificação. No entanto, como essas extensões são otimizadas para pesquisa, elas fazem várias referências ao simples uso do texttipo de dados.

De acordo com a documentação :

Seqüências longas são compactadas pelo sistema automaticamente, portanto, o requisito físico no disco pode ser menor. Valores muito longos também são armazenados em tabelas em segundo plano para que não interfiram no acesso rápido a valores mais curtos da coluna. De qualquer forma, a cadeia de caracteres mais longa possível que pode ser armazenada é de aproximadamente 1 GB.

Portanto, colocar a tabela em seu próprio espaço de tabela muito grande em hardware dedicado deve ser suficiente para seus objetivos de desempenho. Se 1 GB for muito pequeno para seus dados, o int_interval do ProtBio deve fornecer um excelente desempenho:

Um recurso de sequência corresponde a um trigêmeo (id, orient, ii), em que id é um identificador de sequência (possivelmente a chave principal de uma tabela de sequências), orient é um booleano indicando se o recurso está na mesma orientação ou na orientação contrária da sequência, e ii é o int_interval representando o recurso como uma subsequência.

Codificar a sequência em sha1 parece ser uma maneira muito dolorosa de criar um GUID, considerando os possíveis comprimentos da sequência.

Se as diferentes seqüências não estiverem relacionadas, armazene-as em diferentes espaços de tabela em diferentes discos para obter o máximo desempenho.

Acho que 50 bilhões de caracteres provavelmente ultrapassarão os limites do que você pode fazer com o PostgreSQL sem dividir seus registros de alguma forma. Eu suspeito que você terá que encontrar uma maneira de separar as coisas de alguma maneira. Eu não sei que tipo de codificação postbio permite, mas ....

Cálculos rápidos aqui: 5 caracteres solicitam 3 bits para codificação, mas 4 bits tornarão a pesquisa mais fácil, pois dois caracteres podem ser codificados por byte. Por outro lado, 3 pode ser suficiente se você estiver procurando por grupos de 10 ou mais letras, já que é possível fazer 10 caracteres por 4 bytes. Otimizado para pesquisas com cadeias curtas, 50 bilhões de caracteres requerem aproximadamente 25 GB de armazenamento, muito além do que você pode fazer em uma única coluna. A compactação pode ajudar, mas é uma enorme escala de compactação necessária além da representação binária mínima não compactadapara descer para 1 GB. Otimizado para pesquisas mais longas, temos apenas 20 GB. então eu acho que mesmo se você tivesse tipos de informação genética, teria que terminar tudo. As proteínas nessa complexidade serão um desafio ainda maior, pois o melhor que você pode esperar é uma notação de 5 bits, o que significa que você tem 6 por 32, o que significa que o seu melhor argumento para armazenamento é de 30 GB por coluna. Portanto, a menos que você possa obter a compactação, pode ajudar novamente, mas é uma grande taxa de compactação necessária. Vi boas taxas de compactação, mas lembre-se de que você pode estar pressionando.

Portanto, minha recomendação é estar ciente desse problema e fazer alguns testes com dados reais. Esteja preparado para decompor suas leituras em alguns casos.