我目前正试图弄清楚索尔是否适合我。我有以下设置：
有主要文件类型＆＃34;博客＆＃34;。然后还有两种其他文档类型＆＃34; user＆＃34;和＆＃34;类别＆＃34;。这两个人都是博客的父母。文件类型。
现在搜索＆＃34;博客＆＃34;文档，我不仅要搜索这些字段（例如标题和内容），还要搜索父字段（用户＆gt;名称和类别＆gt;名称。
当然，我可以将其归结为Solr的单个文档，这将大大简化搜索。但是，这样做的缺点是用户更新他们的名字，我必须浏览他们的所有博客文章并在Solr中更新文档，而不是仅更新单个文档。
当用户有另一个我需要搜索的父母时，情况会变得更糟。
您对如何处理此用例有任何建议吗？也许我的谷歌foo不够好，但我发现的（阻止加入等）似乎没有做到这一点。
答案 0 :(得分：0)
绝对最高性能和最简单的解决方案是将所有内容展平为单个文档。事实证明，这些关系并不像人们想象的那样经常更新，并且搜索的执行频率高于文档更新。即使在大量文档中相同的值之一发生变化，从最新文档（对于博客）重新索引然后向后转换对大多数用户来说也会显得相当高效。假设您必须实际搜索值并且不需要这些值 - 您可以在显示项目时从辅助存储中查找这些值（并且只在文档中存储永不更改的ID）。
另一种选择是将其划分为多搜索问题。一个博客文章集合，一个用户集合和一个类别集合。然后，您在每个集合中搜索相关数据，并将其合并到搜索模型中。您还可以使用[Streaming Expressions]将大部分处理交给Solr群集。
我总是建议尽可能扁平化的原因是Solr（和Lucene）中的大多数功能都是针对平面文档结构编写的，并且允许您充分利用可用的功能。由于Lucene的设计是一个平面文档存储，大多数其他功能需要特别注意以支持blockjoins和父/子关系，并且您最终需要进行大量实验以获得所需的正确查询和功能集（如果可能）。如果文件是扁平的，它就可以了。