对于经常变化的文档的Lucene索引策略

我正在将搜索功能集成到桌面应用程序中，我正在使用vanilla Lucene来执行此操作。该应用程序处理（可能数千个）POJO，每个POJO都有其自己的一组键/值属性。在我的应用程序和Lucene之间映射模型时，我最初想到为每个POJO分配一个文档并将属性添加为字段。这种方法在索引和搜索方面效果很好，但主要缺点是每当POJO更改其属性时，为了更新索引，我必须重新索引所有属性，即使是没有更改的属性。我一直在考虑改变我的方法，而是为每个属性创建一个Document，并将相同的ID分配给来自同一个POJO的所有文档。这样，当一个POJO属性发生变化时，我只更新其相应的Document，而不重新索引所有其他未更改的属性。我认为图表db Neo4J在编制索引时采用了类似的方法，但我并不完全确定。任何人都可以评论可能对性能，查询等造成的影响吗？对于经常变化的文档的Lucene索引策略

来源

2011-05-16 teto

我正在努力解决完全相同的问题。你发现了一个更好的解决方案来保持lucene和POJOs同步之间的数据？ – 2014-03-03 09:33:12

它从根本上取决于您想在搜索结果中作为文档返回的内容。

但索引是相当便宜。一个变化的POJO是否真的有这么多的属性，重新定义它们都是一个主要问题？

来源

2011-05-16 00:32:49 EJP

我只关心检索一个字段，POJO id，这是唯一实际存储在索引中的字段，其他所有字段都被分析但不存储。问题不在于POJO可能有很多属性（这可能会发生，但不会经常发生），但会更新许多POJO（这肯定会发生）。 – teto 2011-05-16 01:16:58

如果您只在每个搜索请求中搜索一个字段，将一个POJO拆分为几个文档将加速重新索引。但是如果搜索一个多个字段，POJO可能会出现很多次，这会导致另一个问题。其实，我同意EJP，建筑指数在小数据集中速度非常快。

来源

2011-05-18 12:37:51 zzzhc

对于经常变化的文档的Lucene索引策略

回答

相关问题