我第一個瞭解到的分佈式搜索框架是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雲平臺中。它支持插件機制，有豐富的插件。比如和 mongoDBcouchDB同步的river插件，分詞插件，hadoop插件，腳本支持插件等。它有個第三方的solr接口模擬插件，使用這個插件可 以使你原本基於solr的系統無須改代碼直接切換到elasticsearch中，它還是個準實時的搜索引擎，所謂實時搜索引擎就是當你索引一個文檔後你 搜索這個文檔立即就能搜索到。於是就決定使用這套分佈式搜索框架。
後記：之前還簡單瞭解過LinkedIn的zoie，它也是個準實時搜索框架，不過它是不支持分佈式的，現在LinkedIn開源出了基於zoie的分佈式搜索框架sensei，這個沒研究過，有空可以試下。
elasticsearchsolr對比評測：http://engineering.socialcast.com/2011/05/realtime-search-solr-vs-elasticsearch/
elasticsearch官網：http://www.elasticsearch.org/
轉自：http://blog.csdn.net/laigood12345?viewmode=contents