數據庫對互聯網開發的重要性就不必多說了。作為大數據和AI時代的互聯網er，如果你還是只懂MySQL，那你可就火星大發了。下面給大家總結下每個互聯網er都必須懂的幾種數據庫產品：
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也有很多的短處，最明顯的就是字段類型無法修改、寫入性能較低和高硬件資源消耗。前邊講到ES會自動的替你建立索引，盡管這能給全文搜索以及聚合查詢帶來很多好處還能替你省了建索引這一麻煩事，但是這個特性也會帶來一堆問題。ES需要在創建字段前要預先建立Mapping，Mapping中包含每個字段的類型信息，ES需要根據Mapping為字段建立合適的索引。由于這個Mapping的存在，ES中的字段一但建立就不能再修改類型了。（例如，你建的數據表的某個字段忘了加全文搜索，你想臨時加上，但是表已經建好并且已經有很多數據了，這時候該怎么辦呢？不好意思，你只能把整個數據表刪了再重建一遍！）因此，ES在數據結構靈活度上高于MySQL但遠不如MongoDB。ES的缺點還不止這些，自動建立索引使得ES的寫入性能也收到了影響，要明顯低于MongoDB，并且ES的寫入還有一個更要命的問題，那就是默認1S的寫入延遲，也就是說你的數據在寫入后要至少等1S才能被查詢到。對于同樣的數據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：
