Solr架构设计和性能

Question

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

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

2-处理页面作为文件，这将导致更小的领域，但文件数量更多。

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

Answer 1

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

对于标题文档，我将按如下方式对模式进行建模：

1. 图书ID +页码+标题[字符串 - 唯一键]
2. 图书编号[整数]
3. 书名[tokenized text field]
4. 页码[TrieIntField]
5. 标题[标记化文本字段]
6. 该图书/标题/页面组合的内容[标记化文本字段]

您可能还有其他要捕获的属性，例如作者，发布日期，发布者，但是您没有在上面解释您拥有的其他信息，因此我将其留在此示例之外。

然后，文字查询可能涉及Book Name，Title和Content，您可能希望定义一个索引但未存储的单个字段，作为{{1的目标schema.xml中的声明允许在同一时间轻松搜索所有三个。

对于索引，在不了解被索引数据的更多信息的情况下，我会使用ICU Tokenizer和Snowball Porter Stemming Filter在文本字段上使用语言规范来处理非英语数据 - 假设所有书都是用同一种语言。如果是英语，标准令牌代替ICU。