私が持っているメッセージングアプリのユースケースに最適なcouchDBのアーキテクチャに関して質問があります。
ユースケースは、現在、すべてのメッセージをドキュメントとして持つソファ DB が 1 つある単純なメッセージング プラットフォーム用です。各ドキュメントには、メッセージの受信者を示す「宛先」フィールドがあります。クライアント アプリが起動すると、最後のチェック後に特定のユーザーに宛てられたすべての新しいメッセージをデータベースに照会します。これは、ドキュメントの「to」フィールドにユーザーの ID が存在するかどうかをチェックする通常のフィルターを使用して _changes フィードを照会することによって実現されます。
私がcouchDBの操作を理解しているように、これにはデータベースが最後のシーケンスの後に変更フィードのすべてのドキュメントを取得し、それらに対してフィルター機能を実行する必要があります。私のユースケースでは新しいメッセージの可能性は非常に低いため、これは非常に大きなオーバーヘッドになります (100 000 人のユーザーがそれぞれ 1 日に 2 つのメッセージを受け取っているとします。DB は 200 000 のメッセージをすべて読み取る必要があります 200すべてのユーザーをサポートするために 000 回?)
オプション 1: 私が読んだ限りでは、_changes フィードの上にパラメトリック フィルターを配置することはできません。レプリケーション機能を使用してメッセージを抽出できたので、これは素晴らしいことです。– 非スターター?
オプション 2: 「to」フィールドと更新シーケンスを組み合わせたキーを持つビューを実装します。次に、このビューでユーザー値とシーケンス > 最後のシーケンスを照会できます。– ここでは、Map 関数からドキュメントの更新 Seq にアクセスするのに苦労しています。– これは実行可能ですか?
オプション 3: 各ユーザーのサーバーにデータベースを実装し、共通データベースで各ユーザー固有のデータベースへのレプリケーションをセットアップします。次に、ユーザーは自分宛てのメッセージのみを含む自分のデータベースの _changes フィードを照会します。とても簡単です。ここで、サーバー上で 100,000 x 2 の複製を維持する必要があります。これには他の欠点がありますが、うまくいく可能性があります。
上記から、最も実現可能でスケーラブルなアプローチはどれですか? または、別のオプションがありませんか?
ありがとう