質問:
大規模なバリアントストアの状態、制限、および比較
agapow
2017-05-22 21:14:17 UTC
view on stackexchange narkive permalink

背景:多くの被験者に関連する多くのバリアントデータを保存する方法がますます必要になっています。臨床試験や入院患者を考えて、病気の原因となる遺伝子や関連する遺伝子を探してください。千の主題が私たちが始めるところです、地平線上に何百万もの話があります。さまざまなゲノム医学イニシアチブにより、これはより広いニーズになる可能性があります。

問題:プラットフォームはたくさんありますが、急速に進化している分野です。それらがどのように(そしてもし)どのように相互に整列するかを感じるのは難しいです:

  • スケーラブルで大量のデータを処理できるものは何ですか?どのような制限がありますか?
  • ハッキングされたコンポーネントの山ではなく、堅牢なものは何ですか?
  • 背後に大きなコミュニティがあり、実際に広く使用されているものは何ですか?
  • 他のサービスから簡単にアクセスして検索できる理由は何ですか? (コマンドライン、REST、またはソフトウェアAPI)
  • どのような種類のバリアントを処理しますか?
  • 検索にはどのような種類のパラメーターを使用できますか?

これまでに見た解決策:

  • BigQ:i2b2で使用されていますが、広く使用されているかどうかは不明です li>
  • OpenCGA:最も開発されているように見えますが、吐き出されるデータのサイズについて不満を聞いています
  • Google Genomics db:でBigQueryを使用することは一般的な解決策ではないようです
  • Gemini:推奨されますが、本当にスケーラブルで他のサービスからアクセスできますか?
  • SciDb:商用の一般的なデータベース
  • Quince
  • LOVD
  • アダム
  • DIVAS & RVDが実行されているプラ​​ットフォーム:無料で利用できない場合があります
  • いくつかのグラフィカル/グラフゲノムソリューション:私たち(および他のほとんどの人々)現時点ではおそらくグラフゲノムデータを扱っていませんが、これは可能な解決策ですか?
  • 独自の解決策:頻繁に推奨されますが、これが大規模なデータセットのもっともらしい解決策であるかどうかは疑問です。

経験のある人は、このプラットフォームスペースのレビューまたは高レベルのガイドを提供しますか?

私の2セント:単純なRESTフレームワークにラップされたMongoDBを使用します。柔軟なモデルとクエリを可能にし、単一ノード上の数十億のレコードに拡張する必要があります。現在、このためのFLOSSプロジェクトに取り組んでいますが、まだ本番環境に対応していません。
@woemler他のアプローチと比較してどうですか?私が知っている誰かが、5年前に1000gの遺伝子型でMongoDBを試しました。彼は、MongoDBは、はるかに大きなディスク/メモリフットプリントを持ちながら、並列クエリでbcf2よりも10倍以上遅いと述べました。そうは言っても、彼は当時MongoDBを初めて使用したため、最適な方法で実行していない可能性があります。
@user172818: MongoDBの新しいバージョン(3.2以降)は、数年前のバージョンよりも大幅に高速です。私は他の無料のRDBMSに対してベンチマークを行いましたが、特にバリアント呼び出しなどの複雑なデータ表現の場合は、通常、同等以上のパフォーマンスを発揮します。
ここではデータを保存することがより重要ですか、それともデータに関する統計を処理する(Python、Rなどを使用する)ことがより重要ですか?
@macgyver:良い観察。データ-おそらく人々は、要約統計量や分析を見るのではなく、データをマイニングしてクエリしたいと思うでしょう。
1 回答:
#1
+13
user172818
2017-05-23 03:13:53 UTC
view on stackexchange narkive permalink

壮大な質問。残念ながら、簡単な答えは次のとおりです。いいえ、広く使用されているソリューションはありません。

数千のサンプルの場合、VCFのバイナリ表現であるBCF2が適切に機能するはずです。この規模の新しいツールの必要性はないと思います。より大きなサンプルサイズの場合、ExACの人々は火花ベースの雹を使用しています。遺伝子型に加えて、すべてのサンプルごとの注釈(GL、GQ、DPなど)を保持します。雹は少なくとも実際には頻繁に使用されるものですが、これまでのところほとんどのグループで使用されています。

より単純な問題は、遺伝子型のみを保存することです。これは、大多数のエンドユーザーにとって十分です。遺伝子型を保存および照会するためのより良いアプローチがあります。 Geminiチームによって開発されたGQTは、サンプルの高速クエリを可能にします。これにより、特定の遺伝子型構成でサンプルをすばやくプルできます。私が覚えているように、GQTはPCAを実行するためにグーグルゲノミクスAPIよりも桁違いに高速です。別のツールはBGTです。それははるかに小さいファイルを生成し、サイト上で高速で便利なクエリを提供します。その論文は、約32kの全ゲノムサンプルについて述べています。私は、GQTやBGTのような特殊なバイナリ形式が、汎用データベース上に構築されたソリューションよりも高速であると信じているキャンプにいます。遺伝子型のみを照会したい場合は、ぜひご覧になることをお勧めします。

IntelのGenomicDBは、別の角度から問題に取り組んでいます。実際には、「二乗」マルチサンプルVCFを内部に保持しません。代わりに、サンプルごとの遺伝子型/注釈を保持し、マージされたVCFをその場で生成します(これは私の理解ですが、間違っている可能性があります)。私はGenomicDBを直接使用した経験はありませんが、この行の何かが100万サンプルの時代の究極のソリューションになるはずだと思います。 GATK4が何らかの段階でそれを使用していることを私は知っています。

あなたのリストの他の人に関しては、ジェミニはそれほどうまくスケーリングしないかもしれません、私は推測します。それが彼らがGQTに取り組んでいる理由の一部です。前回チェックしたとき、BigQueryは個々の遺伝子型をクエリしませんでした。サイトの統計のみを照会します。 GoogleゲノミクスAPIは個々の遺伝子型にアクセスしますが、パフォーマンスが高いとは思えません。アダムは試す価値があります。でも、試したことはありません。

雹の+1、明らかにこの時点での正解
BigQueryを使用して個々の遺伝子型をクエリできます。この時点での最大の課題は、分析を行うために独自のクエリを作成する必要があることです。


このQ&Aは英語から自動的に翻訳されました。オリジナルのコンテンツはstackexchangeで入手できます。これは、配布されているcc by-sa 3.0ライセンスに感謝します。
Loading...