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