如何在Lucene中存储多种不同类型的文档

and*_*wjs 4 lucene lucene.net

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

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

如何仅通过一种类型的ID通过ID查询Lucene。我可以考虑一些选择,但是我想从经验中知道那些建议,以便使Lucene易于管理和快速进行。

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

我可以打破与现有设置的向后兼容性。如果我要添加其他文档类型,那么可以重用该解决方案将是非常好的。

Den*_*nov 5

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

前两种方式在查询阶段实际上是相同的,因为您对独立类型的文档具有不同的术语和过帐列表。区别在于索引阶段。管理几个独立的索引需要更多的协调,并使代码更加困难。但是,如果您计划在不同的上下文中使用索引,则可能是一个好主意。例如:

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

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