昨天看到一則報(bào)道，繼 Twitter之后，社交新聞網(wǎng)站Digg決定跟 MySQL說再見，并替換掉它的大部分基礎(chǔ)設(shè)施組成，Digg將從LAMP（Linux、 Apache、MySQL和Perl/PHP/Python）架構(gòu)遷移到基于Cassandra的NoSQL架構(gòu)。
隨著Web2.0和云計(jì)算的興起，和一些反SQL的倡導(dǎo)，越來越多的大公司加入到NoSQL陣營。Digg、Twitter、Google、微軟等等公司已經(jīng)開始研究NoSQL，并在一些項(xiàng)目中進(jìn)行實(shí)施。許多人甚至拋棄了MySQL開源數(shù)據(jù)庫這個(gè)長期以來Web 2.0的寵兒，而改由NoSQL的方案來替代，因?yàn)閮?yōu)勢實(shí)在是引人注目。
例如Facebook建立了自己的Cassandra數(shù)據(jù)商店并且在其網(wǎng)站上重點(diǎn)推出一項(xiàng)新的搜索功能，沒有使用到現(xiàn)有的MySQL數(shù)據(jù)庫。據(jù) Facebook的工程師Avinash Lakshma介紹，Cassandra僅用0.12毫秒就可以寫入50GB的數(shù)據(jù)，比MySQL快了超過2500倍。Google也開始公測他們的云數(shù)據(jù)庫Fusion Tables，這是一個(gè)和傳統(tǒng)數(shù)據(jù)庫完全不同的數(shù)據(jù)庫，主要優(yōu)勢能夠簡單的解決關(guān)系型數(shù)據(jù)庫中管理不同類型數(shù)據(jù)麻煩，以及排序整合的常見操作的性能問題等。
那么什么是NoSQL？
以下僅僅從技術(shù)角度來說明什么是NoSQL。
不要叫它們數(shù)據(jù)庫。Amazon.com的首席技術(shù)官Werner Vogels將他們的重要的Dynamo系統(tǒng)稱作“高可用性的鍵值商店”。Google將自己的BigTable稱作“管理結(jié)構(gòu)化數(shù)據(jù)的分布式存儲系統(tǒng)”，在51CTO.com之前的外電《云服務(wù)顛覆開發(fā)傳統(tǒng)觀念》中曾提到，Google的Big Table不是SQL數(shù)據(jù)庫，原因是SQL數(shù)據(jù)庫支持的一些功能實(shí)在難以進(jìn)行分割，這與我們跨機(jī)器存儲數(shù)據(jù)的想法無法結(jié)合。它們都是許多NoSQL追隨者的效仿模式。
它們可以處理超大量的數(shù)據(jù)。比如Zvents公司以BigTable模式搭建的開源數(shù)據(jù)庫Hypertable，據(jù)Zvents工程師Doug Judd介紹，它可以每天在搜索引擎中寫入10億單元數(shù)據(jù)。
另外，BigTable與其姊妹技術(shù)MapReduce相結(jié)合，每天可以處理多達(dá)20PB的數(shù)據(jù)。
“毫無疑問，數(shù)據(jù)量越來越巨大也讓人們尋找其他的數(shù)據(jù)庫替代技術(shù)，”SpringSource的Travis說。
它們運(yùn)行在便宜的PC服務(wù)器集群上。PC集群擴(kuò)充起來非常方便并且成本很低，避免了“sharding”操作的復(fù)雜性和成本。
Google曾表示一個(gè)BigTable的大集群可以管理數(shù)千臺服務(wù)器上多達(dá)6PB的數(shù)據(jù)。
“Oracle會告訴你需要購買一些硬件然后正確配置Oracle RAC，然而用其他的神奇軟件你也可以達(dá)到相同的可擴(kuò)展性。但是兩者的開銷可是天差地別�！盨pringSource首席技術(shù)官Javier Soltero說。
它們擊碎了性能瓶頸。NoSQL的支持者稱，通過NoSQL架構(gòu)可以省去將Web或Java應(yīng)用和數(shù)據(jù)轉(zhuǎn)換成SQL友好格式的時(shí)間，執(zhí)行速度變得更快。
“SQL并非適用于所有的程序代碼，”數(shù)據(jù)庫分析師Curt Monash說。對于那些繁重的重復(fù)操作的數(shù)據(jù)，SQL值得花錢。但是當(dāng)數(shù)據(jù)庫結(jié)構(gòu)非常簡單時(shí)，SQL可能沒有太大用處。
Adobe公司資深計(jì)算機(jī)科學(xué)家Raffaele Sena說，當(dāng)一年半前Adobe準(zhǔn)備重新更新ConnectNow網(wǎng)絡(luò)協(xié)作服務(wù)時(shí)，正是由于上面的理由，他們決定不采用關(guān)系型數(shù)據(jù)庫。
Adobe決定使用Terracotta 提供的Java集群軟件，管理Java格式的數(shù)據(jù)，Sena說，這使ConnectNow的性能提高到前一版本的2至3倍。
沒有過多的操作。雖然NoSQL的支持者也承認(rèn)關(guān)系數(shù)據(jù)庫提供了無可比擬的功能集合，而且在數(shù)據(jù)完整性上也發(fā)揮絕對穩(wěn)定，他們同時(shí)也表示，企業(yè)的具體需求可能沒有那么多。
以Adobe的ConnectNow為例，Sena說，當(dāng)用戶在線時(shí)它會不通過數(shù)據(jù)庫而制作三份會話數(shù)據(jù)，在離線后刪除�！耙虼宋覀儾⒉恍枰獢�(shù)據(jù)庫，因?yàn)榫唧w所需要的數(shù)據(jù)是在內(nèi)存中的，”他說。
NoSQL橫空出世
2009年6月，NoSQL運(yùn)動(dòng)成員的一次全球性聚會引爆了一場“數(shù)據(jù)庫革命”的導(dǎo)火索。在此次會議上，熱衷于NoSQL的人們分享著推翻緩慢而昂貴的關(guān)系型數(shù)據(jù)庫，用更有效和便宜的方法來管理數(shù)據(jù)的創(chuàng)新構(gòu)想。NoSQL之所以備受矚目，與用戶對傳統(tǒng)關(guān)系模型和關(guān)系型數(shù)據(jù)庫的負(fù)面看法直接相關(guān)。在這些質(zhì)疑聲中，有很多的確是用戶在數(shù)據(jù)庫應(yīng)用過程中所遇到的實(shí)際問題。而這些問題與Web 2.0應(yīng)用的風(fēng)行息息相關(guān)。
NoSQL的支持者認(rèn)為，關(guān)系模型人為地扭曲了目標(biāo)對象的本質(zhì)內(nèi)容，過于僵化，尤其不利于Web 2.0應(yīng)用的操作�，F(xiàn)有的關(guān)系數(shù)據(jù)庫產(chǎn)品，似乎都對數(shù)據(jù)的寫入增加過多負(fù)載，以至于難于適應(yīng)Web 2.0環(huán)境下大量非結(jié)構(gòu)化內(nèi)容信息的入庫，包括博客、視頻、音效等。
從技術(shù)體系上看，關(guān)系數(shù)據(jù)庫更多強(qiáng)調(diào)集中或者有限節(jié)點(diǎn)集群的架構(gòu)，而沒有對信息內(nèi)容面向大量廉價(jià)的分散計(jì)算單元進(jìn)行設(shè)計(jì)，以致于無法支持類似Google BigTable、Amazon Dynamo這樣的世界級信息管理技術(shù)。
顯而易見，NoSQL運(yùn)動(dòng)將矛頭直指傳統(tǒng)數(shù)據(jù)庫的主宰者。雖然這在短期內(nèi)無法動(dòng)搖關(guān)系型數(shù)據(jù)庫帝國，但是它所掀起的湍流卻在數(shù)據(jù)庫領(lǐng)域拍打出陣陣鳴響。
技術(shù)差異解讀
除了以Web 2.0為代表的應(yīng)用潮流的涌動(dòng)，以及用戶行為習(xí)慣的因素外，NoSQL的提出者們有著非常明確的技術(shù)特征考慮。具體如下。
1．讀寫方式的差異
以往的關(guān)系數(shù)據(jù)庫更多地是面向“多讀少寫”（Read heavy）、讀寫并重（Read and write heavy）的情況。因?yàn)樾畔⑹菑纳逃玫慕嵌葋硎占蛥R總的，用戶之所以會訪問某個(gè)站點(diǎn)，也是因?yàn)閷ζ鋬?nèi)容優(yōu)勢類別的選擇。信息寫入后，在相對少的修改情況下，被大量的受眾訪問和閱讀。
Web 2.0環(huán)境把這種情況徹底改變了�！罢军c(diǎn)搭臺您唱戲”，內(nèi)容的提供者是一個(gè)個(gè)分離的個(gè)體。他們把自己的信息貢獻(xiàn)到站點(diǎn)，但信息卻不如前者那樣會被密集地訪問，即便有個(gè)別的明星博客、SNS焦點(diǎn)神秘嘉賓，但總體上是形成了“少讀多寫”（Write heavy）的局面（其中的差異如圖1和圖2所示）。
反觀現(xiàn)有的關(guān)系數(shù)據(jù)庫，主要面向前者模式而設(shè)計(jì)。而且為了實(shí)現(xiàn)數(shù)據(jù)驅(qū)動(dòng)、內(nèi)容驅(qū)動(dòng)，以及預(yù)定式信息處理，往往要對“寫”賦予過多的額外內(nèi)容。其中包括生成重做日志、檢查各類鎖控制、激發(fā)觸發(fā)器并對觸發(fā)的內(nèi)容作出響應(yīng)等。
不僅如此，在數(shù)據(jù)寫入后，關(guān)系型數(shù)據(jù)庫還要提供復(fù)雜的分布式處理。這包括信息復(fù)制、內(nèi)容歸檔、觸發(fā)信息CDC準(zhǔn)實(shí)時(shí)抓取和分發(fā)、通知外圍監(jiān)控系統(tǒng)等�？傊�，關(guān)系型數(shù)據(jù)庫在自我束縛的同時(shí),并沒有提供“少讀多寫”信息應(yīng)用模式所需要的良好處理性能。
NoSQL的思路則正好相反。他們認(rèn)為，只給用戶“必要的”功能，而且這些解決方案是可以開源的，讓大家可以“自助式”地進(jìn)行讀寫處理，進(jìn)而將數(shù)TB、甚至PB的信息加以管理。所有的讀寫操作也都是直入主題的，運(yùn)行環(huán)境不要求、也不提供多余的操作，最終加速用戶的“少讀多寫”的性能。
那么，是否真的要按照NoSQL的思路扔掉企業(yè)的各種商用關(guān)系型數(shù)據(jù)庫呢？顯然不行。
對于數(shù)據(jù)庫用戶，尤其是企業(yè)用戶而言，建立信息系統(tǒng)的目的往往不是為了吸引眼球，而是為了能解決特定領(lǐng)域的商業(yè)流程自動(dòng)化，或者半自動(dòng)化。從整體商業(yè)環(huán)境看，大部分行業(yè)的商業(yè)流程主干趨于固定化。而且為了實(shí)現(xiàn)不同信息所有者、商業(yè)合作伙伴間的信息集成，信息格式和表達(dá)方式也趨于規(guī)范。
因此，這些信息依然是“多讀少寫”或者“多讀多寫”的。而且伴隨BI（商業(yè)智能）的興起，這些結(jié)構(gòu)化程度很高的信息不僅僅用于流通環(huán)節(jié)和操作環(huán)節(jié)的OLTP（聯(lián)機(jī)事務(wù)處理），還會用于或被用于ODS（操作型數(shù)據(jù)存儲）、聯(lián)機(jī)分析、數(shù)據(jù)挖掘等。從這個(gè)角度看，企業(yè)中的關(guān)系數(shù)據(jù)庫（商用或開源）仍然非常重要。
2．開源和成本約束
是否“開源”，也是NoSQL被關(guān)注的一個(gè)重點(diǎn)，主要原因同樣在于，過度的商業(yè)化有形或無形中會導(dǎo)致關(guān)系數(shù)據(jù)庫的復(fù)雜化。兩個(gè)技術(shù)特征的差異是互為因果的。
和超市搭售一樣，用戶往往會因?yàn)閮r(jià)格因素買一個(gè)相對“成熟”、“全面”的關(guān)系數(shù)據(jù)庫產(chǎn)品。因?yàn)槟菢映孙@性成本的優(yōu)勢外，還包括消除了出現(xiàn)問題時(shí)廠商間相互推諉等隱憂。這就要求商用產(chǎn)品自身擴(kuò)充功能，擴(kuò)充那些在每個(gè)用戶的情境下都可冗余的功能。
不過，一旦購買了這種“包治百病”的產(chǎn)品后，因?yàn)楫a(chǎn)品特性間的相互制肘，本應(yīng)更快地讀/寫操作，尤其是寫入操作變得慢了。這也就不難理解，為什么NoSQL大會的矛頭最后指向了曾經(jīng)的開源領(lǐng)袖——MySQL。NoSQL的支持者認(rèn)為，曾經(jīng)可以在巨量廉價(jià)設(shè)備上使用的MySQL，在被商用化后增加了一些他們用不到的功能。雖然每個(gè)許可看起來都是小錢，但如果乘以一個(gè)龐大的基數(shù)就無法承受了。
那么，NoSQL所提出的開源理念能否獲得用戶的認(rèn)可呢？很有可能。
隨著技術(shù)門檻的降低，以及開源運(yùn)動(dòng)的深入，越來越多以往只有通過嚴(yán)密技術(shù)轉(zhuǎn)讓合同才能了解的技術(shù)領(lǐng)域，現(xiàn)在可以通過互聯(lián)網(wǎng)就可免費(fèi)學(xué)習(xí)和使用了。而開源軟件的大多數(shù)常用的功能領(lǐng)域也趨于強(qiáng)健。同時(shí)，圍繞開源產(chǎn)品也形成了一個(gè)新的技術(shù)生態(tài)圈，企業(yè)用戶可以從這些圈中獲得所需的技術(shù)支持和第三方服務(wù)。尤其在關(guān)系型數(shù)據(jù)庫領(lǐng)域，已經(jīng)有很多企業(yè)開始采用或嘗試使用開源產(chǎn)品。雖然受到企業(yè)技術(shù)戰(zhàn)略的影響，質(zhì)疑之聲在所難免，但很多非核心系統(tǒng)采用開源關(guān)系型數(shù)據(jù)庫配合開源框架成為越來越多企業(yè)的共同選擇。
NoSQL提出的分布式設(shè)計(jì)對很多企業(yè)而言暫時(shí)還用不到，或者說企業(yè)IT環(huán)境暫時(shí)還沒有演變到這個(gè)階段。但分布式非數(shù)據(jù)庫信息系統(tǒng)會在類似Google、Amazon這樣的互聯(lián)網(wǎng)廠商的催化下漸漸催生出新的綜合性應(yīng)用產(chǎn)品，而屆時(shí)一些IT演進(jìn)快速的企業(yè)也正好到了適用階段。所以，NoSQL旗手們的開拓之路很有可能被普通用戶或者是企業(yè)用戶接受。
3．加工對象容量設(shè)計(jì)的分歧
NoSQL強(qiáng)調(diào)“大”數(shù)據(jù)量，那么這些TB，甚至PB級的寫入對于絕大多數(shù)的用戶有多少實(shí)際的意義呢？
經(jīng)典的關(guān)系數(shù)據(jù)模型并沒有對數(shù)據(jù)容量有明確的限制，但現(xiàn)實(shí)環(huán)境下用戶（尤其是Web 2.0產(chǎn)品的運(yùn)營商們）卻不得不考慮數(shù)據(jù)容量的限制問題。借助各種信息平臺，掩蓋在互聯(lián)網(wǎng)下面的海量用戶無時(shí)無刻地不在制造或者拼湊著大量的信息，這些信息可能小到Twitter上的一句“Hi！”，也可能大到一張藍(lán)光電影。如果繼續(xù)用關(guān)系型數(shù)據(jù)庫來處理他們，運(yùn)營商不僅僅是賠本賺吆喝了，很可能是賣血也聽不到吆喝聲。NoSQL的領(lǐng)袖們正是看到了這一點(diǎn)，嘗試自主策劃全新的技術(shù)實(shí)現(xiàn)手段。
在正視大容量數(shù)據(jù)情景的同時(shí)，我們是否應(yīng)該立即扔掉傳統(tǒng)的關(guān)系型數(shù)據(jù)庫，轉(zhuǎn)向“大小通吃”的NoSQL環(huán)境呢？也不是。
現(xiàn)實(shí)中，絕大部分應(yīng)用并沒有這么大的信息量，尤其當(dāng)信息是來自用戶輸入和登記的情況下。而且，即便是圖片信息，大多數(shù)情況下，在現(xiàn)有顯示設(shè)備支持下也沒必要個(gè)個(gè)都異常細(xì)致。隨著一個(gè)個(gè)行業(yè)信息標(biāo)準(zhǔn)的推出，很多行業(yè)的數(shù)據(jù)容量不僅可以評估，甚至可以較為準(zhǔn)確地預(yù)測。而NoSQL雖然提供了很好的寫入效率，但并沒有對查詢操作提供兼具關(guān)系數(shù)據(jù)庫豐富功能和NoSQL寫入效率優(yōu)勢的解決方案。甚至很多方案在檢索相同信息的時(shí)候，效率還會遠(yuǎn)遠(yuǎn)低于關(guān)系型數(shù)據(jù)庫。從這個(gè)角度分析，關(guān)系型數(shù)據(jù)庫盡管提供的容量支持有限，但對于絕大多數(shù)的商業(yè)數(shù)據(jù)處理，它則更好地兼顧了讀取和寫入，而且功能更符合絕大部分商業(yè)情景的需要。
數(shù)據(jù)庫的用戶應(yīng)該如何看待這個(gè)問題呢？筆者認(rèn)為，關(guān)系型數(shù)據(jù)庫和NoSQL的差異性反而有利于用戶根據(jù)自己的應(yīng)用情景靈活選擇，我們不僅要利用NoSQL的快速寫入能力，更要兩者兼融并蓄，取長補(bǔ)短。
向NoSQL學(xué)習(xí)
NoSQL的理念固然尖銳，它質(zhì)疑關(guān)系型數(shù)據(jù)庫的積弊和不足。那么，從這些批評聲中，傳統(tǒng)的關(guān)系數(shù)據(jù)庫應(yīng)該學(xué)習(xí)點(diǎn)什么呢？
首先，產(chǎn)品需要補(bǔ)課。關(guān)系型數(shù)據(jù)庫不僅要著眼傳統(tǒng)的商業(yè)信息處理，還要照顧到伴隨Web 2.0而來的全新用戶使用場景。要滿足這些特征，需要數(shù)據(jù)庫廠商苦練內(nèi)功。以寫入操作為例，需要根據(jù)不同類型的數(shù)據(jù)容量提供多種寫入策略。讓那些需要嚴(yán)加管控的能“管得住”，沒有附加條件的寫入就要迅速完成。
其次，要賦予用戶更多的自由裁量權(quán)，提供更多的版本選擇余地。盡管在商業(yè)上捆綁銷售對于用戶，尤其是大型企業(yè)用戶是非常有效的營銷手段，但也要看到IT領(lǐng)域中開源軟件強(qiáng)勁的競爭勢頭。傳統(tǒng)數(shù)據(jù)庫廠商應(yīng)該在產(chǎn)品“減肥”上多下功夫。
除此之外，網(wǎng)格也好，云數(shù)據(jù)服務(wù)也好，在確保集中式一站管理的前提下，都要把單純的集中式接入控制變成滿足更豐富分布式接入的體系，減少現(xiàn)有數(shù)據(jù)庫的應(yīng)用瓶頸。避免即便采用數(shù)十個(gè)高端服務(wù)器節(jié)點(diǎn)的集群也難于承載應(yīng)用負(fù)荷的情況。從某種程度看上，必須要提供線形、可預(yù)測的投入/產(chǎn)出績效。
關(guān)系型數(shù)據(jù)庫未死
每一次技術(shù)變革都會催生出一批新的產(chǎn)品和開發(fā)工具。關(guān)系型數(shù)據(jù)庫也許因?yàn)樘^“四平八穩(wěn)”了，所以多年來從“現(xiàn)代應(yīng)用的中心”演變成廠商薄利多銷的傳統(tǒng)市場。NoSQL的出現(xiàn)不僅對促進(jìn)傳統(tǒng)數(shù)據(jù)庫廠商改進(jìn)技術(shù)有所幫助，對用戶也會帶來更多啟示。尤其是在大部分企業(yè)擁有自己專業(yè)IT隊(duì)伍的情況下，與SOA類似，借助NoSQL的思想和成果，企業(yè)可以更加靈活地設(shè)計(jì)自己的IT建設(shè)框架。筆者認(rèn)為，在未來一個(gè)更好的解決方案或許是歸于以下的架構(gòu)：
1．結(jié)構(gòu)化程度很高、結(jié)構(gòu)相對穩(wěn)定的數(shù)據(jù)信息繼續(xù)采用關(guān)系模型管理；
2．雖然結(jié)構(gòu)化程度不高，但信息內(nèi)容仍然可以通過水平、垂直關(guān)系關(guān)聯(lián)，并明確表示的數(shù)據(jù)信息采用以XML為代表的層次化模型管理；
3．對于較大的流式信息、無結(jié)構(gòu)信息，如果需要“多讀少寫”或者“多讀多寫”，就采用傳統(tǒng)的分布式文件系統(tǒng)，以共享磁盤陣列的方式保存；
4．對于非常巨大的文件，而且“少讀多寫”的信息，可以借鑒或采用NoSQL的方案解決。
而在整個(gè)架構(gòu)中，關(guān)系型數(shù)據(jù)庫仍然是信息管理的核心，保存著最重要的、最控制商業(yè)價(jià)值的數(shù)據(jù)信息�？傊�，只要把握住關(guān)鍵商業(yè)環(huán)節(jié)和關(guān)鍵商業(yè)價(jià)值，關(guān)系型數(shù)據(jù)庫現(xiàn)在看來依然會活得有聲有色。