【问题标题】:How to store multiple distinct types of documents in Lucene如何在 Lucene 中存储多种不同类型的文档
【发布时间】:2015-12-23 08:48:43
【问题描述】:

我有一个现有的 Lucene 存储,其中包含数百万个文档,每个文档代表一个实体的元数据。我有几个 Id 字段(Id1、Id2 .. Id5),每个文档可以有零个或多个该字段的值。一次只能由这些 Id 之一查询索引。我已经独立地索引了这些字段,而且一切都很好。我最初选择使用 Lucene,因为它是迄今为止查询如此大量小文档的最快方法,我对我的决定感到满意。

但是现在我必须存储另一种类型的文档,它也代表实体的不同类型的元数据并具有 (Id1, Id2 .. Id5) 的值,并且也将由其中一个 Id 单独查询。现有元数据和这组新数据将相互独立地存储和查询。

如何通过 Id 查询 Lucene,但只能查询一种类型的文档。我可以想到几个选项,但我想知道那些知道的人从经验中推荐什么,以保持 Lucene 易于管理和快速。

  1. 使用单独的 Lucene 索引。这将避免该问题,因为文档类型是正交的。还有一个好处是能够分别从索引中读取和写入。
  2. 将新文档的字段 Id1..Idn 重命名为 XId1...XIdn。这样,一种类型的文档不会与另一种类型的文档具有相同的字段名称。这似乎更像是一种避免问题的解决方法,而不是实际的解决方案。
  3. 添加一个数字字段“类型”并将索引更改为(类型,Idx)。这种方法似乎很浪费,因为每个索引还必须包含类型。

我能够打破与现有设置的向后兼容性。如果我来添加另一种文档类型,如果可以重复使用该解决方案,那就太好了。

【问题讨论】:

  • 我会做 1. 但更多只是意见

标签: lucene lucene.net


【解决方案1】:

由于type 索引的选择性低,我肯定会拒绝第三个选项。 type 字段中只有 2 个不同的值,每个值都有数百万个文档。 Lucene 需要将这个庞大的发布列表与来自idN 索引的短发布列表合并,这仍然可以非常快,但确实很浪费。

前两种方法在查询阶段实际上是相同的,因为对于独立类型的文档,您有不同的术语和发布列表。差异将在索引阶段。管理多个独立索引需要更多的协调,并使代码更加困难。然而,如果您计划在不同的上下文中使用索引,这可能是一个好主意。例如:

  • 物理位置;
  • 备份策略;
  • 可用性要求;
  • 索引时间要求(从客户端更改文档到在索引中可见的时间)

否则,我会选择更简单和易于管理的第一个选项。

【讨论】:

  • 事实证明,我选择了选项 1,结果很好,因为后来我确实需要不同的备份策略和可用性要求。谢谢
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-03-18
  • 2018-07-01
  • 2023-03-31
相关资源
最近更新 更多