杂谈之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)

上一篇:模糊搜索UISearchBar


下一篇:Ubuntu 设备 spark