我目前有一个包含 4000 万个文档和 25 GB 索引大小的集合。集合每 n 分钟更新一次，因此删除的文档数量不断增加。 集合中的数据是 1000 多条客户记录的合并。每个客户的文档数量平均约为 100,000 条记录。
话虽这么说，但我正在尝试处理不断增长的已删除文档大小。由于索引大小不断增加，磁盘空间和内存都已用完。并希望将其缩小到可管理的大小。
我一直在考虑将数据拆分成多个核心，每个客户 1 个。这将使我能够轻松管理较小的集合，并且可以快速创建/更新集合。我担心的是收藏品的数量可能会成为一个问题。有关如何解决此问题的任何建议。
Solr: 4.9
Index size:25 GB
Max doc: 40 million
Doc count:29 million
谢谢
最佳答案
我有类似的问题，有多个客户和大索引数据。
我通过为客户创建一个单独的核心在 3.4 版中实现了它。
即每个客户一个核心。创建核心是某种创建索引或拆分数据，就像我们在分片的情况下所做的那样......
在这里，您将大型索引数据拆分为不同的较小段。
无论发生什么搜索，它都会在较小的索引段中进行..因此响应时间会更快..
到目前为止，我已经创建了将近 700 个内核，并且运行良好。
到目前为止，我在管理核心方面没有遇到任何问题......
我建议结合核心和分片...
它会帮助你实现目标
允许对每个具有不同行为的内核进行不同的配置，并且不会对其他内核产生影响。
您可以在每个核心上以不同方式执行更新、加载等操作。
关于solr 多核 vs 分片 vs 1 个大集合，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31691606/