9

環境

これは、主に Lucene (またはおそらく Solr) の内部に関する質問です。主なトピックはファセット検索です。この検索で​​は、オブジェクトの複数の独立した次元 (ファセット) (車のサイズ、速度、価格など) に沿って検索を行うことができます。

リレーショナル データベースで実装する場合、ファセットは任意の順序で検索できるため、多数のファセットに対してマルチフィールド インデックスは役に立ちません。耐えられない。

Solr は、ファセット検索タスクにうまく対処するように宣伝されています。私が正しく考えると、Lucene が (おそらく) マルチフィールド クエリ (ドキュメントのフィールドがオブジェクトのファセットに関連する場合) でうまく機能する必要があります。

質問

Luceneの逆インデックスはリレーショナル データベースに格納でき、一致するドキュメントの交差を自然に取得することも、単一フィールド インデックスを使用する RDBMS で簡単に実現できます。

したがって、Lucene には、逆インデックスに基づいて一致するドキュメントの交差を取得するだけでなく、複数フィールドのクエリに対する高度な手法がいくつかあると思われます。

問題は、このテクニック/トリックは何ですか? より広く: Lucene/Solr が RDBMS よりも理論的に優れたファセット検索パフォーマンスを達成できるのはなぜですか?

注: 私の最初の推測では、Lucene は、ドキュメント フィールドから構築されたベクトル空間をディメンションとして分割するために何らかの空間分割方法を使用しますが、Lucene は純粋にベクトル空間ベースではないことを理解しています。

4

2 に答える 2

6

ファセット

ファセットには 2 つのタイプがあるため、ファセットには 2 つの答えがあります。これらのいずれかが RDBMS よりも高速かどうかはわかりません。

  1. 列挙ファセット。クエリの結果は、i 番目のドキュメントが一致した場合に i 番目のビットが 1 であるビット ベクトルです。ファセットもビット ベクトルであるため、交差は単なるビット単位の AND です。これは斬新なアプローチだとは思いませんし、ほとんどの RDBMS はおそらくそれをサポートしています。

  2. フィールドキャッシュ。これは単なる通常の (反転されていない) インデックスです。ここで実行される SQL スタイルのクエリは次のようになります。

    select facet, count(*) from field_cache where query_results group by facet の docId

繰り返しますが、これは通常の RDBMS では不可能なことではないと思います。インデックスは、docId をキーとするスキップ リストです。

複数語検索

これがLuceneが輝くところです。Lucene のアプローチが優れている理由をここに投稿するには長すぎますが、Lucene Performance に関するこの投稿、またはそこにリンクされている論文をお勧めします。

于 2011-04-06T15:31:38.007 に答える
3

説明の投稿はhttp://yonik.wordpress.com/2008/11/25/solr-faceted-search-performance-improvements/にあります。

新しい方法は、インデックス付きフィールドを反転せずにファセットすることで機能し、特定のドキュメントのフィールド内の用語をすばやく検索できます。これは実際にはハイブリッド アプローチです。メモリを節約し、速度を上げるために、多くのドキュメント (5% 以上) に表示される用語は逆変換されず、代わりに従来のセット インターセクション ロジックを使用してカウントを取得します。

于 2011-04-07T12:09:39.427 に答える