我有大约5000万个文档，90（已存储（20）+未存储（70））在单核中索引的schema.xml中的字段。查询非常复杂，并且需要分面和突出显示。在这90个字段中，有3-4个字段（全部存储）这些文件经常被上传。现在，更新这些字段通常需要再次填充所有字段，这是一项繁重的任务。如果我使用原子/部分更新，我们必须再次更新未存储的字段。
我们的解决方案：为了克服上述问题，我们决定使用SolrCloud和Join查询。我们将索引拆分为两个单独的索引/集合，即一个用于存储字段，一个用于非存储字段。文档与文档之间的关系是文档的id。我们将频繁更新的字段保存在存储索引中。通过这样做，我们能够利用原子更新。此外，为了克服云中Join查询的限制，我们在所有节点上对存储字段进行了分片和复制，但未存储字段未进行分片，而是在所有节点上进行了复制。我们有一个5节点集群，另外还有3个zookeeper示例。考虑到文档的数量，唯一值得关注的是，连接查询最终会降低搜索性能吗？如果是这样，我还可以考虑哪些其他选项。
2条答案
按热度按时间zzwlnbp81#
考虑到Joins，Solr更像是一个关系数据库。我在Lucidworks团队Solr and Joins中找到了一篇关于这方面的文章。甚至他们也说，如果你的解决方案包括Join的使用，那么这意味着你需要重新考虑这一点。
我想我有一个解决方案给你们。首先，忘记两个集合。你创建一个集合，你将有两个Solr文档为每个文档。现在一个文档将有存储字段，另一个有非存储字段。在更新的时候，你将更新有存储字段的文档，并在另一个文档上执行搜索相关的操作。
现在，您需要做的就是在查询时将两个文档合并为一个文档，这可以通过在Solr上编写服务层来完成。
zzzyeukh2#
我有一个问题，部分/原子更新和索引操作的字段在后台，我没有修改。这是不同的问题，但也许使用嵌套文档是值得思考的。
我正在检查嵌套文档的使用，以便将文档标题数据与要索引的文本内容分开，因为处理文本内容会消耗大量资源。根据文档，父文档和查尔兹作为块进行索引，并且必须始终一起进行索引。
这在https://solr.apache.org/guide/8_0/indexing-nested-documents.html中说明：
除了就地更新，整个块必须一起更新或删除，而不是单独更新或删除。对于某些应用程序，这可能会导致大量的额外索引，因此可能会破坏交易。
因此，只要您不能执行就地更新（在索引、存储和指令方面有自己的限制<copyField...>），使用嵌套文档似乎就不是一种有效的方法。