Question

我有一个11,000,000个文档索引。大多数文档都有一个名为“flrid”的唯一ID，加上一个名为“solrid”的不同ID，即Solr的PK。对于某些搜索，我们需要能够将搜索限制为由FLRID值列表定义的文档子集。 FLRID值列表可以在每次搜索之间进行更改，并且很少会将其称为“从不”任何两个搜索将具有相同的FLRID集来限制。

我们现在正在做的是：

q=title:dogs AND 
    (flrid:(123 125 139 .... 34823) OR 
     flrid:(34837 ... 59091) OR 
     ... OR 
     flrid:(101294813 ... 103049934))

这些FQ中的每一个括号都可以是1000个FLRID串联在一起。我们必须通过子组才能超越Solr对可以进行OR运算的术语数量的限制。

这种方法的问题（除了它很笨重）是它似乎执行O（N ^ 2）左右。拥有1,000个FLRID，搜索时间大约为50ms左右。如果我们有10,000个FLRID，它会在400-500ms内恢复。拥有100,000 FLRID，可跃升至约75000ms。在所有情况下，我们希望它最多可达1000-2000毫秒，最多可达100,000 FLRID。

我们怎样才能更好地做到这一点？

我们尝试或考虑过的事情：

尝试：使用最小匹配的dismax mm：0来模拟OR查询。没有改善。
尝试：将FLRID放入fq而不是q。没有改善。
考虑：将给定搜索的所有FLRID转储到另一个核心并在它与主核心之间进行连接，但如果我们每秒进行五次或十次搜索，似乎Solr会死于所有提交。 FLRID集在搜索之间是唯一的，因此无法重复使用。
考虑：将FLRID转换为SolrID，然后限制SolrID，以便Solr不必点击文档就可以翻译FLRID-＆gt; SolrID来进行匹配。

我们希望：

传递一长串ID的有效方法，或者Solr能够从应用程序的Oracle数据库中提取它们。
让Solr做一个大的OR作为一个集合操作而不是（我们假设的）一个天真的一对一匹配。
一种创建传递给查询的匹配向量的方法，因为查询中的fqs字符串似乎是次优的方式。

我搜索了SO和网络，发现人们几次询问这种情况，但我看到的答案超出了我们现在正在做的事情。

如何将Solr搜索限制为任意一组100,000个文档？

0 个答案: