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則能處理相當復雜的分析。

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

跟隨這些建議，你可以成功地在大數據技術中遨游，并且獲得相應的回報。

文章出處：http://itindex.net/detail/53171-elasticsearch-mongodb-hadoop