标签：style io ar os 使用 sp 数据 on 问题
看《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)
标签：style io ar os 使用 sp 数据 on 问题
原文地址：http://www.cnblogs.com/rcfeng/p/4075159.html
