如何合并来自两个不同（非分片）Lucene 索引的匹配项答案

【问题标题】：How to merge matches from two distinct (not sharded) Lucene Indexes如何合并来自两个不同（非分片）Lucene 索引的匹配项
【发布时间】：2009-08-16 21:25:24
【问题描述】：

我有两个单独的索引，它们包含不同的字段，这些字段一起包含索引的所有可搜索字段。例如，第一个索引保存所有文档的索引文本，第二个索引保存每个文档的标签。

请注意，下面的示例有点不稳定，因为我更改了实体的名称。索引1：文本文档ID

索引2：标记名称：“非常重要” 用户：“弗雷德的身份证”

我想保持索引分开，因为每当用户添加/删除标签时不断更新单个索引似乎很浪费。

到目前为止，我认为我可能需要处理两个搜索结果并手动合并它们（在代码中）。还有其他建议吗？

我不想合并单独/分片的索引。

【问题讨论】：

您是否有理由需要将标签存储在索引中？为什么不将这些信息存储在关系型数据库（如 MySQL 或 SQL Server）中，并将唯一 id 存储在索引中？
@Phoenix - 因为我希望能够执行跨越两个索引的查询。

标签： lucene

【解决方案1】：

Lucene 有一个IndexReader 类型来支持这种安排——ParallelReader。

使用起来可能有点棘手，因为记录的 Lucene 文档标识符在两个索引中必须相同。实际上，这意味着以相同的顺序将文档添加到两个索引中。我已经读过，在某些情况下，文档删除和索引优化会导致 Lucene 重新分配这些文档标识符，但我还没有尝试确定这是否属实。如果修改了现有记录，则可能需要格外小心。如果只追加新记录，应该没有问题。

这种方法通常称为“垂直分区”，而不是“水平分区”或分片。

【讨论】：

希望文档 ID 在两种情况下都匹配似乎是错误的。我想妥善管理。
这不仅仅是希望文档 ID 在文档添加到索引时匹配； ID 只是一个序列号。我不清楚的是 Lucene 是否会重新分配文档 ID 以“压缩”具有高比例已删除记录的索引（请记住，Lucene 中的“更新”是删除原始记录，然后添加“更新"记录)。
“sequence number”比“document id”更接近真实定义，但它们实际上只是一个“偏移量”。随着索引的优化，删除的文档从底层索引文件中物理删除（有点像对索引进行碎片整理），这些偏移量会发生变化，并且没有（简单的）方法可以检测到它。我遇到的这个问题最常见的解决方案是将您自己的唯一 ID 存储在 Lucene 文档的“id”字段中。

【解决方案2】：

似乎您需要合并代码中的索引。如果我理解正确，在搜索术语时，可以匹配文档文本或标签，并且每个标签都使用其相关文档 ID 进行索引。然后，您将有两个要合并的命中列表。由于标签和全文是非常不同的实体，您将需要一些权重（可能作为检索期间的字段提升）才能达到良好的排名。因此，您可以使用如下公式合并文档 k 的标记匹配和全文匹配：

score(k) = a*tagscore(k)+b*fulltextscore(k)

其中 a 和 b 将是经验确定的系数。

有关更详细的讨论，请参阅 Grant Ingersoll 的 findability 和 debugging relevance issues in search 论文。

【讨论】：

评分不是问题，因为合并将在布尔查询边界上。真正的问题在于如何进行搜索。
@mP：请澄清。如果您在两个索引中存储每个文档的唯一 ID，我认为搜索没有问题。我确实看到了排名/评分问题 - 如果您从文档文本中获得 1000 次点击，并且从标签中获得 2000 次点击，您可能希望显示前 20 名左右；这就是得分的重要性。

【解决方案3】：

这种方法的主要问题与文档的排名有关，因为默认算法（可能还有大多数自定义算法，除了少数例外）是基于词频和逆文档频率的。

换句话说，记分员需要知道一个术语在一个文档中出现了多少次，以及有多少其他文档包含该术语。此信息存储在索引中的每个术语，而不是跨多个索引的聚合。

此问题的常见解决方案是两阶段方法。首先，针对每个索引运行查询以确定有多少文档包含每个术语。接下来，汇总结果并再次运行查询，但这次将同时发送逆文档频率。

正如您可以想象的那样，这不会像对单个索引运行查询那样好，但由于没有什么是免费的，我认为这是跨多个索引存储文档的权衡。

【讨论】：