PostgreSQLにおけるUniProtの生物学的シーケンス

UniProtの生物学的シーケンスをPostreSQLに保存する最良の方法は何ですか？

データ詳細

• UniProtから1200万のシーケンスを取得します。この数は3〜10か月ごとに倍増する可能性があります。
• シーケンスの長さは100から500億文字までさまざまです
• シーケンスの1％未満が1万文字を超える
  • 長いシーケンスを個別に保存するとパフォーマンスが向上しますか？
• シーケンスは、タンパク質またはDNAアルファベットのいずれかです。
  • DNAアルファベットは5文字（A、T、C、G、または-）です。
  • プロテインアルファベットは約30文字です。
  • 2つの異なるアルファベットのシーケンスを別の列または別のテーブルに格納してもかまいません。それは役に立ちますか？

データアクセスの詳細

エレミヤ・ペシュカのコメントに答えるには：

• タンパク質とDNAシーケンスは異なる時間にアクセスされます
• シーケンス内を検索する必要はありません（それはdbの外で行われます）
• 一度に1つの行にアクセスするか、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;

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文字をエンコードできるため、検索が容易になります。一方、4バイトあたり10文字を実行できるため、10文字以上のグループを検索する場合は3で十分です。したがって、短い文字列検索用に最適化された500億文字は、約25 GBのストレージを使用します。これは、単一の列で実行できることをはるかに超えています。圧縮は役立つかもしれませんが、それは最小限の非圧縮バイナリ表現を超えて必要な巨大な圧縮スケールです1GBまで下げるために。長時間の検索用に最適化されており、20GBしか取得できません。ですから、たとえ遺伝情報の種類があったとしても、あなたは物事を壊していたと思います。その複雑さのタンパク質は、あなたが期待できる最高のものは5ビット表記であり、つまり32あたり6であることを意味するため、さらに困難になります。つまり、ストレージの最良のケースは列あたり30 GBです。そのため、圧縮を取得できない場合は、圧縮が再び役立つ可能性がありますが、それは必要な大きな圧縮率です。私は良い圧縮率を見てきましたが、あなたはそれを押しているかもしれないことを覚えておいてください。

したがって、私の推奨事項はこの問題を認識し、実際のデータを使用していくつかのテストを行うことです。場合によっては、測定値を分解する準備をしてください。