混合Lucene/MySQL查询或概念

Question

我们的项目需要近实时搜索和不断更新。数据当前存储在MySQL数据库中，Lucene索引随着数据库的修改而更新。

我们目前在我们想要的地方有搜索功能。但是，我们正在尝试添加“标记”文件到索引/数据库中的功能。由于数据源可能是数百万条记录，因此我们不想更新Lucene索引以进行标记（或者是否有方法可以对Lucene进行大规模更新）。我们在MySQL中有一个文档ID表，我们希望用它来确定标签集。

到目前为止，我发现的最好的选择是将ID列表作为整数数组进行检索，对它们进行排序（因此我只需要循环一次），然后遍历并查找两者之间的匹配（尽管这是不理想的，因为我们可能会失去排序）。

尝试在MySQL中的“IN”查询中使用Lucene ID列表失败，因为文档数量可能在数百万个以及MySQL扼流器上。

深入了解我们如何优化或做到这一点？

另一个建议是使用MutliSearcher的第二个索引，但我不完全确定如何去做，因为在更新或删除标记集时，仍然需要更新索引，可能有100万行。

Answer 1

对于您的“批量更新”，您不能在MySql表中基于时间戳记或类似文件对Lucene索引执行delta更新吗？我已经在solr中完成了这个任务，而不是直接在Lucene中完成，但由于Solr是Lucene功能的一个包装，这基本上是相同的（或者我假设......）。

。

Relevant question, (perhaps).

Answer 2

对于所有下面的假设是，你没有足够的RAM完全容纳整个集合。

索引技术的设计特别适用于读取次数多于写入次数的情况。首先分析相应的频率并因此量化“持续更新”将是很好的。

如果更新频率太高，您可能想尝试直接使用您的数据库系统处理这部分搜索（如果MySQL没有完成这项工作，也有PostgreSQL;响应速度也会取决于数据库中的索引机制和可用于在内存中缓存它们的内存）。否则，您可能需要考虑Solr（这不仅仅是Lucene的一个简单包装，因为它提供了可能基于Lucene的额外功能，但本身并不能使用Lucene）。

特别是：

• Solr performance factors
• Multi Core approach（即核心交换）
• StreamingUpdateSolrServer

也许你可以使用取决于更新的批量大小和性能不同的策略提交/优化的交易。对于大批量更新，复制备用核心，批量更新，提交/优化和交换核心可能更容易。但是，它不再是“近实时”（NRT）; NRT in Lucene的想法是本地的并且直接依赖于可用的RAM和集合大小。