Elasticsearch、MongoDB和Hadoop比較

IT界在過去幾年中出現了一個有趣的現象。不少新的技術出現並當即擁抱了「大數據」。稍微老一點的技術也會將大數據添進本身的特性，避免落大部隊太遠，咱們看到了不一樣技術之間的邊際的模糊化。假如你有諸如Elasticsearch或者Solr這樣的搜索引擎，它們存儲着JSON文檔，MongoDB存着JSON文檔，或者一堆JSON文檔存放在一個Hadoop集羣的HDFS中。你可使用這三種配置完成不少同養的事情。

ES是否能夠做爲一個NoSQL數據庫？粗看，這句話說的不太對，可是這是一個合理的場景。相似地，MongoDB在MapReduce的基礎上使用分片的技術一樣能夠完成Hadoop能夠作的工做。固然使用衆多功能，咱們能夠在Hadoop之上（Hive、HBase、Pig和一樣的一些）你也能夠用多種方式查詢Hadoop集羣中的數據。

那麼，咱們如今是否能說Hadoop、MongoDB和Elasticsearch這三個是徹底相同的呢？顯然不行！每一個工具都有自身最爲適用的場景，可是每一個都有至關的靈活性可以勝任不一樣的角色。如今的問題就變成「這些技術的最合適的使用場景是什麼？」。下面咱們來瞧瞧。

Elasticsearch已經超越了其最初的純搜索引擎的角色，如今已經增長了分析和可視化的特性——可是它的核心仍舊是一個全文搜索引擎。Elasticsearch創建在Lucene之上而且支持極其快速的查詢和豐富的查詢語法。若是你有數百萬的文檔須要經過關鍵詞進行定位時，Elasticsearch確定是最佳選擇。固然，若是你的文檔是JSON的，你就能夠把Elasticsearch看成一種輕量級的「NoSQL數據庫」。可是Elasticsearch不是一個合適的數據庫引擎，對複雜的查詢和聚合並非很強，儘管統計facet能夠提供必定的關於給定查詢的統計信息的支持。Elasticsearch中的facet主要是用來支持分面的瀏覽功能。

目前Elasticsearch已經增長了aggregation的功能 若是你在尋找一個對應於一個關鍵詞查詢的少許的文檔集合，而且要支持在這些結果中分面的導航，那麼Elasticsearch確定是最好的選擇。若是你須要進行更加複雜的計算，對數據執行服務端的腳本，輕鬆地運行MapReduce job，那麼MongoDB或者Hadoop就進入待選項中。

MongoDB是NoSQL數據庫，被設計成一個高可擴展，而且有自動分片的功能及一些額外性能優化的功能。MongoDB是一個面向文檔的數據庫，以JSON的形式進行數據的存儲（準確地說能夠稱爲BSON，對JSON進行了一些加強）——例如，一個native數據類型。MongoDB提供了一個文本索引類型來支持全文檢索，因此咱們能夠看到在Elasticsearch和MongoDB之間的界限，基本的關鍵詞搜索對應於文檔的集合。

MongoDB超過Elasticsearch的地方在於其對於服務器端js腳本的支持、聚合的管道、MapReduce的支持和capped collections。使用MongoDB，你可使用聚合管道來處理一個集合中的文檔，經過一個管道操做的序列來多步地對文檔進行處理。管道操做能夠生成全新的文檔而且從最終的結果中移除文檔。這是一個在檢索數據時的至關強的過濾、處理和轉化數據的特色。MongoDB也支持對一個數據collection進行map/reduce job的執行，使用定製的js函數進行操做的map和reduce過程。這就保證了MongoDB能夠對選定的數據執行任意類型的計算或者轉換的終極的靈活性。

MongoDB另外一個極其強大的特性稱之爲「Capped collections」。使用這個特性，用戶能夠定義一個collection的最大size——而後這個collection能夠被盲寫，而且會roll-over必須的數據來獲取log和其餘供分析的流數據。

你看到，Elasticsearch和MongoDB有一個可能的應用場景的重疊，它們不是一樣的工具。可是Hadoop呢？Hadoop就是MapReduce，這已經有MongoDB就地支持了啊！是否是還有一個專屬於Hadoop的場景，MongoDB就只是適合。

有！Hadoop是老MapReduce了，提供了最爲靈活和強大的環境來進行大量數據的處理，毫無疑問的是可以搞定不能使用Elasticsearch或者MongoDB處理的場景。

爲了更加清楚地認識到這點，看看Hadoop如何使用HDFS抽象存儲的——從關聯的計算特性上。經過HDFS中存儲的數據，任意job均可以對於數據進行運算，使用寫在覈心MapReduce API上，或者使用Hadoop流技術直接使用native語言編程。基於Hadoop 2和YARN，甚至核心編程模型都已經被抽象了，你再也不受到MapReduce的牽制了。使用YARN你能夠在Hadoop上實現MPI而且用那種方式寫job。

額外地，Hadoop生態系統提供了一個交錯的工具集合，創建在HDFS和核心MapReduce之上，來進行數據的查詢、分析和處理。Hive提供了一個相似SQL的語言，使得業務分析可使用一個用戶習慣的語法進行查詢。HBASE提供了一個基於Hadoop的面向列的數據庫。Pig和Sizzle提供了兩個更加不一樣的編程模型來查詢Hadoop數據。對存儲在HDFS中的數據的使用，你能夠繼承Mahout的機器學習的能力至你的工具集。當使用RHadoop時，你能夠直接使用R統計語言來對Hadoop數據執行高級的統計分析

因此，儘管Hadoop和MongoDB也有部分重疊的應用場景而且共同擁有一些有用的功能（無縫的水平擴展），可是二者之間仍是有着特定的場景。若是你僅僅想要經過關鍵字和簡單的分析，那麼Elasticsearch能夠完成任務；若是你須要查詢文檔，而且包含更加複雜的分析過程，那麼MongoDB至關適合；若是你有一個海量的數據，須要大量不一樣的複雜處理和分析，那麼Hadoop提供了最爲普遍的工具和靈活性。

一個亙古不變的道理就是選擇手頭最適合的工具作事。在大數據這樣的背景下，技術層出不窮，技術間的界限也是至關的模糊，這對咱們的選擇是一件至關困難的事情。正如你所見，特定的場景有着最適合的技術，這種差別性是至關重要的。最好的消息就是你不在限定在某一種工具或者技術上。依賴於你面對的場景，這就使得咱們可以構建一個整合的系統。例如，咱們知道Elasticsearch和Hadoop是能夠很好地一塊兒共事的，使用Elasticsearch快速的關鍵詞查詢，Hadoop job則能處理至關複雜的分析。

最終，採用了最大的搜索和細緻的分析來確認最爲合適的選擇。在選擇任何技術或者平臺時，須要仔細地驗證它們，理解這個東東適合哪些場景，哪裏能夠進行優化，須要作出哪些犧牲。從一個小小的預研項目開始，確認完畢後，再將技術應用到真正的平臺上，緩慢地升級到新的層級。

跟隨這些建議，你能夠成功地在大數據技術中遨遊，而且得到相應的回報。

文／Not_GOD（簡書做者） 原文連接：http://www.jianshu.com/p/2c7b0c76fa04 著做權歸做者全部，轉載請聯繫做者得到受權，並標註「簡書做者」。