Solr 架构设计和性能答案

【问题标题】：Solr schema design and performanceSolr 架构设计和性能
【发布时间】：2014-09-29 19:29:38
【问题描述】：

我的书籍数据库包含三个实体：书籍、页面和标题（在页面中找到的标题）。我对架构设计中两种方法之间的性能感到困惑和担忧：

1- 将书籍作为文档处理，即书籍字段、具有多值的页面字段和具有多值的标题字段。在这种方法中，所有书籍数据都将在一个具有非常大字段的 Solr 文档中表示。

2- 将页面作为文档处理，这将导致更小的字段但更多的文档。

我试图查看this official resource，但我无法为我的问题找到明确的答案。

【问题讨论】：

发布每个表的描述以及您计划在 Solr 中搜索的内容。
@orangepips 很简单，书有很多页，然后页有很多标题。

标签： solr

【解决方案1】：

假设您要获取 Solr 结果并通过另一个应用程序呈现它们，我将制作最小的项目 - 标题 - 文档模型，这将更容易呈现结果出现的位置。这样做可以最大限度地减少您需要编写的应用程序代码量。如果您的用户直接查询 Solr，我可能会使用 Page 作为我的文档 - 大概您正在使用 Solr's highlighting feature 然后帮助您的用户确定他们的搜索词如何匹配。

对于 Title 文档，我将按如下方式建模架构：

图书 ID + 页码 + 标题 [字符串 - 唯一键]
图书 ID [整数]
书名[标记化文本字段]
页码 [TrieIntField]
标题[标记化文本字段]
该书/标题/页面组合的内容 [标记化文本字段]

您可能还想获取其他属性，例如作者、出版日期、出版商，但您没有在上面解释您拥有哪些其他信息，因此我在此示例中省略了这些信息。

然后，文本查询可能涉及Book Name、Title 和Content，您可能希望在其中定义一个已编入索引但未存储的字段，用作您的 schema.xml 中 <copyField/> 声明的目标以便同时轻松搜索所有三个。

对于索引，在不了解更多关于被索引的数据的情况下，我会使用 ICU Tokenizer 和 Snowball Porter Stemming Filter 以及文本字段上的语言规范来处理非英语数据 - 假设所有书籍都使用相同的语言.如果是英语，则使用 Standard Tokenizer 而不是 ICU。

【讨论】：

很好的解释，但是，您认为您建议的架构布局会导致半重复文档吗？！由于 Page 有很多标题，因此，如果我们有一个包含三个标题的页面，我们将得到三个除了标题字段之外具有相同数据的文档。在这种情况下，大量相同的数据（内容——我指的是页面内容）应该被索引 3 次。但是，您的分析使我采用了我在问题中提出的第二种设计，即设置 title multiValues 字段。
您绝对会有半重复的文档，但与关系数据库 IMO 相比，这是搜索索引的重点：非规范化您的数据以使搜索更容易。