6

多くのテキスト ファイルがあり、それらの合計サイズは約 300GB ～ 400GB です。それらはすべてこの形式です

key1 value_a
key1 value_b
key1 value_c
key2 value_d
key3 value_e
....

各行はキーと値で構成されています。キーのすべての値を照会できるデータベースを作成したいと考えています。たとえば、key1 をクエリすると、value_a、value_b、および value_c が返されます。

まず第一に、これらすべてのファイルをデータベースに挿入することは大きな問題です。LOAD DATA INFILE 構文を使用して、数 GB のサイズのチャンクを MySQL MyISAM テーブルに挿入しようとしています。しかし、MySQL はデータの挿入にマルチコアを利用できないようです。それは地獄のように遅いです。したがって、MySQL は、レコードが非常に多い場合には適していないと思います。

また、データベースを定期的、毎週、または可能であれば毎日更新または再作成する必要があるため、挿入速度が重要です。

単一のノードで計算と挿入を効率的に行うことはできません。効率的にするには、異なるノードで並列に挿入を実行する方がよいと思います。

例えば、

node1 -> compute and store 0-99999.txt
node2 -> compute and store 10000-199999.txt
node3 -> compute and store 20000-299999.txt
....

というわけで、最初の基準がこちら。

基準 1. 分散バッチ方式での挿入速度が速い。

次に、テキスト ファイルの例でわかるように、複数の同じキーを異なる値に指定することをお勧めします。例の key1 が value_a/value_b/value_c にマップされるように。

基準 2. 複数のキーが許可されている

次に、データベース内のキーをクエリする必要があります。リレーショナルまたは複雑な結合クエリは必要ありません。必要なのは単純なキーと値のクエリだけです。重要な部分は、複数のキーが同じ値になることです

基準 3. シンプルで高速なキー値クエリ。

HBase/Cassandra/MongoDB/Redis などがあることは知っていますが、それらすべてに精通しているわけではなく、どれが自分のニーズに合っているかわかりません。問題は、どのデータベースを使用するかということです。どれも私のニーズに合わない場合は、自分で作成することさえ計画していますが、それには努力が必要です:/

ありがとう。

4

6 に答える 6

3

あなたのニーズに合ったシステムがきっとたくさんあるはずです。あなたの要件は、いくつかの方法で物事を楽しく簡単にします。

  • クロスキー操作は必要ないため、複数のデータベースを使用して、ハッシュまたは範囲シャーディングを介してそれらの間でキーを分割できます。これは、MySQL で観察された並列処理の欠如を解決する簡単な方法であり、おそらく他の多くのデータベース システムでも観察されるでしょう。
  • オンライン更新を行うことはないため、不変データベースを一括で構築し、残りの日/週についてクエリを実行できます。この方法でより良いパフォーマンスが得られると思います。

ハッシュ分割された一連のLevelDBテーブルを構築する傾向があります。つまり、leveldb::DBオンラインで更新できるように、より複雑なデータ構造 (テーブルのスタックとログ) をサポートする actual は使用しません。代わりに、直接使用leveldb::Tableし、leveldb::TableBuilderオブジェクト (ログなし、特定のキーに対して 1 つのテーブルのみ)。これは、クエリを実行するための非常に効率的な形式です。また、例のように入力ファイルが既にソートされている場合、テーブルの構築も非常に効率的になります。シャードの数を増やすことで、必要な並列処理を実現できます。データベースの構築に 16 コア、16 ディスクのマシンを使用している場合は、少なくとも 16 個のシャードを使用し、すべて並列で生成されます。16 コア、16 ディスクのマシンを 16 台使用している場合、少なくとも 256 シャード。最近多くの人が行っているように、コアよりもディスクの数がはるかに少ない場合は、両方を試してみてください。注意すれば、基本的に、テーブルを構築している間にディスク スループットを最大化できると思います。キープレフィックスの圧縮 (およびオプションで Snappy ブロックの圧縮) により、テーブルが入力ファイルよりも著しく小さくなることが予想されます。通常、RAM にバッファリングできる比較的小さなインデックスは別として、leveldb テーブルのキーは、入力ファイルから読み取るのと同じ順序で格納されるため、シークはほとんど回避できます。並べ替えました。そうでない場合は、シャードを RAM で並べ替えてから書き出すことができるように、十分な数のシャードが必要になる場合があります。おそらく、シャードをより順次処理します。入力ファイルがすでにソートされていると再び仮定します。そうでない場合は、シャードを RAM で並べ替えてから書き出すことができるように、十分な数のシャードが必要になる場合があります。おそらく、シャードをより順次処理します。入力ファイルがすでにソートされていると再び仮定します。そうでない場合は、シャードを RAM で並べ替えてから書き出すことができるように、十分な数のシャードが必要になる場合があります。おそらく、シャードをより順次処理します。

于 2012-04-08T09:30:31.530 に答える
0

InfoBright はおそらく良い選択です。

于 2012-10-30T14:08:37.153 に答える
0

従来の答えは、大金を持っている場合は Oracle を使用し、そうでない場合は PostgreSQL を使用することです。ただし、非常に高速であることがわかった mongoDb などのソリューションも検討することをお勧めします。これは、スキーマが固定されておらず、データ全体で変更される可能性があるシナリオにも対応します。

于 2012-04-05T09:00:29.517 に答える
0

HBaseを見てください。列を使用して、キーに対して複数の値を格納できます。RDBMS とは異なり、各行に列のセットを固定する必要はありませんが、行に任意の数の列を含めることができます。キー (HBase 用語では行キー) でデータをクエリするため、その行のすべての列の値を読み取ることによって、特定のキーのすべての値を取得できます。

HBase は保持期間の概念も備えているため、どの列がどのくらい存続するかを決定できます。したがって、データは必要に応じて独自にクリーンアップできます。保持期間を利用するために人々が採用した興味深い手法がいくつかあります。

HBase は非常にスケーラブルで、非常に高速な読み取りと書き込みをサポートしています。

于 2012-07-30T18:01:31.863 に答える
0

すでに MySQL に精通しているため、新しいシステムに移行する前にすべての MySQL オプションを試すことをお勧めします。多くのビッグデータ システムは、非常に特定の問題に合わせて調整されていますが、RDBMS から当然と考えられている分野ではうまく機能しません。また、ほとんどのアプリケーションは、ビッグデータ機能とともに通常の RDBMS 機能を必要とします。そのため、新しいシステムに移行すると、新しい問題が発生する可能性があります。

また、選択したシステムで利用できるソフトウェア エコシステム、コミュニティ サポート、ナレッジ ベースも考慮してください。

ソリューションに戻ると、データベースには何行ありますか? これは重要な指標です。100万以上を想定しています。

パーティショニングを試してください。それは大いに役立ちます。選択基準が単純であり、結合を必要としないという事実は、物事をより良くするだけです.

Postgres には、パーティションをうまく処理する方法があります。起動して実行するにはより多くのコードが必要ですが、驚くほどの制御が可能です。MySQL とは異なり、Postgres にはパーティション数に厳密な制限がありません。Postgres のパーティションは通常のテーブルです。これにより、インデックス作成、検索、バックアップ、復元、並列データ アクセスなどをより詳細に制御できます。

于 2012-04-08T10:24:41.020 に答える