Solr 4.5：Solrファセットのクエリは単純なクエリよりも優れていますか？

Question

私はApache Solrと一緒に作業しており、いくつかのクエリオプションに関する詳細情報を取得したいと考えています。私はファセットクエリを発見し、正確にいつそれらが本質的な利点をもたらすのだろうかと疑問に思っていました。特に次の例の場合：

Solrサーバーに保存されている書籍があります。書籍に共通する属性にもかかわらず、彼らはISBNを持っています。書籍に関するデータは第三者によって提供されるため、システム内に二重のISBNがないことを確認することが重要です。書籍のISBNが重複しているかどうかを確認するには、経路を通過する必要があります。残念ながら、すべての書籍は前処理または後処理に関する情報なしに個々に処理されます。

質問は次のとおりです。
A）あなたは、単に現在のブックISBNでのSolrを照会し、合計の結果、または
Bをチェックする必要があります）あなたはf.isbn.facet.mincount=2とファセットのクエリを送信し、結果は現在が含まれているかどうかを確認する必要がありISBNを予約しますか？

いずれの場合も、キャッシュ結果は不可能です。したがって、照会の数は常に処理される書籍の数に等しくなります。私は、Solrがどのように働いているのか分かりません。したがって、特に上記のいずれかの可能性によって問合せの数が減ることはないため、これ以上の情報なしにこの決定を行うことはできません。

Answer 1

クエリを実行する場合は、クエリを実行します。 Luceneはクエリを行うために高度に最適化されているので、それはあなたがすべきことです。ファセットクエリーは、任意のクエリーからファセット（カウント）を作成するためのものです。内部的にも同じことが行われます。ファセットを生成し、そのファセットを反復処理する場合、Luceneは単一の値を照会するだけの場合よりもはるかに多くのドキュメントを参照する必要があります。

パフォーマンスを向上させる最良の方法は、同じバッチ（つまり、isbn:(123 OR 321 OR 567 OR 765)）の500冊の書籍をバッチチェックして、これらの操作をコード内で実行することです。これらの更新が単一のソースを経由せずに多くのシステムから並列に到着できる場合は、ストリームに重複が表示されるまでにどれくらいの時間を費やすことができるかを決定する必要があります（この競合状態は、 2つのストリームが単一のisbnを問い合わせて、両方のストリームから別々に追加する前に否定結果を得ることができるため）。