我正在尝试使用SolrCloud索引大量简单文档，并且遇到了一些性能和可伸缩性限制，并且想知道可以做些什么。
硬件方面，我有一个32节点的Hadoop集群，我用它来运行所有的Solr分片，每个节点都有128GB的内存。当前的SolrCloud设置被分成4个单独的32个分片的单独云，从而每个云提供4个运行分片或每8个节点分配一个云。每个分片当前分配了6GB的堆大小。我宁愿避免为Solr分片增加堆内存，以便在集群上运行其他MapReduce作业。
我目前每天在这些云中插入的文件的比率是两个云中每个50亿，第三个是30亿，第四个是20亿;但是，考虑到容量，目标是扩展解决方案以支持双倍数量的文档。要为这些文档编制索引，可以运行生成Solr XML文档的MapReduce作业，然后通过SolrJ的CloudSolrServer接口提交这些文档。在测试中，我发现将每个云的活动并行插入数量限制为80可以获得最佳性能，因为任何更高的性能都会导致收益递减，这很可能是由于文档在内部不断改组到SolrCloud。从索引的角度来看，正在创建过时的集合来保存一整天的文档，并且通常插入主要发生在当天（前几天只允许搜索）并且计划最多可以保留60天（或者每个云中的集合）。最繁忙的云中一个集合中的单个分片索引当前占用整个集合的30G磁盘空间或960G。文档正在自动提交，提交时间为4分钟（opensearcher = false），软提交时间为8分钟。
从搜索角度来看，用例是相当通用且简单的类型搜索：，因此无需调整系统以使用任何更高级的查询功能。因此，对我来说最重要的是让索引性能能够跟上输入的速度。
在初始负载测试中，我能够实现每天每天云计算100亿个文档的预计索引率，总计每天400亿。但是，初始负载测试是在相当空的云上完成的，只有几个小集合。现在已经有几天的文档被编入索引，一旦云在两个最大的云中达到大约15个完整集合（或每个云大约80-100亿个文档），我开始看到索引性能下降相当急剧下降。根据当前的应用程序日志记录，我发现索引性能下降了40％。因此，我担心随着更多集合的添加，性能将如何保持。
我向社区提出的问题是，是否有其他人有过使用Solr这种规模的经验（数千亿），并且如果有人观察到索引性能随着收集数量的增加而下降。我的理解是每个集合都是一个单独的索引，因此插入率应保持不变。除此之外，还可以在SolrCloud配置中进行哪些其他调整或更改以提高索引性能的速度？我是否对Solr能够处理的事情施加了严格的限制？