0

私が持っているメッセージングアプリのユースケースに最適な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 の複製を維持する必要があります。これには他の欠点がありますが、うまくいく可能性があります。

上記から、最も実現可能でスケーラブルなアプローチはどれですか? または、別のオプションがありませんか?

ありがとう

4

1 に答える 1

0

オプション 2 を使用します。ドキュメント シーケンス ID (ビュー関数からは取得できないと思います) の代わりに、メッセージ ドキュメントに日付/時刻フィールドを追加するだけですか?

クライアントの時計のずれが心配な場合 (編集しようとするのではなく、私の回答にコメントとして投稿する必要がありましたが、拒否されました)、検索にある程度の許容範囲を適用できます。すでに見たいくつかのメッセージを追加するだけでも悪くないと思います。

(クロック スキューについてもそれほど心配する必要はありませんが、どのような種類のクライアントを使用するかはわかりません。)

于 2013-05-16T10:15:09.923 に答える