數(shù)據(jù)庫對互聯(lián)網(wǎng)開發(fā)的重要性就不必多說了嗅剖。作為大數(shù)據(jù)和AI時代的互聯(lián)網(wǎng)er，如果你還是只懂MySQL嘁扼，那你可就火星大發(fā)了信粮。下面給大家總結(jié)下每個互聯(lián)網(wǎng)er都必須懂的幾種數(shù)據(jù)庫產(chǎn)品：

MongoDB

image

MongoDB是當(dāng)今最火爆的NoSQL數(shù)據(jù)庫。MongoDB最早在09年發(fā)布趁啸，算得上是早期大數(shù)據(jù)時代的數(shù)據(jù)庫代表作了强缘。隨著MongoDB的火爆，研發(fā)MongoDB的團隊還專門成立了MongoDB公司來對MongoDB進行維護和推廣不傅，現(xiàn)在這個公司已經(jīng)在納斯達克上市旅掂，市值達到十幾億美元，算得上是技術(shù)變現(xiàn)的典范了访娶。

MongoDB最大的特點是表結(jié)構(gòu)靈活可變商虐，字段類型可以隨時修改。MongoDB中的每一行數(shù)據(jù)只是簡單的被轉(zhuǎn)化成Json格式后存儲崖疤，因此MongoDB中壓根沒有MySQL中表結(jié)構(gòu)這樣的概念秘车，你可以直接簡單粗暴的將任意結(jié)構(gòu)的數(shù)據(jù)塞入同一個表中，壓根不必考慮表結(jié)構(gòu)的限制劫哼，更不必像MySQL一樣因為要修改數(shù)據(jù)表結(jié)構(gòu)而大費周折叮趴。簡而言之，往MySQL寫數(shù)據(jù)像是在做填空題沦偎，你寫入的數(shù)據(jù)必須與最早定義的表結(jié)構(gòu)一致疫向，而往MongoDB寫數(shù)據(jù)就像是在做問答題，想怎么寫就怎么寫豪嚎，這靈活度不要爽太多搔驼。

說完MongoDB的優(yōu)點也該說一說它的缺點了。MongoDB不需要定義表結(jié)構(gòu)這個特點給表結(jié)構(gòu)的修改帶來了極大的方便侈询，但是也給多表查詢舌涨、復(fù)雜事務(wù)等高級操作帶來了阻礙。因此扔字，如果你的數(shù)據(jù)的邏輯結(jié)構(gòu)非常復(fù)雜囊嘉，經(jīng)常需要進行復(fù)雜的多表查詢或者事務(wù)操作，那顯然還是MySQL這類關(guān)系型數(shù)據(jù)庫更合適革为。

得益于MongoDB的這些特點扭粱，MongoDB很適合那些表結(jié)構(gòu)經(jīng)常改變，數(shù)據(jù)的邏輯結(jié)構(gòu)沒又沒那么復(fù)雜不需要多表查詢操作震檩，數(shù)據(jù)量又比較大的應(yīng)用場景琢蛤。例如蜓堕，有一個游戲應(yīng)用，需要存儲每個用戶的信息博其，用戶分為法師套才、戰(zhàn)士等具有不同屬性的角色，還有裝備慕淡、技能等很多結(jié)構(gòu)復(fù)雜的信息背伴，游戲每次更新還可能會引入很多新的用戶屬性，這時如果你使用MySQL峰髓，那么你可能需要建立很多個表傻寂，定義很多個表結(jié)構(gòu)，并且游戲的每次更新也可能會給你帶來重定義表結(jié)構(gòu)等一堆麻煩事儿普，而如果使用MongoDB則這些麻煩統(tǒng)統(tǒng)不存在崎逃，因為你可以定義只一張表便可以容納所有的信息，而且可以隨時根據(jù)新的需求增減字段眉孩。

Redis

image

Redis是現(xiàn)在最熱門的key-value數(shù)據(jù)庫个绍。它與MongoDB同在2009年發(fā)布，也同樣是早期大數(shù)據(jù)時代的數(shù)據(jù)庫代表作浪汪。

Redis的最大特點當(dāng)然就是key-value存儲所帶來的簡單和高性能了巴柿。所謂key-value存儲，就是每一條記錄只包含一個用于查詢數(shù)據(jù)的Key死遭，以及與之對應(yīng)的存儲數(shù)據(jù)的value广恢，就如同現(xiàn)實生活中的門牌號與住戶，而沒有諸如表呀潭、字段這些常規(guī)數(shù)據(jù)庫中必需有的復(fù)雜概念钉迷，所有的查詢都僅僅依賴于key值。因此钠署，key-value數(shù)據(jù)庫可謂是數(shù)據(jù)庫中數(shù)據(jù)結(jié)構(gòu)最簡單的一種糠聪，也得益于這種簡單的結(jié)構(gòu)，再加上Redis會把所有數(shù)據(jù)加載到內(nèi)存中的谐鼎，Redis能得到遠高于MongoDB這類常規(guī)數(shù)據(jù)庫的讀寫性能舰蟆。當(dāng)然，Redis的功能還不止key-value存儲這么簡單狸棍，相較它的key-value前輩Memcached身害，Redis還支持?jǐn)?shù)據(jù)持久化，list草戈、set等多種數(shù)據(jù)結(jié)構(gòu)塌鸯，主從復(fù)制備份等一些列功能，因此Redis絕對稱得上是key-value數(shù)據(jù)庫中功能最全面唐片、最簡單易用的款丙猬。

Redis的key-valule存儲帶來了性能這個優(yōu)勢丢习，但是也給復(fù)雜查詢帶來了很多局限。由于閹割掉了數(shù)據(jù)表淮悼、字段這樣的重要特性，且所有的查詢都依賴key揽思，因此Redis無法提供常規(guī)數(shù)據(jù)庫所具備的多列查詢袜腥、區(qū)段查詢等復(fù)雜查詢功能。同時钉汗，由于Redis需要把數(shù)據(jù)存在內(nèi)存中羹令，這也大大限制了Redis可存儲的數(shù)據(jù)量，這也決定了Redis難以用在數(shù)據(jù)規(guī)模很大的應(yīng)用場景中损痰。

Redis犧牲了常規(guī)數(shù)據(jù)庫中的數(shù)據(jù)表福侈、復(fù)雜查詢等功能，換來了很大的性能提升卢未，特別適合那些對讀寫性能要求極高肪凛，且數(shù)據(jù)表結(jié)構(gòu)簡單（key-value、list辽社、set之類）伟墙、查詢條件也同樣簡單的應(yīng)用場景。如果你的數(shù)據(jù)表結(jié)構(gòu)還挺復(fù)雜滴铅，你還經(jīng)常需要做一些復(fù)雜查詢操作戳葵，那你最好還是老老實實用MongoDB或者SQL吧。

ElasticSearch

image

相較于MongoDB和Redis汉匙，晚一年發(fā)布的ES可能知名度要低一些拱烁，但是ES在搜索引擎領(lǐng)域的名聲絕對是是響當(dāng)當(dāng)?shù)摹Ｏ噍^于其他高大上的數(shù)據(jù)庫產(chǎn)品噩翠，ES的出身要屌絲很多戏自。ES的創(chuàng)建者Shay Banon曾經(jīng)是一個失業(yè)的屌絲程序員，在無事可干的時候為了方便老婆搜索食譜而創(chuàng)建了ES（當(dāng)然绎秒，當(dāng)時還不叫ES）浦妄。不料無心插柳柳成蔭，成就了今天最熱門的搜索引擎數(shù)據(jù)庫见芹，果然妹子才是程序員工作的最大動力凹谅Α！ES也專門成立了自己的Elastic公司已經(jīng)獲得數(shù)億美金融資玄呛，當(dāng)年的屌絲程序員Shay Banon也早已逆襲成為CEO并走上人生巔峰阅懦。諸位程序員看官讀完這個故事是不是也已經(jīng)開始內(nèi)心澎湃的想象自己出任CEO迎娶白富美那一天了？

image

ES的特點徘铝，正如其名耳胎，那就是搜索惯吕。嚴(yán)格的說，ES不是一個數(shù)據(jù)庫怕午，而是一個搜索引擎废登，ES的方方面面也都是圍繞搜索設(shè)計的。ES支持全文搜索郁惜，這里簡單解釋下什么是全文搜索：對于“我在北京的一家互聯(lián)網(wǎng)公司工作”這樣的數(shù)據(jù)堡距，如果你搜索“北京”、“互聯(lián)網(wǎng)”兆蕉、“工作”這些關(guān)鍵詞都能命中這條數(shù)據(jù)的話羽戒，這就是全文搜索，你每天都在用的百度虎韵、Google都屬于全文搜索易稠。值得一提的是，ES的全文搜索對中文也有很好的支持（單是中文分詞器就有很多種）包蓝，絕對能夠滿足國內(nèi)大多數(shù)人的全文搜索需求驶社。ES通過建立倒排索引實現(xiàn)全文搜索。具體來說测萎，ES會建立一個覆蓋表中所有文檔衬吆、所有字段的龐大的倒排索引，以實現(xiàn)對存入ES中的所有數(shù)據(jù)進行快速檢索绳泉。因此只要是存入ES的數(shù)據(jù)逊抡，無論再復(fù)雜的聚合查詢也可以得到不錯的性能，而且你再也不用為如何建立各種復(fù)雜索引而頭痛了零酪。

說了這么多ES的優(yōu)點冒嫡，你是不是覺得ES簡直萬能了？可惜不是的四苇，ES也有很多的短處孝凌，最明顯的就是字段類型無法修改、寫入性能較低和高硬件資源消耗月腋。前邊講到ES會自動的替你建立索引蟀架，盡管這能給全文搜索以及聚合查詢帶來很多好處還能替你省了建索引這一麻煩事，但是這個特性也會帶來一堆問題榆骚。ES需要在創(chuàng)建字段前要預(yù)先建立Mapping片拍，Mapping中包含每個字段的類型信息，ES需要根據(jù)Mapping為字段建立合適的索引妓肢。由于這個Mapping的存在捌省，ES中的字段一但建立就不能再修改類型了。（例如碉钠，你建的數(shù)據(jù)表的某個字段忘了加全文搜索纲缓，你想臨時加上卷拘，但是表已經(jīng)建好并且已經(jīng)有很多數(shù)據(jù)了，這時候該怎么辦呢祝高？不好意思栗弟，你只能把整個數(shù)據(jù)表刪了再重建一遍！）因此工闺，ES在數(shù)據(jù)結(jié)構(gòu)靈活度上高于MySQL但遠不如MongoDB横腿。ES的缺點還不止這些，自動建立索引使得ES的寫入性能也收到了影響斤寂，要明顯低于MongoDB，并且ES的寫入還有一個更要命的問題揪惦，那就是默認(rèn)1S的寫入延遲遍搞，也就是說你的數(shù)據(jù)在寫入后要至少等1S才能被查詢到。對于同樣的數(shù)據(jù)ES占用的存儲空間也要明顯大于MongoDB（建那么復(fù)雜的索引能不占空間嗎器腋？）溪猿，對硬件資源的消耗也是非常厲害，大數(shù)據(jù)量下64G內(nèi)存+SSD基本是標(biāo)配纫塌，算得上是數(shù)據(jù)庫中的貴族服務(wù)了诊县，因此如果你的老板很小氣，對于ES的選用可要慎重嘍措左！

ES的全文搜索特性使它成為構(gòu)建搜索引擎的利器依痊。除此之外，ES很好的支持了復(fù)雜聚合查詢這一特點還使得ES非常適合拿來作數(shù)據(jù)分析使用怎披。其實胸嘁，ES還專門做了與自己配套的ELK套裝，給你提供從日志收集到數(shù)據(jù)可視化分析的一條龍服務(wù)凉逛，絕對是構(gòu)建高大上數(shù)據(jù)分析平臺的利器性宏。但是，ES的高成本和低寫入性能這些缺點也注定了它不適合用在那些數(shù)據(jù)價值不高状飞、對寫入性能有要求毫胜、數(shù)據(jù)量大而成本受限的場景中。

Hbase

image

HBase是Hadoop項目的一部分诬辈，而且是當(dāng)年谷歌大數(shù)據(jù)三駕馬車之一的BigTable方案的實現(xiàn)酵使，因此絕對算得上是大數(shù)據(jù)時代最有代表性的技術(shù)之一了。

作為Hadoop系列產(chǎn)品之一焙糟，HBase也繼承了Hadoop項目的最大優(yōu)點凝化，那就是對海量數(shù)據(jù)的支持，以及極強的橫向（存儲容量）擴展能力酬荞。和Redis類似搓劫，HBase也需要為每一行數(shù)據(jù)定義一個key瞧哟，之后所有的查詢都依賴這個key進行。但是不同的地方在于枪向，HBase中的一行數(shù)據(jù)還可以有非常多的列項（類似MongoDB字段）勤揩，數(shù)據(jù)會按照列進行分組和存儲，同一列的數(shù)據(jù)存儲在同一個地方秘蛔，這也是HBase被稱為列式存儲數(shù)據(jù)庫的原因陨亡。其實從本質(zhì)上來說，HBase相當(dāng)于是把邏輯上的一張大表按照列族分拆成若干張小表分別進行存儲深员，不僅是列负蠕，數(shù)據(jù)的行數(shù)到達一定數(shù)量后表也會再被拆分。因此倦畅，HBase能夠把巨大的表分布到很多臺機器上遮糖，從而容納規(guī)模近乎無限的數(shù)據(jù)。同時叠赐，對HBase進行橫向擴展也非常方便欲账，你基本只需要添加新的機器，而不用對數(shù)據(jù)做任何改動芭概，就可以實現(xiàn)數(shù)據(jù)庫容量線性的增長赛不，這在其他SQL數(shù)據(jù)庫中是難以做到的（盡管其他數(shù)據(jù)庫也有諸如MongoDB分片集群之類的功能幫助你進行數(shù)據(jù)規(guī)模橫向擴展，但是無論是在實施的難度上還是在對數(shù)據(jù)的影響方面這些都無法跟HBase相提并論罢洲。）

HBase的列式存儲特性帶來了海量數(shù)據(jù)規(guī)模的支持和極強的擴展能力踢故，但是也給數(shù)據(jù)的讀取帶來很大的局限。由于只有同一列族的數(shù)據(jù)才會被存放在一起惹苗，而且所有的查詢都必須要依賴Key畴椰，這就使得很多復(fù)雜查詢難以進行。例如鸽粉，如果你的查詢條件涉及多個列項斜脂，或者你無法獲取要查詢數(shù)據(jù)的key，那么查詢效率將會非常低下触机。因此帚戳，HBase僅僅適合。

HBase的列式存儲特點帶來了對海量數(shù)據(jù)的容納能力儡首，因此非常適合數(shù)據(jù)量極大片任，查詢條件簡單，列與列之間聯(lián)系不大的輕查詢應(yīng)用場景蔬胯。最典型的比如搜索引擎所使用的網(wǎng)頁數(shù)據(jù)庫对供。HBase不適合數(shù)據(jù)結(jié)構(gòu)復(fù)雜，且需要復(fù)雜查詢的應(yīng)用場景。另外值得一提的是产场，HBase是很重的一款產(chǎn)品鹅髓，需要依賴很多的Hadoop組件，因此如果你的數(shù)據(jù)規(guī)模不大京景，那就完全沒必要殺雞用牛刀窿冯，MongoDB這類產(chǎn)品完全可以更好的滿足你的需求。

總結(jié)

以上四種數(shù)據(jù)庫是當(dāng)今NoSQL中最火爆的幾款确徙，掌握了它們醒串，你基本就能cover住互聯(lián)網(wǎng)開發(fā)中的絕大多數(shù)數(shù)據(jù)存儲需求。這里還想強調(diào)的一點是鄙皇，如同買衣服一樣芜赌，沒有最好的數(shù)據(jù)庫，只有最適合你的應(yīng)用場景的數(shù)據(jù)庫伴逸，因此選用一款數(shù)據(jù)庫前一定要想清楚自己的應(yīng)用場景是否合適缠沈。再給大家總結(jié)下這些數(shù)據(jù)庫的適用場景：

如果你對數(shù)據(jù)的讀寫要求極高，并且你的數(shù)據(jù)規(guī)模不大违柏，也不需要長期存儲，選redis香椎；

如果你的數(shù)據(jù)規(guī)模較大漱竖，對數(shù)據(jù)的讀性能要求很高，數(shù)據(jù)表的結(jié)構(gòu)需要經(jīng)常變畜伐，有時還需要做一些聚合查詢馍惹，選MongoDB；

如果你需要構(gòu)造一個搜索引擎或者你想搞一個看著高大上的數(shù)據(jù)可視化平臺玛界，并且你的數(shù)據(jù)有一定的分析價值或者你的老板是土豪万矾，選ElasticSearch；

如果你需要存儲海量數(shù)據(jù)慎框，連你自己都不知道你的數(shù)據(jù)規(guī)模將來會增長多么大良狈，那么選HBase。