杂谈之SolrCloud这个坑货
杂谈之SolrCloud这个坑货
看《Solr In Action》时候看到对Solr不足的介绍有这么一段话:“One final limitation of Solr worth mentioning is its elastic scalability: the ability to automatically add and remove servers and redistribute content to handle load. While Solr scales well across servers, it doesn’t yet elastically scale by itself in a fully auto- matic way. ”于是不由得想到公司里部署的SolrCloud的一些问题。
1. SolrCloud的扩容问题,Solr对于集群的扩展上具有明显的劣势,无法做到动态的扩容以及数据的负载均衡。本人的公司是卖服务器的,比如之前卖了一台规格为5亿数据量的服务器,客户使用了一段时间发现数据量超过了5亿,那么它就会再买一台并和前面的那台组成集群。这个时候就涉及到扩容的问题,如何从单台变为集群,如何将一台5亿数据均衡到每台2.5亿上,如何保证扩容的时候服务器仍然进行在线的索引以及查询操作。这简直已经困扰了我半年了,一直都没有有效的策略,这是SolrCloud的短板,但是也是每一个使用Solr的必须去解决的。据说ElasticSearch在这方面做的很出色,接下来得学习下ElasticSearch以取取经。希望很快能找到解决措施再来这里接着写。
2. SolrCloud是依赖zookeeper的,我在对SolrCloud进行容灾和压力测试中,尝会出现SolrCloud的死机,或者shard要么recovery 失败要么就是一直在recovery,初步估计是根zookeeper通信有关(当然这跟我们对zookeeper的使用有关,我们的服务器同时运行solr和zookeeper,没办法谁叫我们是卖服务器的,能省则省),SolrCloud的容灾性能没有他说的那么好,最近有10台以上的集群需求,得充分把集群搞稳定了,甚是担忧。
3. 书上说,集群跟单机的查询性能比是如下,大多数情况是没错,但是Aggregation Overhead这部分的性能还是会很影响集群的查询的,比如极端的情况翻页+排序查询。(Query Speed on N+1 indexes) = Aggregation Overhead + (Query Speed on N indexes)/(N+1)
最新文章
- 配置ntp服务
- TeamCity : 安装 Server
- kali 忘记登录密码后重置的方法
- Beta项目冲刺–第四天
- sql执行顺序
- [ACM_数学] LA 3708 Graveyard [墓地雕塑 圈上新加点 找规律]
- 使用goldengate交付指定时间前的数据
- C 实现一个简易的Http服务器
- mysql数据库备份执行计划
- Linux驱动开发学习的一些必要步骤
- 4道过滤菜鸟的iOS面试题
- curl_setopt函数相关应用及介绍(转)
- ASP.Net MVC概念及基本
- POJ 2986 A Triangle and a Circle
- ant 配置 和测试 1
- 毕向东udp学习笔记3多线程聊天
- SCOI2019酱油记
- 使用Perfect Player观看电视直播
- python开发遇到的坑(1)xpath解析ValueError: Unicode strings with encoding declaration are not supported
- 理解java的三大特性之封装
热门文章
- Business Analysis and Essential Competencies
- 初识AM335X
- 【Deep Learning学习笔记】Dynamic Auto-Encoders for Semantic Indexing_Mirowski_NIPS2010
- 基于redis 内存数据库简单使用
- Qt知识点、疑难杂症的治疗
- 关于cocostudio加载UI json CCUIHELPER未声明问题
- NSDateFormatter 格式说明
- GridView点击行,选中模版列中CheckBox
- 通同select便签实现简单的二级联动
- table标签,认识网页上的表格