web-dev-qa-db-ja.com

MongoDb / CouchDb / RavenDbの選択-パフォーマンスとスケーラビリティに関するアドバイス

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

データベースには、毎秒平均40Kの同時書き込みが行われます（ピークは70,000に達する可能性があります）-ほぼ同じ数の読み取りが発生する可能性があります。

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

ドキュメントデータベースの適切な選択と関連する容量計画の観点から、どのようなオプションが適切でしょうか？

更新済み

期待の詳細。

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

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

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

最後に、同時実行だけではデータベースを選択できないと思います。API（データを取得する方法）を計画して、手元にあるオプションを確認する必要があります。

8
frail

MongoDBをお勧めします。私の要件はあなたの要件ほど高くはありませんでしたが、それはかなり近いものでした。 C＃を使用する場合は、公式のMongoDB C＃ドライバーとInsertBatchメソッドとSafeModeがオンになっています。ファイルシステムが処理できるのと同じくらい高速に文字通りデータを書き込みます。いくつかの警告：

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

そうは言っても、RavenDBも調べることをお勧めします。それはあなたが探しているものすべてをサポートしますが、私の人生の中で、私はそれをモンゴの近くのどこでも実行させることができませんでした。

MongoDBに近づいた唯一の他のデータベースは Riak でした。そのデフォルトのBitcaskバックエンドは、キースペースを格納するのに十分なメモリがある限り、途方もなく高速ですが、私が覚えているように、それはトリガーをサポートしていません。

6
Rahul Ravindran

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

レイテンシが非常に低いことを示す最近のベンチマークがいくつかあります（これはおおむねハイスループットに相当します）： http://10gigabitethernet.typepad.com/network_stack/2011/09/couchbase-goes-faster -with-openonload.html

サポートされているエンタープライズクラスの製品の後ろにエンジニアリングリソースとQAリソースがあることがどれほど重要かわからないが、それも利用できる。

編集：組み込みのトリガーインターフェイスが既にあることを忘れてしまったため、データがディスクにヒットする（永続化される）か、レプリケートされるかを追跡するためにさらに拡張します。

ペリー

4
Perry krug
  • 読み取り/書き込みが集中するアプリケーションのために、フェールオーバークラスタリングを備えたドキュメントデータベースストレージソリューションを検討しています

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

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

セカンダリインデックス付きのRiakを使用すると、データ構造をドキュメント化されたとおりに作成できます=>検索対象のフィールドのみにインデックスを付けます。

成功して無痛Fail OverはRiakの2番目の名前です。ここは本当に輝いています。

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

信頼できるpre-commitおよびpost-commit hooks Riakでその動作を実現しますが、トリガーとしては、価格=>パフォーマンス/保守性が伴います。

  • 挿入はすぐに読めるはずです-ほぼリアルタイム

Riakはディスクに書き込みます（非同期のMongoDBサプライズはありません）=> reliably readable 直ちに。整合性を高める必要がある場合は、Riakのクォーラムを挿入用に構成できます。挿入が成功したと見なされるまでに戻ってくるノードの数

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

2
tolitius