3

プロジェクトで CouchDB を使用する予定です。しかし、クエリ メカニズムにはビュー (通常の RDMBMS のインデックスによく似ています) の書き込みが含まれるため、ドキュメント データベースが頻繁に更新され続ける場合 (書き込み負荷の高いデータベース)、通常の RDBMS と比較して CouchDB のパフォーマンスが優れているのではないかと考えていました。それとも、パフォーマンスを向上させるために、システムを時々圧縮/再インデックス化する必要がありますか?

4

1 に答える 1

3

CouchDBビューモデルの長所/短所をこのように考えるかもしれません。（CouchDBハッカーは同意しないかもしれませんが、IMOはユーザーにとって十分正確です。）

  1. ビュー関数は、最初に作成されたときに常に完全な「テーブルスキャン」を実行します（RDBMS BTWのように）
  2. 副作用がない限り、mapおよびreduce関数は任意に複雑にすることができます
  3. すべてのドキュメントとmap/reduceの結果はキャッシュされ、二度と計算されることはありません
  4. ドキュメントを追加または変更すると、そのドキュメント（およびそのドキュメントのみ）がそのビューに対して再計算（およびキャッシュ）されます

これらを前提として、CouchDBのパフォーマンスについていくつかの結論を導き出すことができます。

  • データセット全体のインデックスの再作成フェーズはありません。ドキュメントの更新ごとに増分するだけです。
  • ビュー関数を変更すると、インデックス全体が強制的に再構築されます
  • CouchDBとRDBMSの両方が新しいデータのインデックスを更新する必要があるため、更新/挿入の使用量が多い場合でもパフォーマンスは同じになると考えるのが妥当です。

明らかに、YMMVと標準のコップアウトでは、「自分の負荷をテストする必要があります」が適用されます。ただし、さらにいくつかの考慮事項を追加します。

  • RDBMSは、探索的なスタイルでデータをクエリするのに非常に優れていると思います。データからどのような質問をするべきかさえわからない場合、構造化されたクエリ用の言語に勝るものはありません。
  • ただし、知りたいことを定義すると、コードを記述しているだけなので、CouchDB（およびおそらくHadoop）は最も豊富なクエリシステムを提供します。
  • データセットが大きい場合、NoSQLデータベースはより簡単に拡張できます。たとえば、CouchDB-Loungeを使用すると、並列処理用のソファのクラスターが可能になります。Hadoopも同じことを行うので、二次的な考慮事項になります。親しみやすさ、保守性、CouchDBはWebサーバーですが、もう少しDIYが必要です。Hadoopは、複雑さ、異質性などを犠牲にして、より多くのクラスター管理を内部化します。

それがあなたの決定に光を当てるのに役立つことを願っています！

于 2010-05-18T08:35:53.747 に答える