1. 程式人生 > >Elasticsearch、MongoDB和Hadoop比較

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

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

跟隨這些建議,你可以成功地在大資料技術中遨遊,並且獲得相應的回報。