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

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

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