Solr云性能下降，有数十亿个文档

我试图使用SolrCloud为大量简单文档编制索引，但遇到了一些性能和可伸缩性限制，我想知道可以对此做些什么

硬件方面，我有一个32节点的Hadoop集群，用于运行所有Solr碎片，每个节点有128GB内存。当前的SolrCloud设置分为4个独立的云，每个云包含32个碎片，因此每个云提供4个正在运行的碎片，或者每8个节点提供一个云。当前为每个碎片分配了6GB的堆大小。我希望避免增加堆内存，使Solr碎片有足够的内存在集群上运行其他MapReduce作业

我目前每天向这些云中插入文档的速率是两个云中各50亿个，第三个云中30亿个，第四个云中20亿个；但是，为了考虑容量，我们的目标是扩展解决方案以支持双倍于此数量的文档。为了索引这些文档，有一些MapReduce作业运行，生成Solr XML文档，然后通过SolrJ的CloudSolrServer接口提交这些文档。在测试中，我发现将每个云的活动并行插入次数限制在80次可以提供最佳性能，因为任何较高的插入次数都会带来递减的回报，这很可能是由于SolrCloud内部不断地对文档进行洗牌。从索引的角度来看，创建带日期的集合是为了保存一整天的文档，通常插入主要发生在当天（前几天仅允许搜索），计划在每个云中保留最多60天（或集合）。在最繁忙的云中，一个集合中的单个碎片索引当前占用30G磁盘空间，或者整个集合占用960G磁盘空间。文档正在自动提交，硬提交时间为4分钟（opensearcher=false），软提交时间为8分钟

从搜索的角度来看，用例是相当通用且简单的搜索类型：，因此无需调整系统以使用任何更高级的查询功能。因此，对我来说，最重要的是索引性能能够跟上输入速率

在最初的负载测试中，我能够实现每天100亿个文档/云的预期索引率，每天总计400亿个文档。然而，最初的负载测试是在相当空的云上完成的，只有几个小集合。现在已经有好几天的文档被索引了，我开始看到，在两个最大的云中，一旦云达到大约15个完整的集合（或每云大约800-1000亿个文档），索引性能就会急剧下降。根据当前的应用程序日志记录，我发现索引性能下降了40%。因此，我担心随着更多集合的添加，性能将如何保持

我向社区提出的问题是，是否有其他人有过以这种规模（数千亿）使用Solr的经验，以及是否有人观察到随着集合数量的增加，索引性能会下降。我的理解是，每个集合都是一个单独的索引，因此插入率应该保持不变。除此之外，在SolrCloud配置中还可以做哪些其他调整或更改来提高索引性能？我是否遇到了Solr能够处理的严重限制