2

在我们的应用程序中，我们一直在使用 Lucene.Net 来索引大量数据。字段本身是可配置的，因此字段的名称和类型可以随着每次重建而改变。在每个文档中，我们可以有多个具有相同名称的字段以及不同数量的数字和文本字段。由于我们在当前的开发中投入了大量工作，因此更改为不同的搜索引擎是行不通的

事实是，在大多数情况下，它是一种魅力，但我们确实有一个我们似乎无法解决的困难。

假设我们要索引包含以下内容的文档“X”：

A 行 - 字段 1：4 + 字段 2：a
行 B - 字段 1：8 + 字段 2：b

我们将创建的索引将包含 4 个字段：

  • 文件 X：
    • 字段 1：4（数字）
    • 字段 2：a（文本）
    • 字段 1：8（数字）
    • 字段 2：b（文本）

（行 ID 不重要）

搜索Field1:[3 TO 6] AND Field2:b会对该文档产生影响。
但是，由行表示的字段之间的链接（链接 4 和“a”）消失了。

我们可以连接像 4_a 这样的值，但这会破坏我们的数字搜索，并且会要求客户端知道连接了哪些字段以获得正确的结果。这也会增加我们分析器的难度，因为对于每个字段，我们可以添加不同的分析器（主要用于语言目的）。

此外，我们可以使用相同的键为每一行创建一个单独的文档，并在搜索结果中添加一个 distinct，但这听起来不像是要走的路，是吗？它会大大增加文档的数量，因为我们将为我们现在创建的每个文档创建 20 到 100 个文档。我还没有在性能或可用性方面对此进行测试，因为当前的实现不允许我很容易地尝试这个:-)

有谁知道我如何强制 Lucene.Net 中的某些字段之间建立链接，但仍然保留一种单独搜索每个字段的方法？

4

2 回答 2

0

我个人不明白为什么增加文档数量会影响性能。至少在 Java 版本的 Lucene 中，大部分内存用于术语缓存 - 这是每个术语并且与文档计数无关（假设术语计数不改变）。无法详细说明可用性，因为这是特定于您的应用程序的。

要点是，一旦将行分组到文档中，就会丢失行关系信息。您可以通过添加额外的字段（例如rowInfoA:4_a, rowInfoB:8_b）来解决这个问题，但这似乎太麻烦并且实际上需要更多的内存。是的，您可以选择不索引而只存储这些辅助字段，但我（已给出信息）仍然更喜欢 1:1 行：文档映射。

于 2013-01-28T10:38:31.407 回答
0

一个问题是为链接添加另一个字段：

  • 文件 X：

    • 字段 1：4（数字）
    • 字段 2：a（文本）
    • 字段 1：8（数字）
    • 字段 2：b（文本）
    • 链接：4_a
    • 链接：8_b

另一个组合是添加一个类似的字段MyDocument:X并分别索引每一行，每一行都包含MyDocument其文档的一个字段。这将允许您稍后在流程中按文档进行过滤。

于 2013-01-28T21:06:37.940 回答