分佈式搜索方案選型之二：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