我目前正在尝试确定 Solr 是否适合我。我有以下设置：
有主要的文档类型“博客”。然后有两个额外的文档类型“用户”和“类别”。这两个都是“博客”文档类型的父级。
现在在搜索“博客”文档时，我不仅要搜索这些字段（例如标题和内容），还要搜索父字段（用户>名称和类别>名称。
当然，我可以将其扁平化为 Solr 的单个文档，这将大大简化搜索。这样做的缺点是，当例如用户更新他们的名字，我必须浏览他们的所有博客文章并在 Solr 中更新相应的文档，而不是只更新单个文档。
当用户有另一个父母时，情况会变得更糟，我也需要在其上进行搜索。
您对如何处理这个用例有什么建议吗？也许我的 Google foo 不够好，但我发现的（块连接等）似乎并没有解决问题。
【问题讨论】：
标签： solr
绝对最高效和最简单的解决方案是将所有内容扁平化为单个文档。事实证明，这些关系并不像人们想象的那样经常更新，而且搜索的执行频率比文档更新的频率高。即使在一大组文档中相同的值之一发生变化，从最近的文档（对于博客）重新索引然后返回对于大多数用户来说似乎是相当高效的。假设您必须实际搜索这些值，而不仅仅是需要这些值 - 您可以在显示项目时从辅助存储中查找这些值（并且只需将永不更改的 id 存储在文档中）。
另一种选择是将其划分为多重搜索问题。一个集合用于博客文章，一个集合用于用户，一个集合用于类别。然后，您在每个集合中搜索相关数据并将其合并到您的搜索模型中。您还可以使用 [Streaming Expressions] 将大部分处理交给 Solr 集群。
我总是建议尽可能扁平化的原因是 Solr（和 Lucene）中的大多数特性都是为扁平化文档结构编写的，并且允许您充分利用可用的特性。由于 Lucene 在设计上是一个平面文档存储，因此大多数其他功能都需要特别注意以支持块连接和父/子关系，并且您最终需要进行大量试验才能获得所需的正确查询和功能集（如果可能）。如果文件是平面的，它就可以工作。
【讨论】：