在我们的应用程序中，我们一直在与Lucene.Net合作索引大量数据。字段本身是可配置的，因此字段的名称和类型可以随每次重建而更改。在每个文档中，我们可以有多个具有相同名称和不同数量的数字和文本字段的字段。由于我们在当前的开发中投入了大量的工作，因此改用不同的搜索引擎是不行的。
事实上，在大多数情况下，它是一种魅力，但我们确实有一个困难，我们似乎没有解决。
假设我们要索引包含以下内容的文档“X”：
A行 - Field1：4 + Field2：a B行 - Field1：8 + Field2：b
我们要制作的索引将包含4个字段：
（行ID并不重要）
搜索 Field1：[3 TO 6]和Field2：b 会对此文档产生影响。
但是，行（由链接4和'a'）表示的字段之间的链接已消失。
我们可以连接像4_a这样的值，但是这会破坏我们的数字搜索，并且需要客户端知道连接哪些字段以获得正确的结果。它还会增加我们的分析器的难度，对于每个字段，我们可以添加不同的分析器（主要用于语言目的）。
此外，我们可以使用相同的键为每一行创建一个单独的文档，并为搜索结果添加一个不同的内容，但这听起来不像是要走的路，是吗？它会严重地增加文档的数量，就像我们在现在创建的每个文档的20-100个文档之间创建的那样。我没有对性能或可用性进行测试，因为目前的实现不允许我很容易地尝试这一点： - ）
有没有人知道我如何强制Lucene.Net中的某些字段之间的链接，但仍然可以单独搜索每个字段？
答案 0 :(得分：0)
我个人不明白为什么增加的文件数量会影响性能。至少在Lucene的Java版本中，大部分内存用于术语缓存 - 每个术语 并且与文档计数无关（提供术语计数不会改变）。无法详细说明可用性，因为这是针对您的应用的。
重点是，一旦将行分组到文档中，就会丢失行关系信息。你可以通过添加额外的字段（类似rowInfoA:4_a，rowInfoB:8_b）来解决这个问题，但这看起来太麻烦了，实际上需要更多的内存。是的，您可以选择不索引但只存储这些辅助字段，但我（有给定信息）仍然更喜欢1：1行：文档映射。
答案 1 :(得分：0)
一个重点是为链接添加另一个字段：
文件X：
另一个问题是添加类似MyDocument:X的字段并分别为每一行编制索引，每行包含一个MyDocument字段。这样您就可以在过程中稍后按文档进行过滤。