我目前拥有一个包含4000万份文档且索引大小为25 GB的单个集合。集合每n分钟更新一次，因此删除的文档数量不断增加。 该集合中的数据是1000多个客户记录的合并。每位客户的文档数量平均约为100,000条记录。
现在说，我试图了解不断增长的删除文档大小。由于索引大小不断增加，磁盘空间和内存都在用完。并希望将其减少到可管理的大小。
我一直在考虑将数据分成多个核心，每个客户1个。这样我就可以轻松管理较小的集合，并且可以快速创建/更新集合。我担心的是收藏数量可能会成为一个问题。有关如何解决此问题的任何建议。
Solr: 4.9
Index size:25 GB
Max doc: 40 million
Doc count:29 million
由于
答案 0 :(得分：2)
我有类似的问题，有多个客户和大索引数据。
我通过为客户创建一个单独的核心来实现3.4版本。
即每个客户一个核心。创建核心是某种创建索引或分割数据的方式，就像我们在分片时一样......
在这里，您要将较大的索引数据拆分为不同的较小段。
无论搜索将会发生什么，它都将携带较小的索引段..因此响应时间会更快..
我现在已经创建了近700个核心，并且它对我运行良好。
截至目前，我没有遇到管理核心问题......
我建议使用核心和分片的组合......
它将帮助您实现
允许为具有不同行为的每个核心配置不同的配置，并且不会对其他核心产生影响。
您可以以不同方式对每个核心执行更新，加载等操作。