如何在 Lucene 中存储多种不同类型的文档
How to store multiple distinct types of documents in Lucene
我有一个现有的 Lucene 存储，其中包含数百万个文档，每个文档代表一个实体的元数据。我有几个 Id 字段（Id1、Id2 .. Id5），每个文档的这个字段可以有零个或多个值。一次只能由这些 ID 之一查询该索引。我已经独立地为这些字段编制了索引，并且一切正常。我最初选择使用 Lucene，因为它是迄今为止查询如此大量小型文档的最快方式，我对自己的决定很满意。
但是现在我必须存储另一种类型的文档，它也代表实体的不同类型的元数据并具有 (Id1、Id2 .. Id5) 的值，并且这些 Id 中的一个也将单独查询。现有元数据和这组新数据将彼此独立存储和查询。
如何通过 Id 查询 Lucene 但仅针对一种类型的文档。我可以想到几个选项，但我想知道知情人士根据经验推荐什么，以保持 Lucene 的可管理性和快速性。
- 使用单独的 Lucene 索引。这将避免问题，因为文档类型是正交的。还有一个好处是能够分别从索引中读取和写入。
- 将新文档的字段 Id1..Idn 重命名为 XId1...XIdn。这样，一种类型的文档将不会与另一种类型的文档具有相同的字段名称。这似乎更像是一种避免问题的解决方法，而不是实际的解决方案。
- 添加一个数字字段 "Type" 并将索引更改为 (Type, Idx)。这种方法似乎很浪费，因为每个索引还必须包含类型。
我能够打破与现有设置的向后兼容性。如果我来添加其他文档类型，解决方案可以重复使用，那就太好了。
我肯定会拒绝第三个选项，因为 type 索引的选择性很低。 type 字段中只有 2 个不同的值，每个值都有数百万个文档。 Lucene 需要将这个巨大的发布列表与来自 idN 索引的短发布列表合并，这仍然可以非常快，但确实很浪费。
前两种方式在查询阶段实际上是相同的，因为对于独立类型的文档，您有不同的术语和发布列表。差异将在索引阶段。管理几个独立的索引需要更多的协调，并使代码更难一些。然而，如果您计划在不同的上下文中使用索引，这可能是个好主意。例如：
- 实际位置；
- 备份策略；
- 可用性要求；
- 索引时间要求（从客户端更改文档到在索引中可见的时间）
否则，我会选择第一个选项，因为它更简单易管理。
我有一个现有的 Lucene 存储，其中包含数百万个文档，每个文档代表一个实体的元数据。我有几个 Id 字段（Id1、Id2 .. Id5），每个文档的这个字段可以有零个或多个值。一次只能由这些 ID 之一查询该索引。我已经独立地为这些字段编制了索引，并且一切正常。我最初选择使用 Lucene，因为它是迄今为止查询如此大量小型文档的最快方式，我对自己的决定很满意。
但是现在我必须存储另一种类型的文档，它也代表实体的不同类型的元数据并具有 (Id1、Id2 .. Id5) 的值，并且这些 Id 中的一个也将单独查询。现有元数据和这组新数据将彼此独立存储和查询。
如何通过 Id 查询 Lucene 但仅针对一种类型的文档。我可以想到几个选项，但我想知道知情人士根据经验推荐什么，以保持 Lucene 的可管理性和快速性。
- 使用单独的 Lucene 索引。这将避免问题，因为文档类型是正交的。还有一个好处是能够分别从索引中读取和写入。
- 将新文档的字段 Id1..Idn 重命名为 XId1...XIdn。这样，一种类型的文档将不会与另一种类型的文档具有相同的字段名称。这似乎更像是一种避免问题的解决方法，而不是实际的解决方案。
- 添加一个数字字段 "Type" 并将索引更改为 (Type, Idx)。这种方法似乎很浪费，因为每个索引还必须包含类型。
我能够打破与现有设置的向后兼容性。如果我来添加其他文档类型，解决方案可以重复使用，那就太好了。
我肯定会拒绝第三个选项，因为 type 索引的选择性很低。 type 字段中只有 2 个不同的值，每个值都有数百万个文档。 Lucene 需要将这个巨大的发布列表与来自 idN 索引的短发布列表合并，这仍然可以非常快，但确实很浪费。
前两种方式在查询阶段实际上是相同的，因为对于独立类型的文档，您有不同的术语和发布列表。差异将在索引阶段。管理几个独立的索引需要更多的协调，并使代码更难一些。然而，如果您计划在不同的上下文中使用索引，这可能是个好主意。例如：
- 实际位置；
- 备份策略；
- 可用性要求；
- 索引时间要求（从客户端更改文档到在索引中可见的时间）
否则，我会选择第一个选项，因为它更简单易管理。