PostgreSQL中UniProt的生物学序列

在PostreSQL中存储UniProt生物序列的最佳方法是什么？

资料明细

• 我们从UniProt中提取了1200万个序列-这个数字很可能每3-10个月增加一倍。
• 序列的长度可以从10到500亿个字符不等
• 少于1％的序列超过1万个字符
  • 单独存储较长的序列是否会提高性能？
• 序列可以是蛋白质或DNA字母
  • DNA字母有5个字符（A，T，C，G或-）。
  • 蛋白质字母将包含大约30个字符。
  • 我们不介意将两个不同字母的序列存储在不同的列甚至不同的表中。有帮助吗？

数据访问详细信息

回答耶利米·佩斯卡的评论：

• 蛋白质和DNA序列将在不同时间访问
• 无需在序列中搜索（在db之外完成）
• 以太会同时访问单个行还是通过ID提取行集。我们不需要扫描行。所有序列都由其他表引用-数据库中存在几个在生物学和时间上有意义的层次结构。

向后兼容

能够继续将以下哈希函数（SEGUID-SEquence全局唯一IDentifier）应用于序列将是一个很好的选择。

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;

探索PostBio的功能，似乎它们有两种编码方式。但是，鉴于这些扩展已针对搜索进行了优化，因此它们可以简单地使用text数据类型进行多个引用。

根据文档：

长字符串由系统自动压缩，因此磁盘上的物理需求可能会更少。非常长的值也存储在后台表中，这样它们就不会干扰对较短列值的快速访问。在任何情况下，可以存储的最长字符串约为1 GB。

因此，通过在专用硬件上将表放入其自己的非常大的表空间中，对于您的性能目标应该足够了。如果1 GB的数据太小，则ProtBio的int_interval应该提供出色的性能：

序列特征对应于一个三元组（id，orient，ii），其中id是序列标识符（可能是序列表的主键），orient是一个布尔值，指示该特征是与序列的方向相同还是相反， ii是int_interval，将要素表示为子序列。

考虑到序列的潜在长度，在sha1中对序列进行编码看起来是制作GUID的一种非常痛苦的方式。

如果不同的序列无关，请将它们存储在不同磁盘上的不同表空间中，以实现最佳性能。

我认为500亿个字符可能会突破PostgreSQL的功能极限，而不会以某种方式拆分记录。我怀疑您将必须找到某种方法以某种方式分解事物。我不知道postbio允许哪种编码方式，但是...

快速计算：5个字符需要3位编码，但是4位将使搜索更加容易，因为每个字节可以编码2个字符。另一方面，如果您要搜索10个或更多字母的组，则3可能就足够了，因为您可以每4个字节输入10个字符。针对短字符串搜索进行了如此优化，500亿个字符占用了大约25gb的存储空间，远远超出了您在单列中可以完成的工作。压缩可能会有所帮助，但这是超出最小未压缩二进制表示形式所需的巨大压缩比例为了降到1GB。针对更长的搜索进行了优化，我们只有20GB。因此，我认为即使您拥有遗传信息类型，也可能会分手。具有如此复杂性的蛋白质将面临更大的挑战，因为您所希望的最好的结果是5位符号，这意味着您每32位中就有6位，这意味着您最好的存储空间是每列30GB。因此，除非您能获得压缩，否则它可能会再次有所帮助，但这是一个很大的压缩率。我已经看到了不错的压缩率，但是请记住，您可能会继续使用它。

因此，我的建议是意识到此问题，并使用真实数据进行一些测试。在某些情况下，可能会分解您的读数。