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;
postgresql
Aleksandr Levchuk
fonte
fonte
Respostas:
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 :
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:
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.
fonte
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.
fonte