数十亿文档导致Solr云性能下降

我正在尝试使用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能够处理的事情施加了严格的限制？