(轉載) MongoDB、ElasticSearch、Redis、HBase這四種熱門數據庫的優缺點及應用場景

MongoDB、ElasitcSearch、Redis、HBase是現今最火的四款NoSQL數據庫產品。在實際的開發中，這四種數據庫有什麼區別？我到底該選哪一個？想必這是不少互聯網開發都遇到過的難題。下面就給你們總結下這四種數據庫產品的特色和應用場景，但願可以幫助你更深入的理解這四種數據庫的特色，好幫助你做出正確的數據庫選擇。

MongoDB

MongoDB是當今最火爆的NoSQL數據庫。MongoDB最先在09年發佈，算得上是早期大數據時代的數據庫表明做了。隨着MongoDB的火爆，研發MongoDB的團隊還專門成立了MongoDB公司來對MongoDB進行維護和推廣，如今這個公司已經在納斯達克上市，市值達到十幾億美圓，算得上是技術變現的典範了。

MongoDB最大的特色是表結構靈活可變，字段類型能夠隨時修改。MongoDB中的每一行數據只是簡單的被轉化成Json格式後存儲，所以MongoDB中壓根沒有MySQL中表結構這樣的概念，你能夠直接簡單粗暴的將任意結構的數據塞入同一個表中，壓根沒必要考慮表結構的限制，更沒必要像MySQL同樣由於要修改數據表結構而大費周折。簡而言之，往MySQL寫數據像是在作填空題，你寫入的數據必須與最先定義的表結構一致，而往MongoDB寫數據就像是在作問答題，想怎麼寫就怎麼寫，這靈活度不要爽太多。

說完MongoDB的優勢也該說一說它的缺點了。MongoDB不須要定義表結構這個特色給表結構的修改帶來了極大的方便，可是也給多表查詢、復瑣事務等高級操做帶來了阻礙。所以，若是你的數據的邏輯結構很是複雜，常常須要進行復雜的多表查詢或者事務操做，那顯然仍是MySQL這類關係型數據庫更合適。

得益於MongoDB的這些特色，MongoDB很適合那些表結構常常改變，數據的邏輯結構沒又沒那麼複雜不須要多表查詢操做，數據量又比較大的應用場景。例如，有一個遊戲應用，須要存儲每一個用戶的信息，用戶分爲法師、戰士等具備不一樣屬性的角色，還有裝備、技能等不少結構複雜的信息，遊戲每次更新還可能會引入不少新的用戶屬性，這時若是你使用MySQL，那麼你可能須要創建不少個表，定義不少個表結構，而且遊戲的每次更新也可能會給你帶來重定義表結構等一堆麻煩事，而若是使用MongoDB則這些麻煩通通不存在，由於你能夠定義只一張表即可以容納全部的信息，並且能夠隨時根據新的需求增減字段。

Redis

Redis是如今最熱門的key-value數據庫。它與MongoDB同在2009年發佈，也一樣是早期大數據時代的數據庫表明做。

Redis的最大特色固然就是key-value存儲所帶來的簡單和高性能了。所謂key-value存儲，就是每一條記錄只包含一個用於查詢數據的Key，以及與之對應的存儲數據的value，就如同現實生活中的門牌號與住戶，而沒有諸如表、字段這些常規數據庫中必需有的複雜概念，全部的查詢都僅僅依賴於key值。所以，key-value數據庫可謂是數據庫中數據結構最簡單的一種，也得益於這種簡單的結構，再加上Redis會把全部數據加載到內存中的，Redis能獲得遠高於MongoDB這類常規數據庫的讀寫性能。固然，Redis的功能還不止key-value存儲這麼簡單，相較它的key-value前輩Memcached，Redis還支持數據持久化，list、set等多種數據結構，主從複製備份等一些列功能，所以Redis絕對稱得上是key-value數據庫中功能最全面、最簡單易用的款。

Redis的key-valule存儲帶來了性能這個優點，可是也給複雜查詢帶來了不少侷限。因爲閹割掉了數據表、字段這樣的重要特性，且全部的查詢都依賴key，所以Redis沒法提供常規數據庫所具有的多列查詢、區段查詢等複雜查詢功能。同時，因爲Redis須要把數據存在內存中，這也大大限制了Redis可存儲的數據量，這也決定了Redis難以用在數據規模很大的應用場景中。

Redis犧牲了常規數據庫中的數據表、複雜查詢等功能，換來了很大的性能提高，特別適合那些對讀寫性能要求極高，且數據表結構簡單（key-value、list、set之類）、查詢條件也一樣簡單的應用場景。若是你的數據表結構還挺複雜，你還常常須要作一些複雜查詢操做，那你最好仍是老老實實用MongoDB或者SQL吧。

ElasticSearch

 

 

相較於MongoDB和Redis，晚一年發佈的ES可能知名度要低一些，可是ES在搜索引擎領域的名聲絕對是是響噹噹的。相較於其餘高大上的數據庫產品，ES的出身要屌絲不少。ES的建立者Shay Banon曾經是一個失業的屌絲程序員，在無事可幹的時候爲了方便老婆搜索食譜而建立了ES（固然，當時還不叫ES）。不料無意插柳柳成蔭，成就了今天最熱門的搜索引擎數據庫，果真妹子纔是程序員工做的最大動力啊！ES也專門成立了本身的Elastic公司已經得到數億美金融資，當年的屌絲程序員Shay Banon也早已逆襲成爲CEO並走上人生巔峯。諸位程序員看官讀完這個故事是否是也已經開始心裏澎湃的想象本身出任CEO迎娶白富美那一天了？

 

ES的特色，正如其名，那就是搜索。嚴格的說，ES不是一個數據庫，而是一個搜索引擎，ES的方方面面也都是圍繞搜索設計的。ES支持全文搜索，這裏簡單解釋下什麼是全文搜索：對於「我在北京的一家互聯網公司工做」這樣的數據，若是你搜索「北京」、「互聯網」、「工做」這些關鍵詞都能命中這條數據的話，這就是全文搜索，你天天都在用的百度、Google都屬於全文搜索。值得一提的是，ES的全文搜索對中文也有很好的支持（單是中文分詞器就有不少種），絕對可以知足國內大多數人的全文搜索需求。除了搜索以外，ES還會自動的替你對全部字段創建索引，以實現高性能的複雜聚合查詢，所以只要是存入ES的數據，不管再複雜的聚合查詢也能夠獲得不錯的性能，並且你不再用爲如何創建各類複雜索引而頭痛了。

說了這麼多ES的優勢，你是否是以爲ES簡直萬能了？惋惜不是的，ES也有不少的短處，最明顯的就是字段類型沒法修改、寫入性能較低和高硬件資源消耗。前邊講到ES會自動的替你創建索引，儘管這能給全文搜索以及聚合查詢帶來不少好處還能替你省了建索引這一麻煩事，可是這個特性也會帶來一堆問題。ES須要在建立字段前要預先創建Mapping，Mapping中包含每一個字段的類型信息，ES須要根據Mapping爲字段創建合適的索引。因爲這個Mapping的存在，ES中的字段一但創建就不能再修改類型了。（例如，你建的數據表的某個字段忘了加全文搜索，你想臨時加上，可是表已經建好而且已經有不少數據了，這時候該怎麼辦呢？很差意思，你只能把整個數據表刪了再重建一遍！）所以，ES在數據結構靈活度上高於MySQL但遠不如MongoDB。ES的缺點還不止這些，自動創建索引使得ES的寫入性能也收到了影響，要明顯低於MongoDB。對於一樣的數據ES佔用的存儲空間也要明顯大於MongoDB（建那麼多索引能不佔空間嗎？），對硬件資源的消耗也是很是厲害，大數據量下64G內存+SSD基本是標配，算得上是數據庫中的貴族服務了，所以若是你的老闆很小氣，對於ES的選用可要慎重嘍！

ES的全文搜索特性使它成爲構建搜索引擎的利器。除此以外，ES很好的支持了複雜聚合查詢這一特色還使得ES很是適合拿來做數據分析使用。其實，ES還專門作了與本身配套的ELK套裝，給你提供從日誌收集到數據可視化分析的一條龍服務，絕對是構建高大上數據分析平臺的利器。可是，ES的高成本和低寫入性能這些缺點也註定了它不適合用在那些數據價值不高、對寫入性能有要求、數據量大而成本受限的場景中。

HBase

 

HBase是Hadoop項目的一部分，並且是當年谷歌大數據三駕馬車之一的BigTable方案的實現，所以絕對算得上是大數據時代最有表明性的技術之一了。

做爲Hadoop系列產品之一，HBase也繼承了Hadoop項目的最大優勢，那就是對海量數據的支持，以及極強的橫向（存儲容量）擴展能力。和Redis相似，HBase也須要爲每一行數據定義一個key，以後全部的查詢都依賴這個key進行。可是不一樣的地方在於，HBase中的一行數據還能夠有很是多的列項（相似MongoDB字段），數據會按照列進行分組和存儲，同一列的數據存儲在同一個地方，這也是HBase被稱爲列式存儲數據庫的緣由。其實從本質上來講，HBase至關因而把邏輯上的一張大表按照列族分拆成若干張小表分別進行存儲，不只是列，數據的行數到達必定數量後表也會再被拆分。所以，HBase可以把巨大的表分佈到不少臺機器上，從而容納規模近乎無限的數據。同時，對HBase進行橫向擴展也很是方便，你基本只須要添加新的機器，而不用對數據作任何改動，就能夠實現數據庫容量線性的增加，這在其餘SQL數據庫中是難以作到的（儘管其餘數據庫也有諸如MongoDB分片集羣之類的功能幫助你進行數據規模橫向擴展，可是不管是在實施的難度上仍是在對數據的影響方面這些都沒法跟HBase相提並論。）

HBase的列式存儲特性帶來了海量數據規模的支持和極強的擴展能力，可是也給數據的讀取帶來很大的侷限。因爲只有同一列族的數據纔會被存放在一塊兒，並且全部的查詢都必需要依賴Key，這就使得不少複雜查詢難以進行。例如，若是你的查詢條件涉及多個列項，或者你沒法獲取要查詢數據的key，那麼查詢效率將會很是低下。所以，HBase僅僅適合。

HBase的列式存儲特色帶來了對海量數據的容納能力，所以很是適合數據量極大，查詢條件簡單，列與列之間聯繫不大的輕查詢應用場景。最典型的好比搜索引擎所使用的網頁數據庫。HBase不適合數據結構複雜，且須要複雜查詢的應用場景。另外值得一提的是，HBase是很重的一款產品，須要依賴不少的Hadoop組件，所以若是你的數據規模不大，那就徹底不必殺雞用牛刀，MongoDB這類產品徹底能夠更好的知足你的需求。

總結

以上四種數據庫是當今NoSQL中最火爆的幾款，掌握了它們，你基本就能cover住互聯網開發中的絕大多數數據存儲需求。這裏還想強調的一點是，如同買衣服同樣，沒有最好的數據庫，只有最適合你的應用場景的數據庫，所以選用一款數據庫前必定要想清楚本身的應用場景是否合適。再給你們總結下這些數據庫的適用場景：

若是你對數據的讀寫要求極高，而且你的數據規模不大，也不須要長期存儲，選redis；

若是你的數據規模較大，對數據的讀性能要求很高，數據表的結構須要常常變，有時還須要作一些聚合查詢，選MongoDB；

若是你須要構造一個搜索引擎或者你想搞一個看着高大上的數據可視化平臺，而且你的數據有必定的分析價值或者你的老闆是土豪，選ElasticSearch；

若是你須要存儲海量數據，連你本身都不知道你的數據規模未來會增加多麼大，那麼選HBase。

四種數據庫的對比

最後，再給你們來個更加形象的對比：

Redis：

MongoDB：

 

HBase：

 

ElasticSearch：

 

轉自 https://zhuanlan.zhihu.com/p/37964096