云計(jì)算背后的秘密：NoSQL誕生的原因和優(yōu)缺點(diǎn)
我本來一直覺得NoSQL其實(shí)很容易理解的别惦，我本身也已經(jīng)對(duì)NoSQL有了非常深入的研究恬试，但是在最近準(zhǔn)備YunTable的Chart的時(shí)候，發(fā)現(xiàn)NoSQL不僅非常博大精深昌屉，而且我個(gè)人對(duì)NoSQL的理解也只是皮毛而已谆膳，但我還算是一個(gè)“知恥而后勇”的人懂衩，所以經(jīng)過一段時(shí)間的學(xué)習(xí)之后华坦，從本系列第六篇開始愿吹，就將和大家聊聊NoSQL，而本篇將主要給大家做一下NoSQL數(shù)據(jù)庫的綜述惜姐。首先將和大家聊聊為什么NoSQL會(huì)在關(guān)系型數(shù)據(jù)庫已經(jīng)非常普及的情況下異軍突起?
隨著互聯(lián)網(wǎng)的不斷發(fā)展洗搂，各種類型的應(yīng)用層出不窮，所以導(dǎo)致在這個(gè)云計(jì)算的時(shí)代载弄，對(duì)技術(shù)提出了更多的需求，主要體現(xiàn)在下面這四個(gè)方面：1. 低延遲的讀寫速度：應(yīng)用快速地反應(yīng)能極大地提升用戶的滿意度; 2. 支撐海量的數(shù)據(jù)和流量：對(duì)于搜索這樣大型應(yīng)用而言撵颊，需要利用PB級(jí)別的數(shù)據(jù)和能應(yīng)對(duì)百萬級(jí)的流量; 3. 大規(guī)模集群的管理：系統(tǒng)管理員希望分布式應(yīng)用能更簡(jiǎn)單的部署和管理;
[if !supportLists]1.?[endif]龐大運(yùn)營(yíng)成本的考量：IT經(jīng)理們希望在硬件成本宇攻、軟件成本和人力成本能夠有大幅度地降低;
目前世界上主流的存儲(chǔ)系統(tǒng)大部分還是采用了關(guān)系型數(shù)據(jù)庫，其主要有一下優(yōu)點(diǎn)：
1.事務(wù)處理—保持?jǐn)?shù)據(jù)的一致性倡勇；
2.由于以標(biāo)準(zhǔn)化為前提逞刷，數(shù)據(jù)更新的開銷很小（相同的字段基本上只有一處）妻熊；
3.可以進(jìn)行Join等復(fù)雜查詢夸浅。
雖然關(guān)系型數(shù)據(jù)庫已經(jīng)在業(yè)界的數(shù)據(jù)存儲(chǔ)方面占據(jù)不可動(dòng)搖的地位，但是由于其天生的幾個(gè)限制扔役，使其很難滿足上面這幾個(gè)需求：1. 擴(kuò)展困難：由于存在類似Join這樣多表查詢機(jī)制帆喇，使得數(shù)據(jù)庫在擴(kuò)展方面很艱難; 2. 讀寫慢：這種情況主要發(fā)生在數(shù)據(jù)量達(dá)到一定規(guī)模時(shí)由于關(guān)系型數(shù)據(jù)庫的系統(tǒng)邏輯非常復(fù)雜，使得其非常容易發(fā)生死鎖等的并發(fā)問題亿胸，所以導(dǎo)致其讀寫速度下滑非常嚴(yán)重; 3. 成本高：企業(yè)級(jí)數(shù)據(jù)庫的License價(jià)格很驚人坯钦，并且隨著系統(tǒng)的規(guī)模预皇，而不斷上升; 4. 有限的支撐容量：現(xiàn)有關(guān)系型解決方案還無法支撐Google這樣海量的數(shù)據(jù)存儲(chǔ); 業(yè)界為了解決上面提到的幾個(gè)需求，推出了多款新類型的數(shù)據(jù)庫婉刀，并且由于它們?cè)谠O(shè)計(jì)上和傳統(tǒng)的NoSQL數(shù)據(jù)庫相比有很大的不同吟温，所以被統(tǒng)稱為“NoSQL”系列數(shù)據(jù)庫⊥患眨總的來說鲁豪，在設(shè)計(jì)上，它們非常關(guān)注對(duì)數(shù)據(jù)高并發(fā)地讀寫和對(duì)海量數(shù)據(jù)的存儲(chǔ)等律秃，與關(guān)系型數(shù)據(jù)庫相比爬橡，它們?cè)诩軜?gòu)和數(shù)據(jù)模型方量面做了“減法”，而在擴(kuò)展和并發(fā)等方面做了“加法”∮丫現(xiàn)在主流的NoSQL數(shù)據(jù)庫有BigTable堤尾、HBase、Cassandra迁客、SimpleDB郭宝、CouchDB、MongoDB和Redis等掷漱。接下來粘室，將關(guān)注NoSQL數(shù)據(jù)庫到底存在哪些優(yōu)缺點(diǎn)。
在優(yōu)勢(shì)方面卜范，主要體現(xiàn)在下面這三點(diǎn)：1. 簡(jiǎn)單的擴(kuò)展：典型例子是Cassandra衔统，由于其架構(gòu)是類似于經(jīng)典的P2P，所以能通過輕松地添加新的節(jié)點(diǎn)來擴(kuò)展這個(gè)集群; 2. 快速的讀寫：主要例子有Redis海雪，由于其邏輯簡(jiǎn)單锦爵，而且純內(nèi)存操作，使得其性能非常出色奥裸，單節(jié)點(diǎn)每秒可以處理超過10萬次讀寫操作; 3. 低廉的成本：這是大多數(shù)分布式數(shù)據(jù)庫共有的特點(diǎn)险掀，因?yàn)橹饕际情_源軟件，沒有昂貴的License成本; 4. 但瑕不掩瑜湾宙，NoSQL數(shù)據(jù)庫還存在著很多的不足樟氢，常見主要有下面這幾個(gè)：1. 不提供對(duì)SQL的支持：如果不支持SQL這樣的工業(yè)標(biāo)準(zhǔn)，將會(huì)對(duì)用戶產(chǎn)生一定的學(xué)習(xí)和應(yīng)用遷移成本; 2. 支持的特性不夠豐富：現(xiàn)有產(chǎn)品所提供的功能都比較有限侠鳄，大多數(shù)NoSQL數(shù)據(jù)庫都不支持事務(wù)埠啃，也不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報(bào)表等; 3. 現(xiàn)有產(chǎn)品的不夠成熟：大多數(shù)產(chǎn)品都還處于初創(chuàng)期伟恶，和關(guān)系型數(shù)據(jù)庫幾十年的完善不可同日而語; 上面NoSQL產(chǎn)品的優(yōu)缺點(diǎn)都是些比較共通的胖缤，在實(shí)際情況下宦焦，每個(gè)產(chǎn)品都會(huì)根據(jù)自己所遵從的數(shù)據(jù)模型和CAP理念而有所不同梦谜，接下來，將給大家介紹NoSQL兩個(gè)最重要的概念：數(shù)據(jù)模型和CAP理念鹃骂，并在本文最后，對(duì)主流的NoSQL數(shù)據(jù)庫進(jìn)行分類罢绽。
Naresh Kumar是位軟件工程師與熱情的博主畏线，對(duì)于編程與新事物擁有極大的興趣，非常樂于與其他開發(fā)者和程序員分享技術(shù)上的研究成果良价。近日寝殴，Naresh撰文比較了NoSQL與RDBMS，并詳細(xì)介紹了他們各自的特點(diǎn)與適用的場(chǎng)景明垢。
NoSQL并不是關(guān)系型數(shù)據(jù)庫管理系統(tǒng)蚣常，本文將會(huì)介紹NoSQL數(shù)據(jù)庫與關(guān)系型數(shù)據(jù)庫之間的差別，同時(shí)還會(huì)討論在何種場(chǎng)景下應(yīng)該使用NoSQL痊银，何種場(chǎng)景下不應(yīng)該使用抵蚊。由于NoSQL還是個(gè)相對(duì)較新的技術(shù)，因此它還面臨著很多挑戰(zhàn)溯革。
時(shí)至今日贞绳，互聯(lián)網(wǎng)上有數(shù)以億計(jì)的用戶。大數(shù)據(jù)與云計(jì)算已經(jīng)成為很多主要的互聯(lián)網(wǎng)應(yīng)用都在使用或是準(zhǔn)備使用的技術(shù)致稀，這是因?yàn)榛ヂ?lián)網(wǎng)用戶每天都在不斷增長(zhǎng)冈闭，數(shù)據(jù)也變得越來越復(fù)雜，而且有很多非結(jié)構(gòu)化的數(shù)據(jù)存在抖单，這是很難通過傳統(tǒng)的關(guān)系型數(shù)據(jù)庫管理系統(tǒng)來處理的萎攒。NoSQL技術(shù)則能比較好地解決這個(gè)問題，它主要用于非結(jié)構(gòu)化的大數(shù)據(jù)與云計(jì)算上矛绘。從這個(gè)角度來看耍休，NoSQL是一種全新的數(shù)據(jù)庫思維方式。
1.NoSQL具有靈活的數(shù)據(jù)模型羊精，可以處理非結(jié)構(gòu)化/半結(jié)構(gòu)化的大數(shù)據(jù)
現(xiàn)在，我們可以通過Facebook次屠、D&B等第三方輕松獲得與訪問數(shù)據(jù)，如個(gè)人用戶信息雳刺、地理位置數(shù)據(jù)劫灶、社交圖譜、用戶產(chǎn)生的內(nèi)容掖桦、機(jī)器日志數(shù)據(jù)以及傳感器生成的數(shù)據(jù)等本昏。對(duì)這些數(shù)據(jù)的使用正在快速改變著通信、購物枪汪、廣告涌穆、娛樂以及關(guān)系管理的特質(zhì)怔昨。沒有使用這些數(shù)據(jù)的應(yīng)用很快就會(huì)被用戶所遺忘。開發(fā)者希望使用非常靈活的數(shù)據(jù)庫宿稀，能夠輕松容納新的數(shù)據(jù)類型趁舀，并且不會(huì)被第三方數(shù)據(jù)提供商內(nèi)容結(jié)構(gòu)的變化所累。很多新數(shù)據(jù)都是非結(jié)構(gòu)化或是半結(jié)構(gòu)化的祝沸，因此開發(fā)者還需要能夠高效存儲(chǔ)這種數(shù)據(jù)的數(shù)據(jù)庫矮烹。但遺憾的是，關(guān)系型數(shù)據(jù)庫所使用的定義嚴(yán)格罩锐、基于模式的方式是無法快速容納新的數(shù)據(jù)類型的奉狈，對(duì)于非結(jié)構(gòu)化或是半結(jié)構(gòu)化的數(shù)據(jù)更是無能為力。NoSQL提供的數(shù)據(jù)模型則能很好地滿足這種需求涩惑。很多應(yīng)用都會(huì)從這種非結(jié)構(gòu)化數(shù)據(jù)模型中獲益仁期，比如說CRM、ERP竭恬、BPM等等跛蛋，他們可以通過這種靈活性存儲(chǔ)數(shù)據(jù)而無需修改表或是創(chuàng)建更多的列。這些數(shù)據(jù)庫也非常適合于創(chuàng)建原型或是快速應(yīng)用萍聊，因?yàn)檫@種靈活性使得新特性的開發(fā)變得非常容易问芬。
2.NoSQL很容易實(shí)現(xiàn)可伸縮性（向上擴(kuò)展與水平擴(kuò)展）
如果有很多用戶在頻繁且并發(fā)地使用你的應(yīng)用，那么你就需要考慮可伸縮的數(shù)據(jù)庫技術(shù)而非傳統(tǒng)的RDBMS了寿桨。對(duì)于關(guān)系型技術(shù)來說此衅，很多應(yīng)用開發(fā)者會(huì)發(fā)現(xiàn)動(dòng)態(tài)的可伸縮性是難以實(shí)現(xiàn)的，這時(shí)就應(yīng)該考慮切換到NoSQL數(shù)據(jù)庫上亭螟。對(duì)于云應(yīng)用來說挡鞍，關(guān)系型數(shù)據(jù)庫一開始是普遍的選擇。然而预烙，在使用過程中卻遇到了越來越多的問題墨微，原因就在于他們是中心化的，向上擴(kuò)展而非水平擴(kuò)展的扁掸。這使得他們不適合于那些需要簡(jiǎn)單且動(dòng)態(tài)可伸縮性的應(yīng)用翘县。NoSQL數(shù)據(jù)庫從一開始就是分布式、水平擴(kuò)展的谴分，因此非常適合于互聯(lián)網(wǎng)應(yīng)用分布式的特性锈麸。
在三層互聯(lián)網(wǎng)架構(gòu)的Web/應(yīng)用層上，多年來向上擴(kuò)展已經(jīng)成為默認(rèn)的擴(kuò)展方式了牺蹄。隨著應(yīng)用使用人數(shù)的激增忘伞，我們需要添加更多的服務(wù)器，性能則是通過負(fù)載均衡來實(shí)現(xiàn)的，這時(shí)的代價(jià)與用戶數(shù)量成線性比例關(guān)系氓奈。在NoSQL數(shù)據(jù)庫之前翘魄，數(shù)據(jù)庫層的默認(rèn)擴(kuò)展方式就是向上擴(kuò)展。為了支持更多的并發(fā)用戶以及存儲(chǔ)更多的數(shù)據(jù)舀奶，你需要越來越好的服務(wù)器暑竟，更好的CPU、更多的內(nèi)存伪节、更大的磁盤來維護(hù)所有表光羞。然而，好的服務(wù)器意味著更加復(fù)雜怀大、私有纱兑、并且也更加昂貴。這與Web/應(yīng)用層所使用的便宜的硬件形成了鮮明的對(duì)比化借。
3.動(dòng)態(tài)模式
關(guān)系型數(shù)據(jù)庫需要在添加數(shù)據(jù)前先定義好模式潜慎。比如說，你需要存儲(chǔ)客戶的電話號(hào)碼蓖康、姓名铐炫、地址、城市與州等信息蒜焊，SQL數(shù)據(jù)庫需要提前知曉你要存的是什么倒信。這對(duì)于敏捷開發(fā)模式來說是場(chǎng)災(zāi)難，因?yàn)槊看瓮瓿尚绿匦詴r(shí)泳梆，數(shù)據(jù)庫的模式通常都需要改變鳖悠。因此，如果在開發(fā)過程中想將客戶喜歡的條目加到數(shù)據(jù)庫中优妙，那就得向表中添加這一列才行乘综，然后要做的就是將整個(gè)數(shù)據(jù)庫遷移到新的模式上。
4.自動(dòng)分片
由于是結(jié)構(gòu)化的套硼，關(guān)系型數(shù)據(jù)庫通常會(huì)垂直擴(kuò)展卡辰，單臺(tái)服務(wù)器要持有整個(gè)數(shù)據(jù)庫來確保可靠性與數(shù)據(jù)的持續(xù)可用性邪意。這樣做的代價(jià)就是非常昂貴九妈、擴(kuò)展受到限制，并且數(shù)據(jù)庫基礎(chǔ)設(shè)施會(huì)成為失敗點(diǎn)雾鬼。這個(gè)問題的解決方案就是水平擴(kuò)展萌朱，添加服務(wù)器而不是為單臺(tái)服務(wù)器增加更多的能力。NoSQL數(shù)據(jù)庫通常都支持自動(dòng)分片呆贿，這意味著他們本質(zhì)上就會(huì)自動(dòng)在多臺(tái)服務(wù)器上分發(fā)數(shù)據(jù)嚷兔，應(yīng)用甚至都不知道這些事情。數(shù)據(jù)與查詢負(fù)載會(huì)自動(dòng)在多臺(tái)服務(wù)器上做到平衡做入，當(dāng)某臺(tái)服務(wù)器當(dāng)機(jī)時(shí)冒晰，它能快速且透明地被替換掉。
5.復(fù)制
大多數(shù)NoSQL數(shù)據(jù)庫也支持自動(dòng)復(fù)制竟块，這意味著你可以獲得高可用性與災(zāi)備恢復(fù)功能壶运。從開發(fā)者的角度來看，存儲(chǔ)環(huán)境本質(zhì)上是虛擬化的浪秘。
1.成熟度
RDBMS系統(tǒng)由來已久蒋情。NoSQL擁護(hù)者們會(huì)說RDBMS的高齡是其衰退的標(biāo)志，不過對(duì)于大多數(shù)CIO來說耸携，RDBMS的成熟讓人放心棵癣。對(duì)于大多數(shù)情況來說，RDBMS系統(tǒng)是穩(wěn)定且功能豐富的夺衍。相比較而言狈谊，大多數(shù)NoSQL數(shù)據(jù)庫則還有很多特性有待實(shí)現(xiàn)。
2.支持
企業(yè)需要的是安心沟沙，如果關(guān)鍵系統(tǒng)出現(xiàn)了故障河劝，他們可以獲得即時(shí)的支持。所有RDBMS廠商都在不遺余力地提供良好的企業(yè)支持矛紫。與之相反赎瞎，大多數(shù)NoSQL系統(tǒng)都是開源項(xiàng)目，雖然每種數(shù)據(jù)庫都有那么幾家公司提供支持颊咬，不過這些公司大多都是小的初創(chuàng)公司务甥，沒有全球支持資源，也沒有Oracle贪染、微軟或是IBM那種令人放心的公信力缓呛。
3.分析與商業(yè)智能
NoSQL數(shù)據(jù)庫在Web 2.0應(yīng)用時(shí)代開始出現(xiàn)。因此杭隙，大多數(shù)特性都是面向這些應(yīng)用的需要的哟绊。然而，應(yīng)用中的數(shù)據(jù)對(duì)于業(yè)務(wù)來說是有價(jià)值的痰憎，這種價(jià)值遠(yuǎn)遠(yuǎn)超出了Web應(yīng)用那種CRUD票髓。企業(yè)數(shù)據(jù)庫中的業(yè)務(wù)信息可以幫助改進(jìn)效率并提升競(jìng)爭(zhēng)力，商業(yè)智能對(duì)于大中型企業(yè)來說是個(gè)非常關(guān)鍵的IT問題铣耘。
4.管理
NoSQL的設(shè)計(jì)目標(biāo)是提供零管理的解決方案洽沟，不過當(dāng)今的現(xiàn)實(shí)卻離這個(gè)目標(biāo)還相去甚遠(yuǎn)。現(xiàn)在的NoSQL需要很多技巧才能用好蜗细，并且需要不少人力裆操、物力來維護(hù)怒详。
5.專業(yè)
全球有很多開發(fā)者，每個(gè)業(yè)務(wù)部門都會(huì)有熟悉RDBMS概念與編程的人踪区。相反昆烁，幾乎每個(gè)NoSQL開發(fā)者都處于學(xué)習(xí)模式。這種狀況會(huì)隨著時(shí)間的流逝而發(fā)生改觀缎岗。但現(xiàn)在静尼，找到一個(gè)有經(jīng)驗(yàn)的RDBMS程序員或是管理員要比NoSQL專家容易多了。
NoSQL數(shù)據(jù)庫正在成為數(shù)據(jù)庫領(lǐng)域的重要力量传泊。如果使用恰當(dāng)鼠渺，那么它會(huì)帶來很多好處。然而眷细，企業(yè)應(yīng)該非常小心并注意到這些數(shù)據(jù)庫的限制與問題拦盹。
NoSQL這兩年越來越熱，尤其是大型互聯(lián)網(wǎng)公司非常熱衷這門技術(shù)溪椎。根據(jù)筆者的經(jīng)驗(yàn)掌敬，并不是任何場(chǎng)景，NoSQL都要優(yōu)于關(guān)系型數(shù)據(jù)庫池磁。下面我們來具體聊聊奔害，什么時(shí)候使用NoSQL比較給力：
1) 數(shù)據(jù)庫表schema經(jīng)常變化?比如在線商城，維護(hù)產(chǎn)品的屬性經(jīng)常要增加字段地熄，這就意味著ORMapping層的代碼和配置要改华临，如果該表的數(shù)據(jù)量過百萬，新增字段會(huì)帶來額外開銷（重建索引等）端考。NoSQL應(yīng)用在這種場(chǎng)景雅潭，可以極大提升DB的可伸縮性，開發(fā)人員可以將更多的精力放在業(yè)務(wù)層却特。
2)數(shù)據(jù)庫表字段是復(fù)雜數(shù)據(jù)類型
對(duì)于復(fù)雜數(shù)據(jù)類型扶供，比如SQL Sever提供了可擴(kuò)展性的支持，像xml類型的字段裂明。很多用過的同學(xué)應(yīng)該知道椿浓，該字段不管是查詢還是更改，效率非常一般闽晦。主要原因是是DB層對(duì)xml字段很難建高效索引扳碍，應(yīng)用層又要做從字符流到dom的解析轉(zhuǎn)換。NoSQL以json方式存儲(chǔ)仙蛉，提供了原生態(tài)的支持笋敞，在效率方便遠(yuǎn)遠(yuǎn)高于傳統(tǒng)關(guān)系型數(shù)據(jù)庫。
3)高并發(fā)數(shù)據(jù)庫請(qǐng)求
此類應(yīng)用常見于web2.0的網(wǎng)站荠瘪，很多應(yīng)用對(duì)于數(shù)據(jù)一致性要求很低夯巷，而關(guān)系型數(shù)據(jù)庫的事務(wù)以及大表join反而成了”性能殺手”赛惩。在高并發(fā)情況下，sql與no-sql的性能對(duì)比由于環(huán)境和角度不同一直是存在爭(zhēng)議的趁餐，并不是說在任何場(chǎng)景坊秸，no-sql總是會(huì)比sql快。有篇article和大家分享下澎怒，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers
4)海量數(shù)據(jù)的分布式存儲(chǔ)
海量數(shù)據(jù)的存儲(chǔ)如果選用大型商用數(shù)據(jù)，如Oracle阶牍，那么整個(gè)解決方案的成本是非常高的喷面，要花很多錢在軟硬件上。NoSQL分布式存儲(chǔ)走孽，可以部署在廉價(jià)的硬件上惧辈，是一個(gè)性價(jià)比非常高的解決方案。Mongo的auto-sharding已經(jīng)運(yùn)用到了生產(chǎn)環(huán)境磕瓷。http://www.mongodb.org/display/DOCS/Sharding
并不是說NoSQL可以解決一切問題盒齿，像ERP系統(tǒng)、BI系統(tǒng)困食，在大部分情況還是推薦使用傳統(tǒng)關(guān)系型數(shù)據(jù)庫边翁。主要的原因是此類系統(tǒng)的業(yè)務(wù)模型復(fù)雜，使用NoSQL將導(dǎo)致系統(tǒng)的維護(hù)成本增加硕盹。
NoSQL概念?隨著web2.0的快速發(fā)展符匾，非關(guān)系型、分布式數(shù)據(jù)存儲(chǔ)得到了快速的發(fā)展瘩例，它們不保證關(guān)系數(shù)據(jù)的ACID特性啊胶。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”垛贤，“Not Only SQL”也被很多人接受焰坪。（“NoSQL”一詞最早于1998年被用于一個(gè)輕量級(jí)的關(guān)系數(shù)據(jù)庫的名字。）
NoSQL被我們用得最多的當(dāng)數(shù)key-value存儲(chǔ)聘惦，當(dāng)然還有其他的文檔型的某饰、列存儲(chǔ)、圖型數(shù)據(jù)庫善绎、xml數(shù)據(jù)庫等露乏。在NoSQL概念提出之前，這些數(shù)據(jù)庫就被用于各種系統(tǒng)當(dāng)中涂邀，但是卻很少用于web互聯(lián)網(wǎng)應(yīng)用瘟仿。比如cdb、qdbm比勉、bdb數(shù)據(jù)庫劳较。
傳統(tǒng)關(guān)系數(shù)據(jù)庫的瓶頸?傳統(tǒng)的關(guān)系數(shù)據(jù)庫具有不錯(cuò)的性能驹止，高穩(wěn)定型，久經(jīng)歷史考驗(yàn)观蜗，而且使用簡(jiǎn)單臊恋，功能強(qiáng)大，同時(shí)也積累了大量的成功案例墓捻。在互聯(lián)網(wǎng)領(lǐng)域抖仅，MySQL成為了絕對(duì)靠前的王者，毫不夸張的說砖第，MySQL為互聯(lián)網(wǎng)的發(fā)展做出了卓越的貢獻(xiàn)撤卢。
在90年代，一個(gè)網(wǎng)站的訪問量一般都不大梧兼，用單個(gè)數(shù)據(jù)庫完全可以輕松應(yīng)付放吩。在那個(gè)時(shí)候，更多的都是靜態(tài)網(wǎng)頁羽杰，動(dòng)態(tài)交互類型的網(wǎng)站不多渡紫。
到了最近10年，網(wǎng)站開始快速發(fā)展考赛√枧欤火爆的論壇、博客颜骤、sns集灌、微博逐漸引領(lǐng)web領(lǐng)域的潮流。在初期复哆，論壇的流量其實(shí)也不大欣喧，如果你接觸網(wǎng)絡(luò)比較早，你可能還記得那個(gè)時(shí)候還有文本型存儲(chǔ)的論壇程序梯找，可以想象一般的論壇的流量有多大唆阿。
Memcached+MySQL?后來，隨著訪問量的上升锈锤，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫上都開始出現(xiàn)了性能問題驯鳖，web程序不再僅僅專注在功能上，同時(shí)也在追求性能久免。程序員們開始大量的使用緩存技術(shù)來緩解數(shù)據(jù)庫的壓力浅辙，優(yōu)化數(shù)據(jù)庫的結(jié)構(gòu)和索引。開始比較流行的是通過文件緩存來緩解數(shù)據(jù)庫壓力阎姥，但是當(dāng)訪問量繼續(xù)增大的時(shí)候记舆，多臺(tái)web機(jī)器通過文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力呼巴。在這個(gè)時(shí)候泽腮，Memcached就自然的成為一個(gè)非常時(shí)尚的技術(shù)產(chǎn)品御蒲。
Memcached作為一個(gè)獨(dú)立的分布式的緩存服務(wù)器，為多個(gè)web服務(wù)器提供了一個(gè)共享的高性能緩存服務(wù)诊赊，在Memcached服務(wù)器上厚满，又發(fā)展了根據(jù)hash算法來進(jìn)行多臺(tái)Memcached緩存服務(wù)的擴(kuò)展，然后又出現(xiàn)了一致性hash來解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來的大量緩存失效的弊端碧磅。當(dāng)時(shí)碘箍，如果你去面試，你說你有Memcached經(jīng)驗(yàn)鲸郊，肯定會(huì)加分的丰榴。
Mysql主從讀寫分離?由于數(shù)據(jù)庫的寫入壓力增加，Memcached只能緩解數(shù)據(jù)庫的讀取壓力严望。讀寫集中在一個(gè)數(shù)據(jù)庫上讓數(shù)據(jù)庫不堪重負(fù)，大部分網(wǎng)站開始使用主從復(fù)制技術(shù)來達(dá)到讀寫分離逻恐，以提高讀寫性能和讀庫的可擴(kuò)展性像吻。Mysql的master-slave模式成為這個(gè)時(shí)候的網(wǎng)站標(biāo)配了。
分表分庫?隨著web2.0的繼續(xù)高速發(fā)展复隆，在Memcached的高速緩存拨匆，MySQL的主從復(fù)制，讀寫分離的基礎(chǔ)之上挽拂，這時(shí)MySQL主庫的寫壓力開始出現(xiàn)瓶頸惭每，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖亏栈，在高并發(fā)下會(huì)出現(xiàn)嚴(yán)重的鎖問題台腥，大量的高并發(fā)MySQL應(yīng)用開始使用InnoDB引擎代替MyISAM。同時(shí)绒北，開始流行使用分表分庫來緩解寫壓力和數(shù)據(jù)增長(zhǎng)的擴(kuò)展問題黎侈。這個(gè)時(shí)候，分表分庫成了一個(gè)熱門技術(shù)闷游，是面試的熱門問題也是業(yè)界討論的熱門技術(shù)問題峻汉。也就在這個(gè)時(shí)候，MySQL推出了還不太穩(wěn)定的表分區(qū)脐往，這也給技術(shù)實(shí)力一般的公司帶來了希望休吠。雖然MySQL推出了MySQL Cluster集群，但是由于在互聯(lián)網(wǎng)幾乎沒有成功案例业簿，性能也不能滿足互聯(lián)網(wǎng)的要求瘤礁，只是在高可靠性上提供了非常大的保證。
MySQL的擴(kuò)展性瓶頸?在互聯(lián)網(wǎng)梅尤，大部分的MySQL都應(yīng)該是IO密集型的蔚携，事實(shí)上希太，如果你的MySQL是個(gè)CPU密集型的話，那么很可能你的MySQL設(shè)計(jì)得有性能問題酝蜒，需要優(yōu)化了誊辉。大數(shù)據(jù)量高并發(fā)環(huán)境下的MySQL應(yīng)用開發(fā)越來越復(fù)雜，也越來越具有技術(shù)挑戰(zhàn)性亡脑。分表分庫的規(guī)則把握都是需要經(jīng)驗(yàn)的堕澄。雖然有像淘寶這樣技術(shù)實(shí)力強(qiáng)大的公司開發(fā)了透明的中間件層來屏蔽開發(fā)者的復(fù)雜性，但是避免不了整個(gè)架構(gòu)的復(fù)雜性霉咨。分庫分表的子庫到一定階段又面臨擴(kuò)展問題蛙紫。還有就是需求的變更，可能又需要一種新的分庫方式途戒。
MySQL數(shù)據(jù)庫也經(jīng)常存儲(chǔ)一些大文本字段坑傅，導(dǎo)致數(shù)據(jù)庫表非常的大，在做數(shù)據(jù)庫恢復(fù)的時(shí)候就導(dǎo)致非常的慢喷斋，不容易快速恢復(fù)數(shù)據(jù)庫唁毒。比如1000萬4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去星爪，MySQL將變得非常的小浆西。
關(guān)系數(shù)據(jù)庫很強(qiáng)大，但是它并不能很好的應(yīng)付所有的應(yīng)用場(chǎng)景顽腾。MySQL的擴(kuò)展性差（需要復(fù)雜的技術(shù)來實(shí)現(xiàn)）近零，大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難抄肖，正是當(dāng)前使用MySQL的開發(fā)人員面臨的問題久信。
易擴(kuò)展?NoSQL數(shù)據(jù)庫種類繁多，但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫的關(guān)系型特性漓摩。數(shù)據(jù)之間無關(guān)系入篮，這樣就非常容易擴(kuò)展。也無形之間幌甘，在架構(gòu)的層面上帶來了可擴(kuò)展的能力潮售。
大數(shù)據(jù)量，高性能?NoSQL數(shù)據(jù)庫都具有非常高的讀寫性能锅风，尤其在大數(shù)據(jù)量下酥诽，同樣表現(xiàn)優(yōu)秀。這得益于它的無關(guān)系性皱埠，數(shù)據(jù)庫的結(jié)構(gòu)簡(jiǎn)單肮帐。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache训枢，在針對(duì)web2.0的交互頻繁的應(yīng)用托修，Cache性能不高。而NoSQL的Cache是記錄級(jí)的恒界，是一種細(xì)粒度的Cache睦刃，所以NoSQL在這個(gè)層面上來說就要性能高很多了。
靈活的數(shù)據(jù)模型?NoSQL無需事先為要存儲(chǔ)的數(shù)據(jù)建立字段十酣，隨時(shí)可以存儲(chǔ)自定義的數(shù)據(jù)格式涩拙。而在關(guān)系數(shù)據(jù)庫里，增刪字段是一件非常麻煩的事情耸采。如果是非常大數(shù)據(jù)量的表兴泥，增加字段簡(jiǎn)直就是一個(gè)噩夢(mèng)。這點(diǎn)在大數(shù)據(jù)量的web2.0時(shí)代尤其明顯虾宇。
高可用?NoSQL在不太影響性能的情況搓彻，就可以方便的實(shí)現(xiàn)高可用的架構(gòu)。比如Cassandra嘱朽，HBase模型旭贬，通過復(fù)制模型也能實(shí)現(xiàn)高可用。
總結(jié)?NoSQL數(shù)據(jù)庫的出現(xiàn)燥翅，彌補(bǔ)了關(guān)系數(shù)據(jù)（比如MySQL）在某些方面的不足骑篙，在某些方面能極大的節(jié)省開發(fā)成本和維護(hù)成本蜕提。 MySQL和NoSQL都有各自的特點(diǎn)和使用的應(yīng)用場(chǎng)景，兩者的緊密結(jié)合將會(huì)給web2.0的數(shù)據(jù)庫發(fā)展帶來新的思路谎势。讓關(guān)系數(shù)據(jù)庫關(guān)注在關(guān)系上，NoSQL關(guān)注在存儲(chǔ)上脏榆。
關(guān)系數(shù)據(jù)庫還是NoSQL數(shù)據(jù)庫
上一篇簡(jiǎn)單的說明了為什么要使用NoSQL。接下來我們看下如何把NoSQL引入到我們的項(xiàng)目中须喂，我們到底要不要把NoSQL引入到項(xiàng)目中。
在過去坞生，我們只需要學(xué)習(xí)和使用一種數(shù)據(jù)庫技術(shù)，就能做幾乎所有的數(shù)據(jù)庫應(yīng)用開發(fā)是己。因?yàn)槌墒旆€(wěn)定的關(guān)系數(shù)據(jù)庫產(chǎn)品并不是很多，而供你選擇的免費(fèi)版本就更加少了，所以互聯(lián)網(wǎng)領(lǐng)域基本上都選擇了免費(fèi)的MySQL數(shù)據(jù)庫宙地。在高速發(fā)展的WEB2.0時(shí)代，我們發(fā)現(xiàn)關(guān)系數(shù)據(jù)庫在性能逆皮、擴(kuò)展性宅粥、數(shù)據(jù)的快速備份和恢復(fù)、滿足需求的易用性上并不總是能很好的滿足我們的需要页屠，我們?cè)絹碓节呄蛴诟鶕?jù)業(yè)務(wù)場(chǎng)景選擇合適的數(shù)據(jù)庫粹胯，以及進(jìn)行多種數(shù)據(jù)庫的融合運(yùn)用。幾年前的一篇文章《One Size Fits All - An Idea Whose Time Has Come and Gone》就已經(jīng)闡述了這個(gè)觀點(diǎn)辰企。
當(dāng)我們?cè)谟懻撌欠褚褂肗oSQL的時(shí)候风纠，你還需要理解NoSQL也是分很多種類的，在NoSQL百花齊放的今天牢贸，NoSQL的正確選擇比選擇關(guān)系數(shù)據(jù)庫還具有挑戰(zhàn)性竹观。雖然NoSQL的使用很簡(jiǎn)單，但是選擇卻是個(gè)麻煩事潜索，這也正是很多人在觀望的一個(gè)原因臭增。
NoSQL僅僅是一個(gè)概念，NoSQL數(shù)據(jù)庫根據(jù)數(shù)據(jù)的存儲(chǔ)模型和特點(diǎn)分為很多種類竹习。
以上NoSQL數(shù)據(jù)庫類型的劃分并不是絕對(duì)誊抛，只是從存儲(chǔ)模型上來進(jìn)行的大體劃分。它們之間沒有絕對(duì)的分界整陌，也有交差的情況拗窃，比如Tokyo Cabinet / Tyrant的Table類型存儲(chǔ)，就可以理解為是文檔型存儲(chǔ)泌辫，Berkeley DB XML數(shù)據(jù)庫是基于Berkeley DB之上開發(fā)的随夸。
NoSQL還是關(guān)系數(shù)據(jù)庫?雖然09年出現(xiàn)了比較激進(jìn)的文章《關(guān)系數(shù)據(jù)庫已死》，但是我們心里都清楚震放，關(guān)系數(shù)據(jù)庫其實(shí)還活得好好的宾毒，你還不能不用關(guān)系數(shù)據(jù)庫。但是也說明了一個(gè)事實(shí)殿遂，關(guān)系數(shù)據(jù)庫在處理WEB2.0數(shù)據(jù)的時(shí)候诈铛，的確已經(jīng)出現(xiàn)了瓶頸。
那么我們到底是用NoSQL還是關(guān)系數(shù)據(jù)庫呢墨礁？我想我們沒有必要來進(jìn)行一個(gè)絕對(duì)的回答幢竹。我們需要根據(jù)我們的應(yīng)用場(chǎng)景來決定我們到底用什么饵溅。
如果關(guān)系數(shù)據(jù)庫在你的應(yīng)用場(chǎng)景中，完全能夠很好的工作冠句，而你又是非常善于使用和維護(hù)關(guān)系數(shù)據(jù)庫的幸乒，那么我覺得你完全沒有必要遷移到NoSQL上面罕扎，除非你是個(gè)喜歡折騰的人。如果你是在金融杆查，電信等以數(shù)據(jù)為王的關(guān)鍵領(lǐng)域亲桦，目前使用的是Oracle數(shù)據(jù)庫來提供高可靠性的浊仆，除非遇到特別大的瓶頸，不然也別貿(mào)然嘗試NoSQL舔琅。
然而备蚓，在WEB2.0的網(wǎng)站中闪檬，關(guān)系數(shù)據(jù)庫大部分都出現(xiàn)了瓶頸粗悯。在磁盤IO同欠、數(shù)據(jù)庫可擴(kuò)展上都花費(fèi)了開發(fā)人員相當(dāng)多的精力來優(yōu)化铺遂，比如做分表分庫（database sharding）、主從復(fù)制撤逢、異構(gòu)復(fù)制等等蚊荣，然而，這些工作需要的技術(shù)能力越來越高奢入，也越來越具有挑戰(zhàn)性媳叨。如果你正在經(jīng)歷這些場(chǎng)合糊秆，那么我覺得你應(yīng)該嘗試一下NoSQL了。
選擇合適的NoSQL?如此多類型的NoSQL艘儒，而每種類型的NoSQL又有很多界睁，到底選擇什么類型的NoSQL來作為我們的存儲(chǔ)呢兵拢？這并不是一個(gè)很好回答的問題说铃，影響我們選擇的因素有很多，而選擇也可能有多種债热，隨著業(yè)務(wù)場(chǎng)景窒篱，需求的變更可能選擇又會(huì)變化舶沿。我們常常需要根據(jù)如下情況考慮：
1.數(shù)據(jù)結(jié)構(gòu)特點(diǎn)。包括結(jié)構(gòu)化高镐、半結(jié)構(gòu)化嫉髓、字段是否可能變更、是否有大文本字段恕沫、數(shù)據(jù)字段是否可能變化纱意。
2.寫入特點(diǎn)。包括insert比例迄委、update比例叙身、是否經(jīng)常更新數(shù)據(jù)的某一個(gè)小字段硫狞、原子更新需求残吩。
3.查詢特點(diǎn)。包括查詢的條件即彪、查詢熱點(diǎn)的范圍隶校。比如用戶信息的查詢蛹锰，可能就是隨機(jī)的，而新聞的查詢就是按照時(shí)間舞终，越新的越頻繁权埠。
NoSQL和關(guān)系數(shù)據(jù)庫結(jié)合?其實(shí)NoSQL數(shù)據(jù)庫僅僅是關(guān)系數(shù)據(jù)庫在某些方面（性能煎谍，擴(kuò)展）的一個(gè)彌補(bǔ)呐粘，單從功能上講，NoSQL的幾乎所有的功能作岖，在關(guān)系數(shù)據(jù)庫上都能夠滿足痘儡，所以選擇NoSQL的原因并不在功能上。
所以渐尿，我們一般會(huì)把NoSQL和關(guān)系數(shù)據(jù)庫進(jìn)行結(jié)合使用砖茸，各取所長(zhǎng)殴穴，需要使用關(guān)系特性的時(shí)候我們使用關(guān)系數(shù)據(jù)庫采幌，需要使用NoSQL特性的時(shí)候我們使用NoSQL數(shù)據(jù)庫，各得其所再沧。
舉個(gè)簡(jiǎn)單的例子吧炒瘸，比如用戶評(píng)論的存儲(chǔ)寝衫，評(píng)論大概有主鍵id慰毅、評(píng)論的對(duì)象aid、評(píng)論內(nèi)容content婶芭、用戶uid等字段犀农。我們能確定的是評(píng)論內(nèi)容content肯定不會(huì)在數(shù)據(jù)庫中用where content=’’查詢宰掉，評(píng)論內(nèi)容也是一個(gè)大文本字段赁濒。那么我們可以把 主鍵id拒炎、評(píng)論對(duì)象aid击你、用戶id存儲(chǔ)在數(shù)據(jù)庫果漾，評(píng)論內(nèi)容存儲(chǔ)在NoSQL谷誓，這樣數(shù)據(jù)庫就節(jié)省了存儲(chǔ)content占用的磁盤空間，從而節(jié)省大量IO户辱，對(duì)content也更容易做Cache庐镐。
//從MySQL中查詢出評(píng)論主鍵id列表 commentIds=DB.query(“SELECT id FROM comments where aid=’評(píng)論對(duì)象id’ LIMIT 0,20”); //根據(jù)主鍵id列表变逃，從NoSQL取回評(píng)論實(shí)體數(shù)據(jù) CommentsList=NoSQL.get(commentIds);NoSQL代替MySQL 在某些應(yīng)用場(chǎng)合揽乱，比如一些配置的關(guān)系鍵值映射存儲(chǔ)、用戶名和密碼的存儲(chǔ)损拢、Session會(huì)話存儲(chǔ)等等福压，用NoSQL完全可以替代MySQL存儲(chǔ)或舞。不但具有更高的性能映凳，而且開發(fā)也更加方便。
NoSQL作為緩存服務(wù)器?MySQL+Memcached的架構(gòu)中腐泻，我們處處都要精心設(shè)計(jì)我們的緩存队询，包括過期時(shí)間的設(shè)計(jì)、緩存的實(shí)時(shí)性設(shè)計(jì)铆惑、緩存內(nèi)存大小評(píng)估员魏、緩存命中率等等叠聋。
NoSQL數(shù)據(jù)庫一般都具有非常高的性能碌补，在大多數(shù)場(chǎng)景下面，你不必再考慮在代碼層為NoSQL構(gòu)建一層Memcached緩存镇匀。NoSQL數(shù)據(jù)本身在Cache上已經(jīng)做了相當(dāng)多的優(yōu)化工作汗侵。
Memcached這類內(nèi)存緩存服務(wù)器緩存的數(shù)據(jù)大小受限于內(nèi)存大小群发，如果用NoSQL來代替Memcached來緩存數(shù)據(jù)庫的話熟妓，就可以不再受限于內(nèi)存大小。雖然可能有少量的磁盤IO讀寫浪蹂，可能比Memcached慢一點(diǎn)坤次，但是完全可以用來緩存數(shù)據(jù)庫的查詢操作斥赋。
規(guī)避風(fēng)險(xiǎn)?由于NoSQL是一個(gè)比較新的東西，特別是我們選擇的NoSQL數(shù)據(jù)庫還不是非常成熟的產(chǎn)品滑绒，所以我們可能會(huì)遇到未知的風(fēng)險(xiǎn)。為了得到NoSQL的好處杠览，又要考慮規(guī)避風(fēng)險(xiǎn)踱阿，魚與熊掌如何兼得钦铁？
現(xiàn)在業(yè)內(nèi)很多公司的做法就是數(shù)據(jù)的備份。在往NoSQL里面存儲(chǔ)數(shù)據(jù)的時(shí)候還會(huì)往MySQL里面存儲(chǔ)一份佛点。NoSQL數(shù)據(jù)庫本身也需要進(jìn)行備份（冷備和熱備）超营⊙媸郑或者可以考慮使用兩種NoSQL數(shù)據(jù)庫书妻，出現(xiàn)問題后可以進(jìn)行切換（避免出現(xiàn)digg使用Cassandra的悲劇）见间。
總結(jié)?本文只是簡(jiǎn)單的從MySQL和NoSQL的角度分析如何選擇米诉，以及進(jìn)行融合使用篷帅。其實(shí)在選擇NoSQL的時(shí)候，你可能還會(huì)碰到關(guān)于CAP原則惊橱，最終一致性税朴，BASE思想的考慮。因?yàn)槭褂肕ySQL架構(gòu)的時(shí)候泡一，你也會(huì)碰到上面的問題鼻忠，所以這里沒有闡述哪亿。
大數(shù)據(jù)學(xué)習(xí)資料分享群 232840209 不管你是小白還是大牛蝇棉，小編我都挺歡迎芥永，今天的源碼已經(jīng)上傳到群文件埋涧，不定期分享干貨，包括我自己整理的一份最新的適合2018年學(xué)習(xí)的大數(shù)據(jù)開發(fā)和零基礎(chǔ)入門教程劲弦，歡迎初學(xué)和進(jìn)階中的小伙伴邑跪。
