PostgreSQL 中 UniProt 的生物序列

Ale*_*huk 11 postgresql

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

数据详情

  • 我们从UniProt 中提取了 1200 万个序列——这个数字可能每 3-10 个月翻一番。
  • 序列的长度可以从 10 到 500 亿个字符不等
  • 少于 1% 的序列长度超过 1 万个字符
    • 单独存储较长的序列会提高性能吗?
  • 序列可以是蛋白质或 DNA 字母表
    • DNA 字母表有 5 个字符(A、T、C、G 或 -)。
    • 蛋白质字母表将有大约 30 个字符。
    • 我们不介意将两个不同字母的序列存储在不同的列甚至不同的表中。那会有帮助吗?

数据访问详情

回答 Jeremiah Peschka 的评论:

  • 蛋白质和 DNA 序列将在不同时间访问
  • 不需要在序列内搜索(这是在 db 之外完成的)
  • 是一次访问单行还是按 ID 拉出多组行。我们不需要扫描行。所有序列都被其他表引用——数据库中存在几个具有生物学意义和按时间顺序排列的层次结构。

向后兼容

如果能够继续将以下散列函数(SEGUID - SEquence Globally Unique 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;
Run Code Online (Sandbox Code Playgroud)

Bri*_*ton 7

探索PostBio的功能,看起来它们有几种编码方式。但是,鉴于这些扩展已针对搜索进行了优化,因此它们会多次引用以简单地使用text数据类型。

根据文档

系统会自动压缩长字符串,因此对磁盘的物理要求可能会降低。很长的值也存储在后台表中,这样它们就不会干扰对较短列值的快速访问。在任何情况下,可以存储的最长字符串大约是 1 GB。

因此,将表放入专用硬件上自己的非常大的表空间应该足以满足您的性能目标。如果 1 GB 对于您的数据来说太小,ProtBio 的 int_interval 应该提供出色的性能:

序列特征对应于三元组 (id, orient, ii),其中 id 是序列标识符(可能是序列表的主键), orient 是一个布尔值,指示特征是在序列的相同方向还是相反方向, ii 是将特征表示为子序列的 int_interval。

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

如果不同的序列不相关,请将它们存储在不同磁盘上的不同表空间中以获得最大性能。