我有一个包含 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 括号中的每一个都可以是 1,000 个 FLRID 串在一起。我们必须进行子分组以克服 Solr 对可以一起 ORed 的术语数量的限制。
这种方法的问题（除了它很笨重）是它似乎执行 O(N^2) 左右。对于 1,000 个 FLRID，搜索会在 50 毫秒左右返回。如果我们有 10,000 个 FLRID，它会在 400-500 毫秒内返回。如果有 100,000 个 FLRID，则时间会上升到大约 75000 毫秒。我们希望它在所有情况下最多为 1000-2000 毫秒，最多 100,000 个 FLRID。
我们怎样才能更好地做到这一点？
我们尝试或考虑过的事情：
- 尝试：使用 dismax 和最小匹配 mm:0 来模拟 OR 查询。没提升。
- 尝试：将 FLRID 放入 fq 而不是 q。没提升。
- 考虑：将给定搜索的所有 FLRID 转储到另一个核心并在它和主核心之间进行连接，但如果我们每秒进行五到十次搜索，Solr 似乎会因所有提交而死亡。FLRID 集在搜索之间是唯一的，因此不可能重用。
- 考虑：将 FLRID 转换为 SolrID，然后改为限制 SolrID，这样 Solr 就不必点击文档来转换 FLRID->SolrID 来进行匹配。
我们所希望的：
- 一种传递长组 ID 或 Solr 能够从应用程序的 Oracle 数据库中提取它们的有效方法。
- 让 Solr 将大 OR 作为一个集合操作而不是（我们假设是）一个简单的一次匹配。
- 一种创建传递给查询的匹配向量的方法，因为查询中的 fqs 字符串似乎是一种次优方法。
我搜索了 SO 和网络，发现有人问过这种情况几次，但除了我们现在正在做的事情之外，我没有看到任何答案。