我们的项目需要近实时搜索和不断更新。数据当前存储在MySQL数据库中，Lucene索引在数据库被修改时更新。
我们目前拥有搜索功能。但是，我们正在尝试添加在索引/数据库中“标记”文档的功能。由于数据罐可以是数百万条记录，因此我们不希望更新Lucene索引以进行标记（或者，如果有一种方法可以批量更新可能有效的Lucene）。我们在MySQL中有一个文档ID表，我们希望用它来确定标记集。
我到目前为止找到的最佳选择是将两个ID列表作为整数数组进行检索，对它们进行排序（所以我只需要循环一次），然后循环查找两者之间的匹配（尽管如此）因为我们可能会失去分类，所以并不理想。
尝试在MySQL中的“IN”查询中使用Lucene ID列表失败，因为文档的数量可以是数百万，并且MySQL上有choke。
有关我们如何优化或执行此操作的任何见解？
另一个建议是第二个索引并使用MutliSearcher，但由于在更新或删除标记集时仍需要更新可能的百万行索引，我不完全确定如何去做。
答案 0 :(得分：0)
对于“批量更新”，您是否无法根据MySql表中的时间戳或类似内容对Lucene索引执行增量更新？我在solr中完成了这个，而不是直接在Lucene中完成，但是因为Solr是Lucene功能的包装器，所以这基本上是相同的（或者我假设......）。
答案 1 :(得分：0)
对于以下所有内容，假设您没有足够的RAM来完全保存整个集合。
索引技术的设计特别适用于读取数据远多于写入数量的情况。最好先分析相应的频率，从而量化“不断更新”。
如果更新频率太高，您可能想尝试直接使用数据库系统处理这部分搜索（如果MySQL不能完成这项工作，还有PostgreSQL;还有响应速度将取决于DB中的索引机制和可用于在内存中缓存它们的内存。
否则，您可能需要查看Solr（它不仅仅是Lucene的简单包装器，因为它提供了可能基于的功能，但使用Lucene本身并不可用）。
特别是：
根据更新的批量大小和提交/优化的性能交易，您可以使用不同的策略。对于大批量更新，可能更容易复制备用核心，批量更新，提交/优化和交换核心。但是，它不再是“近实时”（NRT）; NRT in Lucene的概念是本地的，并且直接取决于可用的RAM和集合大小。