NoSQL、CouchDB対CouchBase、どうすればよいですか？

Question

本番サイトでいくつかの問題に遭遇し始めました。非常に大きなResultSet（現在はリレーショナルデータベースであるMySQL）をロードする必要があるWebページがあると、永遠にかかり、これらの結果セットがどんどん大きくなっているという問題があります。

私はより良い解決策を模索し始め、私が遭遇したのはNoSQLデータベースにデータを保存するという考えです。（私は既にMongoを使用していますが、環境に大量のDMLがあるため、Mongoは非効率的です。）Webを検索するとき、次の2つのオプションについて考えました。

CouchDB
カウチベース

上記の両方を見ると、どちらもJSONドキュメントベースであると言えます（それは良い出発点です）が、技術的な背景に入るときは、より良いキャッシュを探します（私は殺したくありません）私のサーバーのI/O）、次にMongoDBのマスターマスターレプリケーション機能（CouchDBがソース->宛先/宛先->ソースに基づいて簡単に複製できることを確認しました）。

誰かが私にあなたの意見のいくつかを提供できますか？あなたが上記の解決策を試していたなら、私はあなたの経験について聞いて幸せです。

Chris Travers · Accepted Answer

IMOあなたがしようとしているのは、MySQLの初期結果サイズに起因するパフォーマンスの問題に対する答えは、トレードオフが何であるかをほとんど理解せずにNoSQLソリューションに頻繁にジャンプすることであると想定することです。それらを適切かつ効果的に使用する方法。

結果セットのサイズが問題である場合、十分に調整されたdbが実際にここでWebアプリケーションの問題である場合、私は驚きます。単純な事実は、結果セットはディスクから非常に高速にしか取得できないことであり（すべてがRAMに強制されるメインメモリデータベースを使用していないと仮定）、実際に結果セットを処理するために時間を費やす必要があります。ウェブページ。それがデータベースであると想定する前に、すべてを完全にプロファイリングすることから始める必要があります。

NoSQLの最も基本的なトレードオフは、データ入力の柔軟性と簡単なスケーリングと整合性の保証、および出力でのデータ処理です。任意のサイズの結果セットに対してNoSQLでデータ処理を行う唯一の方法は、基本的に入力に対して行うことです。これは、従来のRDBMSを犠牲にしてNoSQLソリューションを使用する場合、製品の寿命全体に大きな影響を及ぼします。一方、RDBMSのこれらの付加付属品は、前処理と後処理の両方に役立つ適切なものでした。つまり、NoSQLを選択する理由はありますが、サイズは実際にはその1つではありません。

ここで、これは「非常に大きな結果セット」をロードする「Webページ」であることをここで述べます。さて、私は時々Webアプリでクレイジーなことをしています、そしてあなたが本当に非常に大きな結果セットを直接Webページにロードしているなら、dbパフォーマンス以外にもたくさんの問題があると思います。

たとえば、LedgerSMBでは、1,000を超える請求書行をプルして、一部のユーザー（PostgreSQLを使用）に対して単一のWebページを生成するケースを知っています。私たちにとって、PostgreSQLは、数百万のレコードのテーブルから何千ものレコードを収集する傾向がある場合でも、かなりうまくいきます。そのレベルでのページ読み込みごとに費やされた（プロファイルされた）時間は、約15秒のdb時間から、Webページを生成するためのWebアプリ時間の最大5分です。（これは、この顧客のワークフローをグローバルに最適化するという理由で許容されます。Webページには最大20kの入力要素があり、dbサーバーがデータを送信する場所と送信する場所の間でデータを大幅に変換する必要があることに注意してください。 Webページが作成されます）。これは具体的にはユースケースと一致しない場合がありますが、データベースがボトルネックになっている必要はなく、Webページで多くのことを実行している場合はそうではないという事実がわかります。

以下は、dbが実際に問題である場合のトラブルシューティングとオプションのいくつかの側面です。

アプリケーション全体をプロファイリングします。実際にデータベースに費やされている時間はどれくらいですか？表示用のページの処理にどのくらい費やされていますか？
Dbクエリのプロファイルを作成します。それらをより効率的にするために何ができるでしょうか？

別のデータベースで問題が解決すると結論する前に、これを行ってください。

これが本当に最大に達したことが判明した場合は、選択肢を確認する必要があります。これらには以下が含まれます：

PostgreSQL（はい、リレーショナルデータベース）。これが行っていることの1つは、より一般的に最適化されたテーブル/インデックス構造です（InnoDBはpkeyルックアップに特化しているため、他の検索が遅くなります）。
VoltDB（別のリレーショナルDB。ただし、これは高速oltpのメインメモリであり、非常に高速です）
Rdbmsと一緒に機能するNoSQL dbを使用してキャッシングレイヤーを構築できます。ここで、MongoDBまたはCouchDBを使用できる場合があります。

donna · Answer

Couchbaseには、データベースインスタンス（memcachedテクノロジーに基づく）の一部として組み込みキャッシュが含まれているため、分散キャッシュ層、キー値のユースケース、またはドキュメント駆動型のユースケースに最適です。 Orbitzのような大規模な顧客は、Couchbaseを分散キャッシュ層として使用しています。このページはあなたが探している追加情報を与えるかもしれません。 http://www.couchbase.com/memcached

http://www.couchbase.com/presentations/couchbase-at-orbitz

CouchDBは単一サーバーのドキュメントデータベースです。ピアツーピアの優れたDBになるかもしれませんが、十分に拡張できず、ディスクベースです。

このページは、couchbaseとcouchdbの違いを捉えようとしています。