CouchDB の究極の目標は、レプリケーション機能です。TouchDB、Cloudant-Sync、および Couchbase-Lite を使用すると、ユーザーのスマートフォンからデータベースを複製することもできるため、接続に問題があってもデータを利用できます。
CouchDB レプリケーション プロトコル(さまざまなフレームワークや SDK で実装が若干異なる場合があります) は、変更されたすべてのドキュメントに対して GET 要求を行います。
CloudantとIris-Couchはどちらも、データベースのサイズ、軽い http 要求 (GET、HEAD) の数、および重い http 要求 (PUT、POST、DELETE) の数に基づく料金設定プログラムを提供します。つまり、単一のドキュメントに対して GET を呼び出すと、 に対して GET を呼び出すのと同じコストがかかり/_all_docsます。
ある意味では、これらの価格設定プログラムに関しては、レプリケーション プロトコルは非常に非効率的であるように見えます。たとえば、ユーザーがサーバーからドキュメントをプルするだけの場合、要求によって変更されていないドキュメントをダウンロードするように要求/_all_docs?include_docs=trueされたとしても、標準のレプリケーションを実行するよりも安価に使用できる可能性があります.../_all_docs
何か不足していますか？価格設定プログラムは、リクエスト数ではなく、ダウンロード/アップロードされるデータの量を考慮すべきではありませんか? /_all_docs単一のドキュメントの GET リクエストは、呼び出しやビューよりもはるかに安価であるべきではありませんか? レプリケーション プロトコルを微調整して、帯域幅の面で効率を低下させますが、はるかに安価にすることはできますか?
PS Couchbase は別のプロジェクトであり、CouchDB レプリケーション プロトコルはそれに無関係であることを知っています。Couchbase はクライアントからのレプリケーションもサポートしています (Couchbase Lite 経由)。サーバーへのリクエスト数に関して、2 つのメカニズムを比較する方法はありますか?
- - 編集 - -
/_all_docsコストを削減するためではなく、プロセスを最適化するために、Couchbase-Lite レプリケーション アルゴリズムで使用されている
ようです: https://github.com/couchbase/couchbase-lite-ios/wiki/Replication-Algorithm
- 上記の一括取得最適化の限定的なケースは、標準 API で可能です。ジェネレーション 1 のリビジョン (リビジョン ID は「1-」で始まります) は、_all_docs を介して一括で取得できます。これは、定義上、リビジョン履歴がないためです。残念ながら、_all_docs は添付ファイルの本文を含めることができないため、JSON が添付ファイルがあることを示すドキュメントを返す場合、それらは個別に取得する必要があります。それにもかかわらず、この最適化は非常に役立ち、現在 Couchbase Lite に実装されています。
- 編集 -
この問題は、CouchDB の一部としてではなく、Couchbase Sync Gateway で処理されています: https://github.com/couchbase/sync_gateway/wiki/Bulk-GET
これが CouchDB に実装されることはあるのだろうか。リクエストごとに課金するサービス プロバイダーは、この機能をサポートすることに関心がないようです...