5

私は生物学研究室で働いており、多くのDNAマイクロアレイ実験結果を保存するためにデータベースを設計する必要があります。

各実験は多くのマイクロアレイ（平均で約10個）で構成されており、各マイクロアレイには500万を超えるプローブが含まれています。各プローブは特定の遺伝子IDにマッピングされます。もちろん、同じプローブがすべての実験で同じgene_idに一致します。目的は、特定の実験で特定の遺伝子IDのプローブの強度値をすばやく取得できるようにするために、各マイクロアレイの強度値を保存することです。

実際、単純なmysqlテーブルで十分であり、次のようになります。

強度テーブル：| probe_id | Experiment_id | microarray_id | gene_id | intensity_value

（probe_id、experiment_id、microarray_id、gene_id）で構成される主キーを使用

ここに問題があります：各実験には500万以上のプローブを持つ多くのマイクロアレイがあります。1000回の実験で、平均して10個のマイクロアレイ（推定値は低く、数百個あるものもあります）、1000 * 10 * 5M=500億行。遅いと思います。そして、何十億行ものmysqlテーブルを処理する方法についてはまったくわかりません。それは可能ですか？任意のヒント ？

noSQLデータベースにも興味があります。私はカサンドラを使ったことがありませんが、それはこのタスクに最適だと私には思えます、私は正しいですか？私はこのようなシェマを想像することができます：

{
experiment_id_1:{ <- thats a super collumnFamilly ?
    gene_id_1:{ <- thats a collumnFamilly ?
        probe_id_1:{ value_microarray_1, value_microarray_2, ... }, <- thats a superCollumn ?
        probe_id_2:{ value_microarray_1, value_microarray_2, ... },
        probe_id_3:{ value_microarray_1, value_microarray_2, ... },
        ...
    },
    gene_id_2:{
        probe_id_1:{ value_microarray_1, value_microarray_2, ... },
        probe_id_2:{ value_microarray_1, value_microarray_2, ... },
        probe_id_3:{ value_microarray_1, value_microarray_2, ... },
        ...
    }
}
experiment_id_2{
    ...
}
...
}

私はリグスですか？それはカサンドラモデルに適合しますか？それは効率的でしょうか？noSQLの第一人者はどう思いますか:)

ありがとう。

4

6 に答える 6

2

このアプローチでは、NoSQL データベースを介したリレーショナルも検討します。いくつかの考慮事項を検討すると、データを処理できるかどうかを確認できます。

  1. テーブルの予想サイズとは何ですか。大まかなアイデアを得るには、1 セットのデータのサイズを確認し、それにデータセットの合計予想数を掛けて全体のサイズを計算します。
  2. インデックスのサイズを計算する
  3. サーバーがこれらのインデックスをRAMで処理できるか、またはそれ以上に処理できるかどうかを確認し、テーブル全体をRAMで処理します。
  4. このテーブルでの DML 操作と選択操作の比率は?
  5. これらの種類のテーブルのバックアップ、最適化、変更などの一般的なタスクをどのように処理するかについて、戦略を立てていることを確認してください。

そのような状況に対処する必要がある場合は、通常、テーブルにあると予想されるものと同様のテストデータを生成し、さまざまなサーバーパラメーターで遊んでいます。また、この場合、テーブルのパーティション化を使用することを検討します (たとえば、experiment_id でパーティション化します。これにより、テーブルが小さなサブセットに分割され、既存のハードウェア境界で対処できます。あえて自分でこれを作成しないでください。 、MySQL はこれを行うことができ、テーブルは単一のテーブルとしてユーザーに表示されます.しかし、マシンは、特定の experiment_id のデータセットが格納されている部分のみを処理する必要があります.これにより、I/O が大幅に高速化されます. .

予想をはるかに超える行数を持つテーブルを簡単に処理するマシンを見たことがありますが、そのようなセットアップを慎重に計画する必要があり、通常、本番環境に移行する前に多くのテスト/最適化/再設計が必要です. しかし、これは非常に興味深いことなので、常にこの努力をする価値があります。

(勉強中に embl データを扱っているときにこの分野での最初の経験があり、それが私の情熱になりました ;))

于 2012-04-05T15:02:37.567 に答える
1

MySQL または Postgres は問題なく機能する可能性があり、他の回答では、その方法に関するいくつかの良いヒントが得られます。しかし、あなたは具体的に Cassandra についても尋ねたので、私の考えは次のとおりです。

Cassandra はこれに適しています。実験/gene_id の組み合わせのすべての強度値を効率的に検索できるようにしたい場合は、思いついたものとは少し異なるものをお勧めします。のような複合キーを使用し(<experiment_id>, <gene_id>)(単純にする場合は単に文字列のよう"<experiment_id>:<gene_id>"に)、この行の強度値ごとに 1 つの列を使用します。これにより、必要なすべての強度値を非常に効率的に取得できます。通常、コールド ルックアップのために 1 つまたは 2 つのディスク シークが行われます。

于 2012-04-06T02:09:48.330 に答える
1

このことを考慮：

列 (probe_id、gene_id、array_of_values) を持つ各実験のテーブルを用意します。私があなたを正しく理解していれば、主キーはprobe_idにあります（ただし、この列を照会しないと、主キーを持たない可能性があります）。また、gene_id のインデックスが必要です。

したがって、それぞれ管理可能な 5M 行の 1000 個のテーブルがあります。良いか悪いか？これはあなたのクエリ パターンに適合しますか? このスキームの優れた特性は、古いデータを簡単に削除できることです。

ところで、mysql の代わりに postgresql を検討すると、ネイティブの配列型があります。それ以外の場合は、配列をシリアル化する効率的な方法を考え出す必要があります。

とにかく、これは簡単にテストできるはずです。

于 2012-04-05T14:39:41.793 に答える
1

RDBMS は、そのボリュームでまったく詰まることがあってはなりません。データは十分に構造化されており、リレーションに入れるのに十分な意味があります。

ストレージに応じた MySQL でこれを処理できます。ストレージ管理の立場から、テーブルを別々のテーブルに分割することをお勧めします。

関連データベース内の行数が多すぎますか?

于 2012-04-05T14:53:21.733 に答える
0

多分私は何かが欠けているかもしれませんが、あなたは次のように聞こえるシステムを持っています:

  • 同種: データベース内のすべてのエントリには、実験 ID、遺伝子 ID、プローブ ID、値セレクタ ID (マイクロアレイのどの要素であるか)、および値があります。
  • write-once, read-many: 情報を記録し、一度記録すると二度と変更したくありません。

これは、NoSQL データベースよりもリレーショナル データベース (MySQL または PostreSQL) に適しているように思えます。NoSQL データベースは、異種データベースの処理に優れています。

于 2012-04-05T13:59:44.123 に答える