44

読み取り/書き込みが集中するアプリケーション向けに、フェイルオーバー クラスタリングを使用したドキュメント データベース ストレージ ソリューションを検討しています。

1 秒あたり平均 40K の同時書き込みがデータベースに書き込まれます (ピーク時には 70,000 に達する可能性があります)。ほぼ同様の数の読み取りが発生する可能性があります。

また、データベースが新しく書き込まれたレコードについて通知するためのメカニズムも必要です (データベース レベルでの何らかのトリガー)。

ドキュメント データベースの適切な選択と関連するキャパシティ プランニングに関して、どのオプションが適切でしょうか?

更新しました

期待の詳細。

  • 平均して、3 ～ 4 のデータベース/ドキュメント コレクション全体で 1 秒あたり 40,000 (40K) の挿入 (新しいドキュメント) の数が予想されます。
  • ピークは 120,000 (120K) の挿入に達する可能性があります
  • インサートはすぐに読めるようになるはずです - ほぼリアルタイム
  • これに加えて、1 秒あたり約 5000 の更新または削除が予想されます
  • これに加えて、データにアクセスする 500 ～ 600 の同時クエリも予想されます。これらのクエリと実行計画はある程度わかっていますが、たとえば週に 1 回程度更新する必要があるかもしれません。
  • システムは、ストレージ側でフェールオーバー クラスタリングをサポートする必要があります
4

4 に答える 4

8

「20,000回の同時書き込み」が挿入を意味する場合、CouchDBに行き、トリガーに「_changes」APIを使用します。しかし、20,000 回の書き込みでは、安定したシャーディングも必要になります。次に、bigcouchを確認することをお勧めします。

そして、「20.000」の同時書き込みが「ほとんど」の更新で構成されている場合、その「適切な更新」は非常に素晴らしいので、MongoDB を使用することは間違いありません。ただし、トリガーを手動で処理する必要がありますが、別のコレクションを使用して一般的なドキュメントを更新することは、便利な解決策になる可能性があります。ここでも、シャーディングに注意してください。

最後に、並行性だけでデータベースを選択することはできないと思います。API (データを取得する方法) を計画してから、オプションを検討する必要があります。

于 2011-03-10T14:11:21.740 に答える
6

MongoDB をお勧めします。私の要件はあなたの要件ほど高くはありませんでしたが、かなり近いものでした。C# を使用すると仮定すると、公式の MongoDB C# ドライバーと SafeMode をオンにしたInsertBatchメソッドをお勧めします。文字通り、ファイル システムが処理できる速さでデータを書き込みます。いくつかの注意事項:

  1. MongoDB はトリガーをサポートしていません(少なくとも最後にチェックしたとき)。
  2. MongoDB は、ディスクに同期する前に、最初にデータを RAM にキャッシュします。耐久性を備えたリアルタイムのニーズが必要な場合は、fsync を低く設定することをお勧めします。これにより、パフォーマンスが大幅に低下します。
  3. C# ドライバーは少し不安定です。それが私だけかどうかはわかりませんが、長時間実行する操作を実行しようとすると、奇妙なエラーが発生します。C++ ドライバーは、C# ドライバー (またはその他のドライバー) よりもはるかに優れており、実際には高速です。

そうは言っても、RavenDB も調べることをお勧めします。それはあなたが探しているものすべてをサポートしていますが、私の人生では、Mongo に近いパフォーマンスを得ることができませんでした.

MongoDB に近づいた他の唯一のデータベースはRiakでした。そのデフォルトの Bitcask バックエンドは、キースペースを保存するのに十分なメモリがある限り途方もなく高速ですが、トリガーをサポートしていないことを思い出します。

于 2011-09-25T18:51:27.147 に答える
4

Membase (および間もなくリリースされる Couchbase Server) は、ニーズを簡単に処理し、動的なスケーラビリティ (オンザフライでノードを追加または削除)、フェイルオーバーによるレプリケーションを提供します。最上位の memcached キャッシュ レイヤーは 200k ops/秒を簡単に処理し、複数のノードで線形にスケールアウトして、ディスクに永続化されたデータの取得をサポートできます。

非常に低いレイテンシー (高スループットとほぼ同等) を示す最近のベンチマークがいくつかあります。

サポートされているエンタープライズ クラスの製品とその背後にあるエンジニアリングおよび QA リソースを持つことがどれほど重要かはわかりませんが、それも利用できます。

編集: 組み込みのトリガー インターフェースが既に存在することを忘れていました。データがディスクにヒットした (永続化された) とき、または複製されたときを追跡するために、それをさらに拡張しています。

ペリー

于 2011-09-27T21:50:57.063 に答える
2
  • 読み取り/書き込みを多用するアプリケーション向けに、フェールオーバークラスタリングを備えたドキュメントデータベースストレージソリューションを検討しています。

十分なキャッシュとソリッドディスクが非常に高速である場合、RiakとGoogleのLevelDBバックエンド[これはGoogleのすばらしいベンチマークです]。ドキュメントの構造とそのサイズ（2KBとおっしゃいました）にもよりますが、もちろんベンチマークを行う必要があります。[データを（ビジネス的に）シャーディングできる場合は、単一ノードで40K/sのスループットを維持する必要がないことに注意してください]

LevelDBのもう1つの利点は、データ圧縮=>ストレージです。ストレージが問題にならない場合は、圧縮を無効にすることができます。その場合、LevelDBは文字通り飛行します。

二次インデックスを使用したRiakを使用すると、必要に応じてデータ構造を文書化できます=>検索対象のフィールドのみにインデックスを付けることができます。

成功し、痛みを伴わないFail Overのは、Riakの2番目の名前です。ここは本当に輝いています。

  • また、dbが新しく書き込まれたレコードについて通知するメカニズムも必要です（dbレベルでのある種のトリガー）

pre-commitその動作を実現するためにpost-commit hooksRiakに依存することもできますが、トリガーとして、価格=>パフォーマンス/保守性が付属しています。

  • インサートはすぐに読めるはずです-ほぼリアルタイム

Riakはディスクに書き込みます（非同期のMongoDBのサプライズはありません）=>reliably readableすぐに。より良い一貫性が必要な場合は、挿入に対してRiakのクォーラムを構成できます。たとえば、挿入が成功したものとして扱われる前に、いくつのノードが戻る必要があるかなどです。

一般に、fault tolerance/ concurrency/ fail over/scalabilityが重要な場合は、Erlangで記述されたデータストアを使用します。これは、Erlangが長年にわたってこれらの問題を解決することに成功しているためです。

于 2011-09-26T19:19:25.367 に答える