雜談之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)