现状
当 solr 集群采用了 merger 的合并方式后,会把各台 solr 的结果合并到最终结果并输出,如下图所示:
这种是非常常规的做法,我想各路大神也早明白大概的情况了,那我也不多说了
集群的基本情况就是,因为收录了大量的新闻信息,某些新闻可能某一个小时间段内插入了大量数据,而某些时间段却木有,比如:“车祸“这一个关键字,在早上的9点1分1秒添加了 10W + 条数据,但其他时间段却一条都没有,但因为入索引时采用了轮询的方式,可以认为相同所有关键字在每台 solr 的数据量近似一样。简单一句话,每一个台solr 对应关键字的文档数差不多,但关键字在每一台 solr 对应关键字的时间段分布很不均匀。这很重要的目前的集群数据分布情况。
问题的提出
业务要求需要通过某关键字搜索出来的数据,并通过翻页拿出最新的 1W 的数据用于分析,比如:搜索“车祸”有 50W+条结果,每页 20条记录,然后通过翻页 page=1 , page=2 , page=3 这样子一直翻到 500 页拿到 1W 条数据(500 * 20 = 1W )
但这样子的问题又来了,通知这样子的翻页,性能比较低下,这样子遍历1W条记录需要 45秒左右的时间,因为这样子的分析是用户触发,意思是需要让用户在页面前等待 45 秒的时间,同时这样子造成了 merger 较大的 cpu 使用率。因为 merger 要进行合并排序,越往后翻页,merger 合并的数据量倍数增长。
1. 比如越往后翻页,性能表现越差,因为在 merger 排序,如果我翻到 start=100 ,rows=10 的话,表面上 merger 只返回了10条记录,但事实上单台 solr 却返回了 100 + 10 = 110 条记录到 merger ,导致越往后翻性能越差
2. 同样的道理,因为翻页越往后,从每台 solr 拿到的 rows 就越大(因为无论什么时候 start=0) ,
那读取的 docs 就更多了,导致了每台 solr 的搜索时间更长了。
综上所述,要解决这些问题我做了以下的调整
由上面的分析可以知道,其实翻页越往后,mereger 筛选掉的结果就越多,这些都是无用功。
所以我做了2个地方调整,如下所示
1,调整从 merger 传递到各 solr 的分页调整(如下图所示),注意红色框的东西,因为merger 合并时把前 n 页的数据都会拿出来并进行合并,所以我这里调整了一下,比如, solr 的数量是 6 ,前端需要 start=100,rows=10 则从merger 发布到各solr 的分页则变成 rows / 6 = 10 / 6 = 1.6 ,取为 2 ,则传给每一台 solr 的分页参数是 start= (100 / 10 ) * 2 , rows = 2 , 则从 merger 传到各 solr 的 rows 是 2 , start 是 20 . 那 merger 从每一台 solr 拿到的结果其实只有 2 个,merger 拿到的总数据是 2 X 6 = 12 个了,merger 只需要把这些结果合并起来不用参与任何的排序。
2,另外,修改 solr 的 merger 那部分的源码,在QueryComponent 类中,修改 mergeIds 的方法,使用里面的 ShardFieldSortedHitQueue 类变成普通的 LinkedList 类,只需要把各 Shards 简单添加起来了。如图:
OK,已经完成了。就算前端需要 start 值很大,但事实上,这样修改后 每台 solr 传给 rows 的只有几个,大大减少了 merger 在合并过程中的损失。同时业务的遍历仅仅拿到这个时间段的数据则可,至于有没有排序好,对于他们来说意义不大,因为他们要把这些数据进行整理。
文字虽然比较啰嗦,希望我能表达我能表达的东西出来就可以了。只要按着思路去做,代码方面不是什么问题。
优化后的性能对比
两种方式,在修改前后的效果对比,可以看到,新方式比之前的快了2到3倍,这都是得益于这种方式的效率。
欢迎转载,请注明 http://kernaling-wong.iteye.com/blog/2022742 by kernaling.wong
相关推荐
这些测试结果对于理解和优化 Solr 在实际应用中的性能具有重要的指导意义。在选择 Solr 部署模式时,需要根据具体的业务需求和预期的并发量来权衡单节点和集群的优劣。在需要高性能读写和高可用性的场景下,Solr ...
- **JVM配置**:Solr运行于Java虚拟机(JVM)之上,合理的JVM配置对提高性能至关重要。例如,设置合理的堆内存大小(`-Xms` 和 `-Xmx` 参数)以确保有足够的内存用于索引和缓存,避免频繁的垃圾回收。 - **HTTP缓存**...
在Solr中,Schema是核心组件之一,它定义了文档的结构和处理方式。`manageschema`功能允许用户通过Web界面动态地修改Schema,而无需直接编辑XML文件,简化了管理和维护过程。在这个"增加了分词器后的配置文件"中,...
### Solr性能优化关键知识点详解 #### 一、理解Solr环境与版本 - **环境配置**:在本文档中,我们关注的是基于Tomcat 6的Solr 3.5版本的部署与优化,这对于初学者来说是一个非常实用且稳定的组合。 - **Solr简介...
随着传统互联网和移动互联网的持续发展,网络带给我们的...目前一些搜索公司在公共互联网领域提供了很好的解决方案,但是企业或者政府机关内部相关信息往往需要应用独立的搜索系统,Solr Cloud则是很好的一个平台选择。
后端性能优化六种方式:缓存化、服务化、异步化等 在软件开发中,后端性能优化是一个非常重要的方面。一个高性能的后端系统可以提高用户体验、增加系统的可扩展性和可维护性、本降低系统的运营成本。今天我们将讨论...
"solr性能调优.mht"文件专门针对Solr的性能优化,包括索引优化、硬件配置、查询策略调整等方面,对于追求高效稳定运行的Solr系统来说,这部分内容是必不可少的。 这些文档和资料覆盖了Solr的多个方面,包括入门、...
solr在做检索的时候时常需要得知他的性能参数,此处使用8G内存,双核处理器测试的结果
最后,ES的一个不足之处在于文档编写可能不如Solr全面。由于ES和Solr都在快速的发展中,版本更新频繁,用户应该基于自己的需求进行实际测试,来判断哪个产品更适合自己的应用场景。对于ES而言,尽管它提供了很多先进...
- **性能优化**:Solr团队不断努力提升查询速度和索引效率,8.11.1版本可能包含了一些新的性能优化。 - **新功能**:可能引入了新的搜索特性,比如新的查询语法、更强大的分析器或者对最新技术标准的支持。 - **稳定...
Solr的多种性能优化技巧,如索引的性能优化、缓存的性能 优化、查询的性能优化、JVM和Web容器的优化,以及操作系统级别的优化。 拓展知识中首先讲解了Solr的一些比较生僻的知识点,如伪域、多语种索引支持、安全认证...
Solr作为一个功能强大的搜索引擎框架,能够在不同层面提供解决方案,不仅优化了搜索功能,还能够帮助解决大型网站架构中的性能问题。通过对Solr的深入理解和合理部署,可以有效提升用户体验,保证网站在高峰期的稳定...
Solr支持多种数据存储方式,如内存存储和硬盘存储,以及分布式索引和查询处理,使得它可以轻松应对大数据量的场景。 二、Solr的特性 1. 分布式搜索:Solr 6.2.0支持集群部署,可以将索引分片到多个节点,实现水平...
其中,Solrtest是FusionInsight中用于测试Solr性能和功能的工具,它可以方便地验证Solr集群的正确性和性能。 Java客户端是与Solr通信的一种常见方式,它允许开发者通过编写Java代码来执行索引操作、查询、更新和...
8. **搜索性能优化**:Solr提供了多种优化手段,包括使用倒排索引、缓存策略、查询优化器等,以提高查询速度和整体性能。 9. **安全与认证**:Solr 8.x引入了内置的安全性框架,包括Zookeeper的ACL和Solr的Role-...
Solr-9.0.0是该软件的最新版本,此版本可能包含了一些新的特性和改进,比如性能优化、新的查询语法、更强大的分析器等。 在Solr-9.0.0的压缩包中,通常会包含以下组件: 1. **bin** 文件夹:这个目录下有启动和...
使用Solr内置的Jetty服务器启动Solr (1)借助X Shell上传solr的安装包到/usr/local/目录下,使用 tar -zxvf命令进行解压. (2)使用内置的Jetty来启动Solr服务器只需要在example目录下,执行start.jar程序即可,...
9. **性能优化**:Solr可以通过调整缓存策略、使用NRT(Near Real Time)索引、优化查询执行计划等方式提高查询速度。 10. **安全与身份验证**:Solr 8.8.2可能包含安全模块,允许设置访问控制列表(ACLs)和角色...
#### 八、Solr 性能优化 - **索引优化**:包括索引合并、段合并等技术,提高搜索效率。 - **查询优化**:通过对查询语法的调整和优化,提升查询速度。 - **硬件升级**:增加内存、使用 SSD 等方式改善性能瓶颈。 ##...