文書の大量のリアルタイム データ ストリームを消費し、それらの文書が利用可能になったときに一連のユーザー定義の検索クエリに対してそれらの文書を照合するシステムを作成する必要があるとします。これは、レトロスペクティブではなく、プロスペクティブな検索サービスです。適切な永続化ソリューションは何でしょうか?
ユーザーが、クエリに一致するドキュメントのライブ フィード (Google アラートを考えてみてください) を表示したいと考えており、フィードが各ドキュメントの特定のメタデータを表示する必要があるとします。マッチの存続期間が無期限であると仮定しましょう。つまり、システムは、特定のクエリが作成された時点から、ユーザーがクエリのすべての一致を表示できるようにします。そのため、ストリームに含まれる各ドキュメントのメタデータ、およびドキュメントとそのドキュメントに一致したユーザー クエリとの関連付けは、データベースに永続化する必要があります。
ユーザーがメタデータの一部をファセットできるようにするという別の要件を考えてみましょう。たとえば、ユーザーは、メタデータ フィールドの「結果の種類」が「ブログ」に等しい特定のクエリに一致するドキュメントのみを表示したいと考えています。ブログの一致数のカウント。
ここにいくつかの仮定の数字があります:
毎日 200,000 件の新しいドキュメントがデータ ストリームに含まれています。
-すべてのドキュメントのメタデータが保持されます。
それぞれ約 5 つの検索クエリを持つ 1000 人のユーザー: 合計約 5000 のユーザー検索クエリ。
-これらのクエリは単純なブールクエリです。
- 新しいドキュメントが入るたびに、5000 件のクエリすべてに対して処理され、どのクエリが一致するかが確認されます。
各フィード (ユーザー クエリごとに 1 つずつ) は、1 分ごとにユーザーに対して更新されます。つまり、すべてのフィードについて、最新の一致ページのデータベースへのクエリが毎分実行されます。
ユーザーにフィードを表示する速度は、最も重要です。スケーラビリティと高可用性も不可欠です。
ユーザーとクエリの関係は、クエリと一致するドキュメントの関係と同様にリレーショナルですが、ドキュメントのメタデータ自体は単なるキーと値のペアです。したがって、私の最初の考えは、MySQL のようなリレーショナル DB にリレーショナル データを保持し、NoSQL DB にメタデータを保持することでしたが、ファセット要件は NoSQL DB で達成できますか? また、フィードを構築するには、2 つの別個のデータ ストアを呼び出す必要があり、これがさらに複雑になります。または、すべてを MySQL に押し込むこともできますが、これには多くの結合とカウントが必要になります。すべてのデータをキーと値のペアとして別の種類のデータ ストアに格納する場合、ファセットはどのように行うのでしょうか? また、複数の検索クエリに一致するドキュメントには、大量の冗長なメタデータが存在します。
このシナリオに適したデータベースの種類は何ですか? Twitter Stormや Yahoo のS4などのツールを使用して、このようなシステムの全体的なアーキテクチャを構築できることは承知していますが、データ ストレージ、ボリューム、およびクエリ/ファセットを考慮して、データベースに焦点を当てたいと思います。要件。