0

そのため、2 種類のインデックスを格納しようとしています。

  1. 第 1 の種類は、1 から 1000 の間の値を持ち、それぞれが 1 つまたは 2 つの 64 ビット整数である、10 億のオーダーになります。
  2. 2 番目の種類は数百万のオーダーで、それぞれ約 200 の値があり、各値のサイズは 1KB から 1MB です。

使用パターンは次のようになります。

  • どちらの種類のインデックスにも、1 秒あたり最大数千回まで値が追加されます。
  • インデックスはめったに読み込まれませんが、読み込まれるときはインデックス全体が読み込まれます
  • インデックスに値を書き込むとき、またはある種のバッチ タイプのジョブで、インデックスをプルーニングする必要があります。

これまでかなりの数のデータベースを検討してきましたが、現時点でのお気に入りは Cassandra と PostreSQL です。ただし、私たちのアプリケーションは Erlang にあり、Cassandra のプロダクション対応バインディングはありません。そして、大きな要件は、維持するために多くの人員を必要としないことです。Cassandra では予期しないスケーリングの問題が発生するのに対し、PostgreSQL では単にシャード処理が面倒になるような気がしますが、少なくとも私たちにとっては既知の量です。私たちはすでに PostgreSQL に精通していますが、Cassandra にはあまり詳しくありません。

そう。このユース ケースに最も適したデータ ストアに関する提案や推奨事項はありますか? 私はあらゆる提案を受け入れます！

ありがとう、

-アレック

4

2 に答える 2

2

インデックスの設計に関する回答の多くをサポートするのに十分な情報が提供されていません。ただし、Cassandra はクラスターを成長させることで非常に簡単にスケールアップします。

この記事を読むことをお勧めします: http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html

Cassandra にとってより重要な問題は、必要な種類のクエリをサポートしているかどうかです。スケーラビリティは問題ではありません。あなたが与えた数字からすると、テラバイトまたは数十テラバイトについて話しているように聞こえますが、これは Cassandra にとって非常に安全な領域です。

于 2012-02-03T00:23:56.080 に答える
2

数十億は、今日の基準では大きな数字ではありません。当て推量の代わりにベンチマークを書いてみませんか? これにより、より優れた意思決定ツールが得られ、非常に簡単に実行できます。ターゲットOSと各データベースエンジンをインストールしてから、たとえばPerlでクエリを実行するだけです（私はPerlが好きなので）これをすべて行うのに1日以上かかることはありません。ベンチマークを行う良い方法は、ランダムに、またはガウス ベル曲線のようなものを使用してクエリを実行し、実際の使用を「シミュレート」するスクリプトを作成することです。次に、データをプロットするか、ボスのように実行して、ログを読むだけです.

于 2012-02-02T20:28:18.673 に答える