14

クエリ結果セットに変更のストリームを提供できるNoSQLデータベースがある場合はどれですか？

誰かが私にいくつかの例を教えてもらえますか？

まず、どのSQLデータベースもこの機能を提供していないと思います-私は正しいですか？

SQLで同等のものが記述されている可能性のある、任意の単純なクエリを指定できる必要があります。

SELECT * FROM accounts WHERE balance < 0 and balance > -1000;

初期結果セットが必要です：

id: 100, name: Fred, balance: -10
id: 103, name: Mary, balance: -200

しかし、それから私は、変更を停止するまで、変更のストリームを永遠に追跡したいと思います。

meta: remove, id: 100
meta: add,    id: 104, name: Alice, balance: -300
meta: remove, id: 103
meta: modify, id: 104, name: Alice, balance: -400
meta: modify, id: 104, name: Alison, balance: -400
meta: add,    id: 101, name: Clive, balance: -200
meta: modify, id: 104, name: Alison, balance: -100
...

注：大きな結果セットのストリーミングについては話していません。ソフトリアルタイムの変更の流れを探しています。

また、可能であればスケールアウトする必要があります。

ありがとう、

クリス。

4

8 に答える 8

12

CouchDBには変更フィードがあります。基本的に、それはブロックチェーン、または開始以来のデータベースのすべての変更の履歴です。JSON、JSONP、ロングポーリングを介して、または連続ストリームとしてフィードを取得し、データベースの変更に応答するアプリケーションを作成できます。

これが私のブログからの変更フィードです

詳細については、CouchDBガイドのこのセクションを確認してください。

于 2011-03-10T09:00:47.507 に答える
5

答えは受け入れられましたが、あなたの質問の下にある仮定の核心に達する別の答えがあります。

データへの変更のリストを取得することに関連するビジネス上の懸念は何ですか？データへの変更のリストを取得するだけでなく、データが変更された理由と方法を示す一連のイベントを受け取った場合はどうなりますか。

この概念は、アーキテクチャとしての「CQRS」の背後にある根本的な理由の1つです。基本的に、FundsDeposited、FundsWithdrawnなど、データに変更を加えたすべてのイベントを保存し、それらのイベントを「再生」して、データが時間の経過とともにどのように変化したかだけでなく、その理由を発見することができます。

その道を進むと、イベントをストリームとして保存できるようになり、少数のストレージエンジンに制限されなくなります。代わりに、文字通り任意のストレージエンジンを使用でき、それで作業が完了します。

于 2011-03-10T14:17:08.350 に答える
1

これがまさにあなたが探している種類のものであるかどうかはわかりませんが、言及するのに十分な関連性があると考えました！

MongoDBでレプリケーションを使用する場合、すべての書き込み操作はoplog（操作ログ）に保存されます。したがって、すべての挿入/更新/削除はそこに記録され、セカンダリノードで再生できるようになります。これは上限付きのコレクションであるため、循環して自身を上書きします（サイズを設定できます）。しかし、理論的には、このoplogは、変更のストリームを取得する方法として使用できます。私はそれを自分で試したことはありませんが、おそらくそのoplogをポーリングすることができます。

于 2011-03-10T08:47:33.880 に答える
1

ブレーンストーミングの答えのみ：

たとえば、MongoDBを取り上げ、上記のように変更フィードにアクセスしたくないとします。はい、それは他の答えと比較してくだらないように聞こえますが、これらの答えが書いている間にポップアップする前の私の最初のアイデアでした...

この質問に関連する現在の機能は、上限付きコレクション（http://www.mongodb.org/display/DOCS/Capped+Collections）とサーバー側のコード実行（http://www.mongodb.org/display/ ）です。 DOCS/サーバー側+コード+実行）。

上限付きのコレクションを使用すると、大量のデータを書き込むのは簡単ですが、（ログファイルのように）読み取る量は少なくなります。このコレクションタイプは、このような場合に使用されます。サーバーサイドスクリプトは、多くの処理（アプリコードが少ない）をアウトソーシングするために使用できますが、ロジックをアプリに完全に統合する場合は、この点を省略できます。

「フック」を備えたNoSQLDBがあるかどうかはわかりません。私はそれがpostgres（SQL）で可能であることを知っています。

現在、ストリーミングロジックはアプリコードAFAIKで実装する必要があります。

CouchDBでは、MongoDBに実装されていない「ビュー」で可能になる可能性があります（これが正しくない場合は、リンクを教えてください。これも興味深いトピックです！）。

これが役立つかどうかわからない。ここSOでの答えの私の最初の試みです。

于 2011-03-10T09:11:27.430 に答える
1

この種のことは、データベースではなくアプリで行う必要があります。

つまり、変更を加えるたびに、新しいレコードとして記録する必要があります。レコードの変更ではありません。このようにすると、アプリに追加できるインテリジェンスが大幅に増えます。

于 2011-12-06T05:33:01.647 に答える
1

v.3.6以降、MongoDBは変更ストリームを使用して、アプリケーションが変更のリアルタイムリストにサブスクライブできるようにします。

変更ストリームを使用すると、アプリケーションは、oplogを調整する複雑さやリスクなしに、リアルタイムのデータ変更にアクセスできます。アプリケーションは、変更ストリームを使用して、コレクション上のすべてのデータ変更をサブスクライブし、それらに即座に対応できます。

変更ストリームは、依存するビジネスシステムを備えたアーキテクチャにメリットをもたらし、データの変更が永続的になると、ダウンストリームシステムに通知します。たとえば、変更ストリームを使用すると、抽出、変換、読み込み（ETL）サービス、クロスプラットフォームの同期、コラボレーション機能、通知サービスを実装する際の開発者の時間を節約できます。

デフォルトでは、ストリームはコレクション内のすべてのドキュメントへの変更を返しますが、集計パイプラインを追加して、クエリ結果セットに一致するドキュメントのみにフィルターをかけることができます。

于 2018-01-12T15:58:30.950 に答える
0

すべての変更（クエリ結果セットへの変更だけでなく）を受け入れることができる場合は、mongodbレプリケーションスレーブを作成し、マスターからすべての変更を受け取ることができます。phpでさえmongodbレプリケーションスレーブが書かれているのを見たことがあるので、それを実装するのはそれほど難しいことではないはずです。

于 2011-03-10T11:02:48.220 に答える
0

mongoDBは、tailable-cursorを実装しますが、上限付きコレクションのみを対象としています。ドキュメントを参照してください。特定の要件によっては、役立つ場合があります。

于 2011-03-10T12:37:04.843 に答える