為什么要使用NoSQL？NOSQL的優(yōu)勢(shì)

非常榮幸能受邀在InfoQ開(kāi)辟這樣一個(gè)關(guān)于NoSQL的專(zhuān)欄，InfoQ是我非常尊重的一家技術(shù)媒體，同時(shí)我也希望借助InfoQ，在國(guó)內(nèi)推動(dòng)NoSQL的發(fā)展，希望跟我一樣有興趣的朋友加入進(jìn)來(lái)。這次的NoSQL專(zhuān)欄系列將先整體介紹NoSQL，然后介紹如何把NoSQL運(yùn)用到自己的項(xiàng)目中合適的場(chǎng)景中，還會(huì)適當(dāng)?shù)胤治鲆恍┏晒Π咐?，希望有成功使用NoSQL經(jīng)驗(yàn)的朋友給我提供一些線索和信息。 NoSQL概念隨著web2.0的快速發(fā)展，非關(guān)系型、分布式數(shù)據(jù)存儲(chǔ)得到了快速的發(fā)展，它們不保證關(guān)系數(shù)據(jù)的ACID特性。NoSQL概念在2009年被提了出來(lái)。NoSQL最常見(jiàn)的解釋是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一詞最早于1998年被用于一個(gè)輕量級(jí)的關(guān)系數(shù)據(jù)庫(kù)的名字。） NoSQL被我們用得最多的當(dāng)數(shù)key-value存儲(chǔ)，當(dāng)然還有其他的文檔型的、列存儲(chǔ)、圖型數(shù)據(jù)庫(kù)、xml數(shù)據(jù)庫(kù)等。在NoSQL概念提出之前，這些數(shù)據(jù)庫(kù)就被用于各種系統(tǒng)當(dāng)中，但是卻很少用于web互聯(lián)網(wǎng)應(yīng)用。比如cdb、qdbm、bdb數(shù)據(jù)庫(kù)。 傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的瓶頸 傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)具有不錯(cuò)的性能，高穩(wěn)定型，久經(jīng)歷史考驗(yàn)，而且使用簡(jiǎn)單，功能強(qiáng)大，同時(shí)也積累了大量的成功案例。在互聯(lián)網(wǎng)領(lǐng)域，MySQL成為了絕對(duì)靠前的王者，毫不夸張的說(shuō)，MySQL為互聯(lián)網(wǎng)的發(fā)展做出了卓越的貢獻(xiàn)。 在90年代，一個(gè)網(wǎng)站的訪問(wèn)量一般都不大，用單個(gè)數(shù)據(jù)庫(kù)完全可以輕松應(yīng)付。在那個(gè)時(shí)候，更多的都是靜態(tài)網(wǎng)頁(yè)，動(dòng)態(tài)交互類(lèi)型的網(wǎng)站不多。 到了最近10年，網(wǎng)站開(kāi)始快速發(fā)展?；鸨恼搲?、博客、sns、微博逐漸引領(lǐng)web領(lǐng)域的潮流。在初期，論壇的流量其實(shí)也不大，如果你接觸網(wǎng)絡(luò)比較早，你可能還記得那個(gè)時(shí)候還有文本型存儲(chǔ)的論壇程序，可以想象一般的論壇的流量有多大。 Memcached+MySQL 后來(lái)，隨著訪問(wèn)量的上升，幾乎大部分使用MySQL架構(gòu)的網(wǎng)站在數(shù)據(jù)庫(kù)上都開(kāi)始出現(xiàn)了性能問(wèn)題，web程序不再僅僅專(zhuān)注在功能上，同時(shí)也在追求性能。程序員們開(kāi)始大量的使用緩存技術(shù)來(lái)緩解數(shù)據(jù)庫(kù)的壓力，優(yōu)化數(shù)據(jù)庫(kù)的結(jié)構(gòu)和索引。開(kāi)始比較流行的是通過(guò)文件緩存來(lái)緩解數(shù)據(jù)庫(kù)壓力，但是當(dāng)訪問(wèn)量繼續(xù)增大的時(shí)候，多臺(tái)web機(jī)器通過(guò)文件緩存不能共享，大量的小文件緩存也帶了了比較高的IO壓力。在這個(gè)時(shí)候，Memcached就自然的成為一個(gè)非常時(shí)尚的技術(shù)產(chǎn)品。 Memcached作為一個(gè)獨(dú)立的分布式的緩存服務(wù)器，為多個(gè)web服務(wù)器提供了一個(gè)共享的高性能緩存服務(wù)，在Memcached服務(wù)器上，又發(fā)展了根據(jù)hash算法來(lái)進(jìn)行多臺(tái)Memcached緩存服務(wù)的擴(kuò)展，然后又出現(xiàn)了一致性hash來(lái)解決增加或減少緩存服務(wù)器導(dǎo)致重新hash帶來(lái)的大量緩存失效的弊端。當(dāng)時(shí)，如果你去面試，你說(shuō)你有Memcached經(jīng)驗(yàn)，肯定會(huì)加分的。 Mysql主從讀寫(xiě)分離 由于數(shù)據(jù)庫(kù)的寫(xiě)入壓力增加，Memcached只能緩解數(shù)據(jù)庫(kù)的讀取壓力。讀寫(xiě)集中在一個(gè)數(shù)據(jù)庫(kù)上讓數(shù)據(jù)庫(kù)不堪重負(fù)，大部分網(wǎng)站開(kāi)始使用主從復(fù)制技術(shù)來(lái)達(dá)到讀寫(xiě)分離，以提高讀寫(xiě)性能和讀庫(kù)的可擴(kuò)展性。Mysql的master-slave模式成為這個(gè)時(shí)候的網(wǎng)站標(biāo)配了。 分表分庫(kù)隨著web2.0的繼續(xù)高速發(fā)展，在Memcached的高速緩存，MySQL的主從復(fù)制，讀寫(xiě)分離的基礎(chǔ)之上，這時(shí)MySQL主庫(kù)的寫(xiě)壓力開(kāi)始出現(xiàn)瓶頸，而數(shù)據(jù)量的持續(xù)猛增，由于MyISAM使用表鎖，在高并發(fā)下會(huì)出現(xiàn)嚴(yán)重的鎖問(wèn)題，大量的高并發(fā)MySQL應(yīng)用開(kāi)始使用InnoDB引擎代替MyISAM。同時(shí)，開(kāi)始流行使用分表分庫(kù)來(lái)緩解寫(xiě)壓力和數(shù)據(jù)增長(zhǎng)的擴(kuò)展問(wèn)題。這個(gè)時(shí)候，分表分庫(kù)成了一個(gè)熱門(mén)技術(shù)，是面試的熱門(mén)問(wèn)題也是業(yè)界討論的熱門(mén)技術(shù)問(wèn)題。也就在這個(gè)時(shí)候，MySQL推出了還不太穩(wěn)定的表分區(qū)，這也給技術(shù)實(shí)力一般的公司帶來(lái)了希望。雖然MySQL推出了MySQL Cluster集群，但是由于在互聯(lián)網(wǎng)幾乎沒(méi)有成功案例，性能也不能滿足互聯(lián)網(wǎng)的要求，只是在高可靠性上提供了非常大的保證。 MySQL的擴(kuò)展性瓶頸 在互聯(lián)網(wǎng)，大部分的MySQL都應(yīng)該是IO密集型的，事實(shí)上，如果你的MySQL是個(gè)CPU密集型的話，那么很可能你的MySQL設(shè)計(jì)得有性能問(wèn)題，需要優(yōu)化了。大數(shù)據(jù)量高并發(fā)環(huán)境下的MySQL應(yīng)用開(kāi)發(fā)越來(lái)越復(fù)雜，也越來(lái)越具有技術(shù)挑戰(zhàn)性。分表分庫(kù)的規(guī)則把握都是需要經(jīng)驗(yàn)的。雖然有像淘寶這樣技術(shù)實(shí)力強(qiáng)大的公司開(kāi)發(fā)了透明的中間件層來(lái)屏蔽開(kāi)發(fā)者的復(fù)雜性，但是避免不了整個(gè)架構(gòu)的復(fù)雜性。分庫(kù)分表的子庫(kù)到一定階段又面臨擴(kuò)展問(wèn)題。還有就是需求的變更，可能又需要一種新的分庫(kù)方式。 MySQL數(shù)據(jù)庫(kù)也經(jīng)常存儲(chǔ)一些大文本字段，導(dǎo)致數(shù)據(jù)庫(kù)表非常的大，在做數(shù)據(jù)庫(kù)恢復(fù)的時(shí)候就導(dǎo)致非常的慢，不容易快速恢復(fù)數(shù)據(jù)庫(kù)。比如1000萬(wàn)4KB大小的文本就接近40GB的大小，如果能把這些數(shù)據(jù)從MySQL省去，MySQL將變得非常的小。 關(guān)系數(shù)據(jù)庫(kù)很強(qiáng)大，但是它并不能很好的應(yīng)付所有的應(yīng)用場(chǎng)景。MySQL的擴(kuò)展性差（需要復(fù)雜的技術(shù)來(lái)實(shí)現(xiàn)），大數(shù)據(jù)下IO壓力大，表結(jié)構(gòu)更改困難，正是當(dāng)前使用MySQL的開(kāi)發(fā)人員面臨的問(wèn)題。 NOSQL的優(yōu)勢(shì)易擴(kuò)展NoSQL數(shù)據(jù)庫(kù)種類(lèi)繁多，但是一個(gè)共同的特點(diǎn)都是去掉關(guān)系數(shù)據(jù)庫(kù)的關(guān)系型特性。數(shù)據(jù)之間無(wú)關(guān)系，這樣就非常容易擴(kuò)展。也無(wú)形之間，在架構(gòu)的層面上帶來(lái)了可擴(kuò)展的能力。 大數(shù)據(jù)量，高性能 NoSQL數(shù)據(jù)庫(kù)都具有非常高的讀寫(xiě)性能，尤其在大數(shù)據(jù)量下，同樣表現(xiàn)優(yōu)秀。這得益于它的無(wú)關(guān)系性，數(shù)據(jù)庫(kù)的結(jié)構(gòu)簡(jiǎn)單。一般MySQL使用Query Cache，每次表的更新Cache就失效，是一種大粒度的Cache，在針對(duì)web2.0的交互頻繁的應(yīng)用，Cache性能不高。而NoSQL的Cache是記錄級(jí)的，是一種細(xì)粒度的Cache，所以NoSQL在這個(gè)層面上來(lái)說(shuō)就要性能高很多了。 靈活的數(shù)據(jù)模型 NoSQL無(wú)需事先為要存儲(chǔ)的數(shù)據(jù)建立字段，隨時(shí)可以存儲(chǔ)自定義的數(shù)據(jù)格式。而在關(guān)系數(shù)據(jù)庫(kù)里，增刪字段是一件非常麻煩的事情。如果是非常大數(shù)據(jù)量的表，增加字段簡(jiǎn)直就是一個(gè)噩夢(mèng)。這點(diǎn)在大數(shù)據(jù)量的web2.0時(shí)代尤其明顯。 高可用NoSQL在不太影響性能的情況，就可以方便的實(shí)現(xiàn)高可用的架構(gòu)。比如Cassandra，HBase模型，通過(guò)復(fù)制模型也能實(shí)現(xiàn)高可用。 總結(jié)NoSQL數(shù)據(jù)庫(kù)的出現(xiàn)，彌補(bǔ)了關(guān)系數(shù)據(jù)（比如MySQL）在某些方面的不足，在某些方面能極大的節(jié)省開(kāi)發(fā)成本和維護(hù)成本。 MySQL和NoSQL都有各自的特點(diǎn)和使用的應(yīng)用場(chǎng)景，兩者的緊密結(jié)合將會(huì)給web2.0的數(shù)據(jù)庫(kù)發(fā)展帶來(lái)新的思路。讓關(guān)系數(shù)據(jù)庫(kù)關(guān)注在關(guān)系上，NoSQL關(guān)注在存儲(chǔ)上。

創(chuàng)新互聯(lián)網(wǎng)站建設(shè)由有經(jīng)驗(yàn)的網(wǎng)站設(shè)計(jì)師、開(kāi)發(fā)人員和項(xiàng)目經(jīng)理組成的專(zhuān)業(yè)建站團(tuán)隊(duì)，負(fù)責(zé)網(wǎng)站視覺(jué)設(shè)計(jì)、用戶體驗(yàn)優(yōu)化、交互設(shè)計(jì)和前端開(kāi)發(fā)等方面的工作，以確保網(wǎng)站外觀精美、網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)易于使用并且具有良好的響應(yīng)性。

NoSQL會(huì)取代SQL數(shù)據(jù)庫(kù)嗎

對(duì)此，前Google工程師，Milo（本地商店搜索引擎）創(chuàng)始人Ted Dziuba最近發(fā)表標(biāo)題驚人的博客“I Can't Wait for NoSQL to Die”，對(duì)NoSQL的適用范圍進(jìn)行了分析。他認(rèn)為，

NoSQL也會(huì)帶來(lái)一連串的新問(wèn)題，并不會(huì)成為主流，無(wú)法取代關(guān)系型數(shù)據(jù)庫(kù)。

他的理由是：Cassandra等NoSQL數(shù)據(jù)庫(kù)在使用上并不方便，比如，修改column family定義時(shí)就需要重啟。而且NoSQL更適合Google那樣的規(guī)模，而一般的互聯(lián)網(wǎng)公司都不是Google，早早地去考慮Google那樣的規(guī)模的可擴(kuò)展性，純粹是浪費(fèi)時(shí)間，存在巨大的商業(yè)風(fēng)險(xiǎn)。

他還透露，即使在Google，AdWords這樣的關(guān)鍵產(chǎn)品也是基于MySQL實(shí)現(xiàn)的。

他在文中最后表示，NoSQL當(dāng)然死不了，但是

它最終會(huì)被邊緣化，就像Rails被NoSQL邊緣化一樣

Dziuba的文章因?yàn)檠赞o激烈，在社區(qū)里引起了強(qiáng)烈反應(yīng)。

SQL數(shù)據(jù)庫(kù)陣營(yíng)贊同者大有人在。craigslist工程師、著名的MySQL專(zhuān)家Jeremy Zawodny表示，在讀此文的時(shí)候，不時(shí)會(huì)心一笑。他說(shuō)，

NoSQL運(yùn)動(dòng)只是軟件不斷進(jìn)化進(jìn)程中的正?，F(xiàn)象

。關(guān)系型數(shù)據(jù)庫(kù)也會(huì)繼續(xù)發(fā)展，MySQL社區(qū)不斷推出的XtraDB或InnoDB插件, PBXT, Drizzle都是證據(jù)。各種技術(shù)競(jìng)爭(zhēng)的結(jié)果是，我們獲得了更多解決問(wèn)題的選擇。

drizzle項(xiàng)目開(kāi)發(fā)者Eric Day也表示，NoSQL有很多值得學(xué)習(xí)的，但是目前大部分實(shí)際項(xiàng)目的最佳選擇還是關(guān)系型數(shù)據(jù)庫(kù)。

NoSQL陣營(yíng)當(dāng)然不會(huì)坐視不理，Cassandra項(xiàng)目組的Eric Evans表示，Dziuba提到Cassandra修改column family定義的問(wèn)題其實(shí)很容易解決。而且，NoSQL并不是要取代MySQL，事實(shí)上Twitter仍然在用MySQL。如果關(guān)系型數(shù)據(jù)庫(kù)能夠承擔(dān)負(fù)荷，那就用好了；如果不行，請(qǐng)考慮NoSQL。

而德國(guó)知名博客Code Monkeyism則嘲笑Dziuba看起來(lái)并沒(méi)有用MySQL做過(guò)真實(shí)項(xiàng)目，因?yàn)镸ySQL如果沒(méi)有memcache，基本上無(wú)法應(yīng)付網(wǎng)站項(xiàng)目。他認(rèn)為，NoSQL將使SQL數(shù)據(jù)庫(kù)邊緣化，而且一個(gè)重要理由恰恰是可以節(jié)省DBA的開(kāi)銷(xiāo)。

digg的前任首席架構(gòu)師現(xiàn)在也在創(chuàng)業(yè)的Joe Stump說(shuō)，自己現(xiàn)在的創(chuàng)業(yè)項(xiàng)目就是用NoSQL，而且列舉了一系列問(wèn)題挑戰(zhàn)SQL陣營(yíng)。

如何定義NoSQL數(shù)據(jù)庫(kù)？

NoSQL Distilled

》時(shí)附帶寫(xiě)出的一篇博客。

Oskarsson組織的一個(gè)非正式的會(huì)議上。與會(huì)人員來(lái)自Voldemort, Cassandra, Dynomite, HBase,

Hypertable, CouchDB, VPork,

以及MongoDB的公司。這個(gè)詞迅速的被人們注意到，有人認(rèn)為只有出席了這次會(huì)議的幾個(gè)數(shù)據(jù)庫(kù)公司的產(chǎn)品才是NoSQL。

事實(shí)上，就

是對(duì)NoSQL這個(gè)名字本身的理解也是有分歧的：很多NoSQL的倡導(dǎo)者認(rèn)為它不僅僅指的是”No” toSQL

，應(yīng)該把它理解成Not Noly

SQL才對(duì)。對(duì)于此，我認(rèn)為，應(yīng)該從目前的數(shù)據(jù)庫(kù)生態(tài)環(huán)境中分離出一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)類(lèi)型，這樣對(duì)NoSQL的未來(lái)更有好處。當(dāng)我們說(shuō)“x

是一個(gè)NoSQL數(shù)據(jù)庫(kù)”時(shí)，我認(rèn)為把NoSQL解釋成“Not

Only”是愚蠢的，因?yàn)檫@會(huì)讓這個(gè)術(shù)語(yǔ)變得沒(méi)有價(jià)值。(因?yàn)檫@樣一來(lái)你實(shí)際上可以認(rèn)為SQLServer也是一個(gè)NoSQL數(shù)據(jù)庫(kù))。我們應(yīng)該把NoSQL的“not

only”做另外一種理解——盡管這個(gè)時(shí)候我更愿意使用PolyglotPersistence這個(gè)詞。

所以，對(duì)于我們這本書(shū)來(lái)說(shuō)，我們采取的觀點(diǎn)是，NoSQL是目前的數(shù)據(jù)庫(kù)家族的外來(lái)者。它們有些通用的特征，但沒(méi)有一個(gè)是被明確定義的。

不使用關(guān)系數(shù)據(jù)庫(kù)模型(或SQL語(yǔ)言)開(kāi)源針對(duì)大型集群而設(shè)計(jì)

基于21世紀(jì)互聯(lián)網(wǎng)特征的需求

沒(méi)有schema，可以在任何時(shí)候向一條記錄添加新字段

雖然在軟件產(chǎn)業(yè)里我們已經(jīng)習(xí)慣了這種模糊的邊界定義，但我承認(rèn)當(dāng)看到又多了這樣一個(gè)定義后，心里還是有些不爽。但重要的是，在我們以后數(shù)十年的開(kāi)發(fā)工作中，這些數(shù)據(jù)庫(kù)提供了我們重要的補(bǔ)充。在未來(lái)普遍使用的過(guò)程中，這些不清晰的定義頂多就像一個(gè)蚊子的叮咬。