3

クエリ処理に関する私の理解は正しいですか?

  1. Get DocSet from cache or First filter query は OpenBitSet または SortedVIntSet の実装を作成し、それをキャッシュします
  2. キャッシュから DocSet を取得するか、他のすべてのフィルターが DocBitSet の実装を作成し、オリジナルと交差します (このコードの効率は DocSet の最初の実装の実装に依存します)
  3. Lucene フィルター + クエリ検索を使用して、MainQuery と最終的な DocSet (すべての交差の後) でリープフロッグを行います (この効率は、最初の DocSet 実装に依存します) 。
  4. 元のクエリの AND としてポスト フィルター (cost > 100 && cache==false) を適用します。

結果として、小さなクエリの場合は SortedIntSet の方が効率的であり、大きな BitSet の場合は優れているため、パフォーマンスは最初のフィルターに依存します。私は正しいですか？

質問の 2 番目の部分: DocSet には、HashDocSet と SortedIntDoc の 2 つの主要な実装があります。各交差実装は、最初のフィルターのすべてのインスタンスを反復し、2 番目の DocSet にもあるかどうかを確認します...つまり、フィルターをサイズで並べ替え、最初に最小にする必要があります。キャッシュされたフィルターの順序を制御することは可能ですか (コストはキャッシュされていないフィルターに対してのみ機能します)?

4

1 に答える 1

3

いいですね。詳細については、SolrIndexSearcher#getProcessedFilterをご覧ください。

結果として、小さなクエリの場合は SortedIntSet の方が効率的で、大きな BitSet の場合は優れているため、パフォーマンスは最初のフィルターに依存します。私は正しいですか？

これは、速度の問題というよりは、スペース効率の問題です。ソートされた int[] のコストは 4 * nDocs バイトですが、ビット セットのコストは maxDoc / 8 バイトです。これが、セット内のドキュメントの数が < maxDoc / 32 の場合に Solr がソートされた int[] を使用する理由です。

質問の 2 番目の部分: DocSet には、HashDocSet と SortedIntDoc の 2 つの主要な実装があります。

SortedIntDocSet の問題は、ランダム アクセスがサポートされていないことです。HashDocSet の問題は、ドキュメント ID を順番に列挙できないことです。これはスコアリングにとって重要です。これが、Solr がほぼすべての場所で SortedIntDocSets を使用し、ランダム アクセスが必要なときはいつでも一時的な HashDocSet を作成する理由です (たとえば、JoinQParserPlugin または DocSlice#intersect を見てください)。

于 2012-08-24T10:23:37.710 に答える