分布式搜索方案選型
分布式搜索方案選型之一：Solr
我第一個了解到的分布式搜索框架是solr,它是由java開發的，基于lucene的分布式搜索引擎，提供了類似于webserver的編程接口，是一個比較成熟的搜索引擎，目前很多公司都在使用。很快我就部署了一個由4臺機器組成的solr集群，開始導公司的數據進去測試，導的數據為200萬。導入速度非常快。接下來就開始測試查詢效率，發現它是有緩存的，第一次查詢的時間基本上在80～150毫秒之間，第二次查由于有緩存，查詢時間基本上只需要18~35毫秒，可以說非常之快。它如何做到分布式？因為現在做的是集群，每臺機器存儲的信息是一樣的，怎樣做到把索引信息進行拆分？于是就到solr的官網查資料，原來solr是有索引分片功能的，可以通過分片把索引拆分成多個部分，分布到不同的機器上。知道怎樣做后就部署了兩個分片，測試后發現性能差不多，不過這樣還有問題就是怎樣做到索引分布的負載均衡？solr并沒有提供自帶的負載均衡，完全要自己編程實現，而且實現起來非常復雜，于是放棄了這個方案。
solr官網：http://lucene.apache.org/solr/
分布式搜索方案選型之二：Solandra
我在學校項目實踐時使用過solandra，它是一個基于solr和nosql數據庫cassandra的分布式搜索引擎。cassandra是由非死book開源的nosql數據庫，非死book的信箱搜索就是基于它實現的，它是基于列結構的，不同與關系數據庫。它的數學模型基于google的bigtable和Amazon的Dynamo，它的一個重要特性是沒有對外沒有中心節點，所以不會存在單點故障的問題，如果當前豬節點掛了，那么它余下的節點會進行自動投票，選舉出新的節點，這種特性未來必定是所有分布式系統的特性之一。它是當前熱門的nosql數據庫之一。
我看了下它的源碼，它從底層上重新實現了solr索引的存儲，把索引數據保存到cassandra中。它的這種實現方式給了我一個思路，就是lucene和nosql數據庫結合的可行性。由于solandra的零配置和自動發現的特性，很容易就部署起來，基本上一啟動服務就行了。我把原先用于測試的200萬數據導浸solandra中，它完全是黑盒模式的，你根本不知道你的數據分布到了那臺機器，你可以設置副本數來冗余數據，增加可用性和容錯性。
導完數據就對它進行性能測試，發現它的第一次查詢效率非常低，平均查詢時間4秒，比原生的solr低了很多，我猜測這里性能的差距主要是因為它把索引存儲cassandra中，原本的是直接保存到文件系統中的，現在是先從數據庫讀取到文件系統，多了一步，所以查詢效率有所差異，不過這樣的好處是真正實現了索引的分布式存儲。想到如果運行當中有臺機器掛了怎么辦？于是就開始測試它的容災性，結果發現，如果是一個3臺機的solandra機器，掛了其中一臺機還是可以查的，但是如果掛了兩臺機就搜索不出東西。這是因為我把索引的副本定義為2即集群中有兩份完整的索引。由于它索引不可見的黑盒特性我們并不知道它實際上索引的分布情況，這樣的話對后期索引的維護并不好。加上它查詢效率的問題，最終放棄該方案。
solandra項目主頁：https://github.com/tjake/Solandra
分布式搜索方案選型之三：SolrCloud
逛solr官網時無意發現了solrCloud這個開源項目，即solr云或叫分布式solr。它是基于solr的，使用zookeeper作為節點之間通信管理，它具有solr的所有特征，并提供索引分片的功能，不過這是要自己在配置文件中配置分片信息的。它好的地方是它是個實時的搜索引擎，即將推出的lucene4.0將實現實時搜索，而solrCloud就是基于開發中的lucene4.0的，目前solrCloud也是個本成品，本著試試的心態根據官方配置文檔搭建了
一個三臺機器，三個分片的分布式環境并對其進行測試。查詢效率與三臺機的solr集群差不多，都比較快。不過它的搜索接口很不好，你要在請求的url中指定分片的地址，如：http://localhost:8983/solr/collection1/select?shards=shard1,shard2,shard3。還有一個不好的地方是和solr一樣，建立索引時它沒有自動給你做負載均衡，如果你一直往分片1中插數據它也不管你的，你要自己編程去完成索引的均衡分配，這樣的話工作量就很大了。于是放棄solrCloud。
solrCloud項目主頁：http://wiki.apache.org/solr/SolrCloud
分布式搜索方案選型之四：Solr+Katta
一個叫katta的開源項目進入我的視線，它是一個分布式索引建立和管理工具，底層是hadoop的hdfs分布式文件系統，hadoop是當今云計算的熱門使用項目，由apatch開源是一個海量數據的處理和存儲方案，它的主要核心就是它的hdfs分布式文件存儲系統和mapreduce算法，它們分別是google論文中的gfs和mapreduce的開源實現。目前大公司的云計算平臺基本上都是基于它來搭建的。因為我之前在學校做的一個搜索引擎項目也是基于它的，所以我對它還是比較熟悉的，通過之前寫過的自動化部署腳本，我很快就搭起了一個由4臺機器組成的hadoop集群，每臺機160G的硬盤，乘于4的話就是640G了，而且這640G還是一個整體來的哦，以后如果空間不夠了，或者運算能力不夠了的話就直接加機器就行了，使用hadoop可以非常容易的提高整個系統的運算能力，google的核心技術之一就它了。而katta這個項目只是個lucene的索引管理工具，通過hadoop的mapreduce算法來批量建立索引，它的很大部分特性都是參考了nutch（一個基于hadoop的開源爬蟲項目），它提供的搜索功能很弱，只有最基本的查詢方法，一些高級的如：分組，統計，范圍查詢都沒有的，于是試試看看能否把它和solr進行集成，因為solr提供了很強大的搜索功能，網上搜索發現有人已經研究實現它了，就是這個帖子https://issues.apache.org/jira/browse/SOLR-1395，不過配置過程極其復雜，而且還要該很多的源碼，我看那帖子是從10年就開始了的，他們的討論已經持續一年多了，貌似還沒有什么結果，可見難度還是比較大的。就沒有深入去了解。
katta官網：http://katta.sourceforge.net/
分布式搜索方案選型之五（終篇）：Elasticsearch
最后發現了elasticsearch這個分布式搜索框架，我一看它的介紹就覺得，就是它了。它基本上所有我想要的特性都包含了，分布式搜索，分布式索引，零配置，自動分片，索引自動負載，自動發現，restful風格接口。于是就開始使用，部署了四臺機器，并把索引導了進去，我設置的分片為3，即把索引分成三片，副本為2，即有兩份完整的索引。
通過它的管理工具可以很清晰的看到它索引分布的情況：哪塊分布在那里，占用空間多少都可以看到，并且可以管理索引。還發現當一臺機掛了時，整個系統會對掛機里的內容重新分配到其它機器上，當掛掉的機重新加入集群時，又會重新把索引分配給它。當然，這些規則都是可以根據參數進行設置的，非常靈活。對它的搜索效率進行測試，查詢時間基本上維持在200毫秒左右，第二次搜索的話因為有緩存，所以和solr差不多。但經過詳細對比測試后發現，solr在建索引時的查詢性能非常之差，因為solr在建索引時會產生io的阻塞，造成搜索性能的下降，但elasticsearch不會，因為它是先把索引的內容保存到內存之中，當內存不夠時再把索引持久化到硬盤中，同時它還有一個隊列，是在系統空閑時自動把索引寫到硬盤中。
它的存儲方式有四種，1.像普通的lucene索引，存儲在本地文件系統中。2.存儲在分布式文件系統中，如freeds。3.存儲在hadoop的hdfs中。4.存儲在亞馬遜的s3云平臺中。它支持插件機制，有豐富的插件。比如和mongoDB couchDB同步的river插件，分詞插件，hadoop插件，腳本支持插件等。它有個第三方的solr接口模擬插件，使用這個插件可以使你原本基于 solr的系統無須改代碼直接切換到elasticsearch中，它還是個準實時的搜索引擎，所謂實時搜索引擎就是當你索引一個文檔后你搜索這個文檔立即就能搜索到。于是就決定使用這套分布式搜索框架。
后記：之前還簡單了解過LinkedIn的zoie，它也是個準實時搜索框架，不過它是不支持分布式的，現在LinkedIn開源出了基于zoie的分布式搜索框架sensei，這個沒研究過，有空可以試下。
elasticsearch solr對比評測：http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/
elasticsearch官網：http://www.elasticsearch.org/