分佈式搜索方案選型

一：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是由facebook開源的nosql數據庫，facebook的信箱搜索就是基於它實現的，它是基於列結構的，不一樣與關係數據庫。它的數學模型基於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/