はい、CouchDB はこれに非常に適しているように思えます — その単純なプロトコルにより、Web アプリ [オフラインでも、pouchdbを参照] およびモバイル/デスクトップ アプリ [オフラインでも、Couchbase Mobileを参照] に最適です。
残念ながら、公開されている優れたコード レベルの例をすぐには知りませんが、基本的な考え方は、フィルター処理されたレプリケーションとドキュメントの検証を組み合わせて使用することです。
基本的な考え方は、ユーザー データベースのサーバー側のコピーに対して検証機能を設定し、目的のドキュメント スキーマとアクセス制御が適用されるようにすることです。エンド ユーザーは、低遅延のオフライン アクセスに使用できるこのデータベースのレプリカを取得します。理論的には、エンド ユーザーは自分のコピーを破壊することができますが、複製を元に戻すと、検証機能によってサーバー側のデータベースが破損するのを防ぐことができます。
一般公開されていないマスター データベースをセットアップし、フィルター処理されたレプリケーションを使用して、各ユーザーのデータをサーバー側のユーザーごとのデータベースに同期することもできます。これは、集中型メッセージング、集計統計、1 つのデータベースのバックアップのみが必要な場合などに役立ちます。 .
この「レプリケーションの新機能」の記事には、さらにいくつかの高レベルの例があります。特に、「DesktopCouch」と「Need-to-Know ベースのデータ共有」のユース ケース セクションが最後にあります。
更新 (2015/03/10) : 上記のように CouchDB のフィルター処理されたレプリケーションを使用することはお勧めしません。中央データベースからいくつかのフィルタリングされたフィードを複製しようとすると、いくつかのパフォーマンスとスケーラビリティの問題 (信頼性の問題ではないにしても) が発生します。ドキュメント レベルの読み取りアクセス許可が必要な場合は、Couchbase とその同期ゲートウェイを試すか、_local_seq
.