ディープストリーム "キャッシュ"レイヤーのリアルタイムクエリ？

Question

私は、RethinkDBコネクタを使用することで、特に名前付きリストに登録することで、リアルタイムでクエリ機能を実現できることが分かりました。レコードの変更がデータベースに書き込まれた後にのみクエリが更新される可能性があるため、これは実際には最速の解決策ではないと私は推測します。リアルタイムのクエリ機能をディープストリーム側で実現するための推奨されるアプローチはありますか？

のようないくつかの有利な特性があります。

• ユニークなクエリの数は、RPCを介して行われているレコードの数または接続されたクライアント
• 照会の対象となるレコードのすべての操作の偶数個に比べて小さいです。

私はそれを行う方法を複数の方法を想像することができます

• はrethinkdbコネクタのアプローチを模倣します。しかし、そのために私はlist.listen（）メソッドがありません。これで、オンデマンドでリストを作成するバックエンドプロセスを作成し、レコード上の各RPC CRUD操作で、現在アクティブなリスト=クエリをすべて更新することができます。

• レコード内の再実装し、基本的なリスト機能となりまし既存.listen（と上記のアプローチを使用する）

• イベントで.listen使用（）？

または、私はlist.listen（）を持っていますか？またはそれをよりエレガントな方法がありますか？

Answer 1

大きな質問 - 一般的に、リストはクライアント側の概念であり、レコードの上に実装されます。レコードを購読しているクライアントについて、必ずしも変更する必要はありません。変更通知はmylist.subscribe(data => {})またはmyRecord.subscribe(data => {})で届きます。

トリッキービットは、キャッシュの非常に限定されたクエリ機能です。レディスは、範囲と交差点を検索できるセカンダリインデックスの基本コンセプトを持っています。memcachedとcoは、IDだけで検索可能な純粋なキー値ストアです。実際のクエリは、データベースレイヤで最も効果的です。あなたのデータは通常200ミリ秒よりかなり遅く到着します。

RethinkDBの検索プロバイダーは、RethinkDBのリアルタイムクエリー機能をサポートしています。また、MongoDBを使用して操作ログを追跡したり、変更通知用にPostGresと深層ストリームに組み込まれた購読機能を使用することもできます。