我有一个现有的 Lucene 存储，其中包含数百万个文档，每个文档都代表一个实体的元数据。我有几个 Id 字段（Id1、Id2 .. Id5），每个文档可以有零个或多个该字段的值。一次只能由这些 Id 之一查询该索引。我已经独立地对这些字段建立了索引，并且一切都工作得很好。我最初选择使用 Lucene，因为它是迄今为止查询如此大量小文档的最快方法，我对我的决定感到满意。
然而现在我必须存储另一种类型的文档，它也代表实体的不同类型的元数据，并且具有 (Id1, Id2 .. Id5) 的值，并且也将由这些 Id 之一单独查询。现有元数据和这组新数据将彼此独立地存储和查询。
如何通过 Id 查询 Lucene，但仅针对一种类型的文档。我可以想到一些选择，但我想知道知情者根据经验建议什么，以保持 Lucene 的可管理性和快速性。
- 使用单独的 Lucene 索引。这可以避免该问题，因为文档类型是正交的。还有一个好处是能够单独读取和写入索引。
- 将新文档的 Id1..Idn 字段重命名为 XId1...XIdn。这样，一种类型的文档将不会与另一种类型的文档具有相同的字段名称。这似乎更像是避免问题的解决方法，而不是实际的解决方案。
- 添加数字字段“Type”并将索引更改为（Type，Idx）。这种方法似乎很浪费，因为每个索引还必须包含类型。
我能够破坏与现有设置的向后兼容性。如果我来添加另一种文档类型时可以重用该解决方案，那就太好了。
我肯定会拒绝第三种选择，因为选择性低type指数。中只有 2 个不同的值type每一项都包含数百万份文档。 Lucene 需要将这个巨大的发布列表与来自的短发布列表合并idN索引，它仍然可以非常快，但确实很浪费。
前两种方法在查询阶段实际上是相同的，因为对于独立类型的文档，您有不同的术语和发布列表。差异将出现在索引阶段。管理多个独立索引需要更多的协调，并使代码变得更加困难。然而，如果您计划在不同的上下文中使用索引，这可能是一个好主意。例如：
- 物理位置;
- 备份策略；
- 可用性要求；
- 索引时间要求（从客户端更改文档到在索引中可见的时间）
否则，我会选择第一个选项，因为它更简单且易于管理。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
