11,000,000ドキュメントのインデックスがあります。ほとんどのドキュメントには、「flrid」と呼ばれる一意のIDと、SolrのPKである「solrid」と呼ばれる別のIDがあります。一部の検索では、FLRID値のリストによって定義されたドキュメントのサブセットに検索を制限できる必要があります。FLRID値のリストは検索ごとに変わる可能性があり、2つの検索で同じFLRIDのセットを制限することを「決して」と呼ぶことはほとんどありません。
私たちが今していることは、大まかに言って、次のとおりです。
q=title:dogs AND
(flrid:(123 125 139 .... 34823) OR
flrid:(34837 ... 59091) OR
... OR
flrid:(101294813 ... 103049934))
これらのFQの括弧のそれぞれは、1,000個のFLRIDをつなぎ合わせることができます。一緒にORできる用語の数に関するSolrの制限を乗り越えるには、サブグループ化する必要があります。
このアプローチの問題は（不格好であることに加えて）、O（N ^ 2）程度を実行しているように見えることです。1,000個のFLRIDを使用すると、検索は50ミリ秒程度で返されます。10,000個のFLRIDがある場合、400〜500ミリ秒で戻ります。100,000個のFLRIDを使用すると、約75000ミリ秒に跳ね上がります。せいぜい1000〜2000msのオーダーで、すべての場合で最大100,000FLRIDにする必要があります。
どうすればこれをより良くすることができますか？
私たちが試した、または検討したこと：
- 試行：最小一致mm：0でdismaxを使用して、ORクエリをシミュレートします。改善なし。
- 試行：FLRIDをqではなくfqに配置します。改善なし。
- 考慮事項：特定の検索のすべてのFLRIDを別のコアにダンプし、そのコアとメインコアの間で結合を実行しますが、1秒あたり5〜10回の検索を実行すると、Solrはすべてのコミットで停止するようです。FLRIDのセットは検索間で一意であるため、再利用することはできません。
- 考慮事項：FLRIDをSolrIDに変換し、代わりにSolrIDを制限して、FLRID->SolrIDを変換して照合を行うためにSolrがドキュメントをヒットする必要がないようにします。
私たちが望んでいること：
- 長いIDのセットを渡す、またはSolrがアプリのOracleデータベースからIDをプルできるようにするための効率的な方法。
- Solrに、（私たちが想定している）単純な1つずつのマッチングではなく、集合演算として大きなORを実行させます。
- クエリ内のfqの文字列は最適ではないように思われるため、クエリに渡される一致ベクトルを作成する方法。
私はSOとウェブを検索し、この種の状況について質問する人を数回見つけましたが、私たちが現在行っていることを超えて私が見る答えはありません。