昨天看到一則報道，繼 Twitter之后，社交新聞網站Digg決定跟 MySQL說再見，并替換掉它的大部分基礎設施組成，Digg將從LAMP（Linux、 Apache、MySQL和Perl/PHP/Python）架構遷移到基于Cassandra的NoSQL架構。

　　隨著Web2.0和云計算的興起，和一些反SQL的倡導，越來越多的大公司加入到NoSQL陣營。Digg、Twitter、Google、微軟等等公司已經開始研究NoSQL，并在一些項目中進行實施。許多人甚至拋棄了MySQL開源數據庫這個長期以來Web 2.0的寵兒，而改由NoSQL的方案來替代，因為優勢實在是引人注目。

　　例如Facebook建立了自己的Cassandra數據商店并且在其網站上重點推出一項新的搜索功能，沒有使用到現有的MySQL數據庫。據 Facebook的工程師Avinash Lakshma介紹，Cassandra僅用0.12毫秒就可以寫入50GB的數據，比MySQL快了超過2500倍。Google也開始公測他們的云數據庫Fusion Tables，這是一個和傳統數據庫完全不同的數據庫，主要優勢能夠簡單的解決關系型數據庫中管理不同類型數據麻煩，以及排序整合的常見操作的性能問題等。

　　那么什么是NoSQL？

　　以下僅僅從技術角度來說明什么是NoSQL。

　　不要叫它們數據庫。Amazon.com的首席技術官Werner Vogels將他們的重要的Dynamo系統稱作“高可用性的鍵值商店”。Google將自己的BigTable稱作“管理結構化數據的分布式存儲系統”，在51CTO.com之前的外電《云服務顛覆開發傳統觀念》中曾提到，Google的Big Table不是SQL數據庫，原因是SQL數據庫支持的一些功能實在難以進行分割，這與我們跨機器存儲數據的想法無法結合。它們都是許多NoSQL追隨者的效仿模式。

　　它們可以處理超大量的數據。比如Zvents公司以BigTable模式搭建的開源數據庫Hypertable，據Zvents工程師Doug Judd介紹，它可以每天在搜索引擎中寫入10億單元數據。

　　另外，BigTable與其姊妹技術MapReduce相結合，每天可以處理多達20PB的數據。

　　“毫無疑問，數據量越來越巨大也讓人們尋找其他的數據庫替代技術，”SpringSource的Travis說。

　　它們運行在便宜的PC服務器集群上。PC集群擴充起來非常方便并且成本很低，避免了“sharding”操作的復雜性和成本。

　　Google曾表示一個BigTable的大集群可以管理數千臺服務器上多達6PB的數據。

　　“Oracle會告訴你需要購買一些硬件然后正確配置Oracle RAC，然而用其他的神奇軟件你也可以達到相同的可擴展性。但是兩者的開銷可是天差地別。”SpringSource首席技術官Javier Soltero說。

　　它們擊碎了性能瓶頸。NoSQL的支持者稱，通過NoSQL架構可以省去將Web或Java應用和數據轉換成SQL友好格式的時間，執行速度變得更快。

　　“SQL并非適用于所有的程序代碼，”數據庫分析師Curt Monash說。對于那些繁重的重復操作的數據，SQL值得花錢。但是當數據庫結構非常簡單時，SQL可能沒有太大用處。

　　Adobe公司資深計算機科學家Raffaele Sena說，當一年半前Adobe準備重新更新ConnectNow網絡協作服務時，正是由于上面的理由，他們決定不采用關系型數據庫。

　　Adobe決定使用Terracotta 提供的Java集群軟件，管理Java格式的數據，Sena說，這使ConnectNow的性能提高到前一版本的2至3倍。

沒有過多的操作。雖然NoSQL的支持者也承認關系數據庫提供了無可比擬的功能集合，而且在數據完整性上也發揮絕對穩定，他們同時也表示，企業的具體需求可能沒有那么多。

　　以Adobe的ConnectNow為例，Sena說，當用戶在線時它會不通過數據庫而制作三份會話數據，在離線后刪除。“因此我們并不需要數據庫，因為具體所需要的數據是在內存中的，”他說。

　　NoSQL橫空出世

　　2009年6月，NoSQL運動成員的一次全球性聚會引爆了一場“數據庫革命”的導火索。在此次會議上，熱衷于NoSQL的人們分享著推翻緩慢而昂貴的關系型數據庫，用更有效和便宜的方法來管理數據的創新構想。NoSQL之所以備受矚目，與用戶對傳統關系模型和關系型數據庫的負面看法直接相關。在這些質疑聲中，有很多的確是用戶在數據庫應用過程中所遇到的實際問題。而這些問題與Web 2.0應用的風行息息相關。

　　NoSQL的支持者認為，關系模型人為地扭曲了目標對象的本質內容，過于僵化，尤其不利于Web 2.0應用的操作。現有的關系數據庫產品，似乎都對數據的寫入增加過多負載，以至于難于適應Web 2.0環境下大量非結構化內容信息的入庫，包括博客、視頻、音效等。

　　從技術體系上看，關系數據庫更多強調集中或者有限節點集群的架構，而沒有對信息內容面向大量廉價的分散計算單元進行設計，以致于無法支持類似Google BigTable、Amazon Dynamo這樣的世界級信息管理技術。

　　顯而易見，NoSQL運動將矛頭直指傳統數據庫的主宰者。雖然這在短期內無法動搖關系型數據庫帝國，但是它所掀起的湍流卻在數據庫領域拍打出陣陣鳴響。

　　技術差異解讀

　　除了以Web 2.0為代表的應用潮流的涌動，以及用戶行為習慣的因素外，NoSQL的提出者們有著非常明確的技術特征考慮。具體如下。

　　1．讀寫方式的差異

　　以往的關系數據庫更多地是面向“多讀少寫”（Read heavy）、讀寫并重（Read and write heavy）的情況。因為信息是從商用的角度來收集和匯總的，用戶之所以會訪問某個站點，也是因為對其內容優勢類別的選擇。信息寫入后，在相對少的修改情況下，被大量的受眾訪問和閱讀。

　　Web 2.0環境把這種情況徹底改變了。“站點搭臺您唱戲”，內容的提供者是一個個分離的個體。他們把自己的信息貢獻到站點，但信息卻不如前者那樣會被密集地訪問，即便有個別的明星博客、SNS焦點神秘嘉賓，但總體上是形成了“少讀多寫”（Write heavy）的局面（其中的差異如圖1和圖2所示）。

 

　　反觀現有的關系數據庫，主要面向前者模式而設計。而且為了實現數據驅動、內容驅動，以及預定式信息處理，往往要對“寫”賦予過多的額外內容。其中包括生成重做日志、檢查各類鎖控制、激發觸發器并對觸發的內容作出響應等。

　　不僅如此，在數據寫入后，關系型數據庫還要提供復雜的分布式處理。這包括信息復制、內容歸檔、觸發信息CDC準實時抓取和分發、通知外圍監控系統等。總之，關系型數據庫在自我束縛的同時,并沒有提供“少讀多寫”信息應用模式所需要的良好處理性能。

　　NoSQL的思路則正好相反。他們認為，只給用戶“必要的”功能，而且這些解決方案是可以開源的，讓大家可以“自助式”地進行讀寫處理，進而將數TB、甚至PB的信息加以管理。所有的讀寫操作也都是直入主題的，運行環境不要求、也不提供多余的操作，最終加速用戶的“少讀多寫”的性能。

　　那么，是否真的要按照NoSQL的思路扔掉企業的各種商用關系型數據庫呢？顯然不行。

　　對于數據庫用戶，尤其是企業用戶而言，建立信息系統的目的往往不是為了吸引眼球，而是為了能解決特定領域的商業流程自動化，或者半自動化。從整體商業環境看，大部分行業的商業流程主干趨于固定化。而且為了實現不同信息所有者、商業合作伙伴間的信息集成，信息格式和表達方式也趨于規范。

　　因此，這些信息依然是“多讀少寫”或者“多讀多寫”的。而且伴隨BI（商業智能）的興起，這些結構化程度很高的信息不僅僅用于流通環節和操作環節的OLTP（聯機事務處理），還會用于或被用于ODS（操作型數據存儲）、聯機分析、數據挖掘等。從這個角度看，企業中的關系數據庫（商用或開源）仍然非常重要。

　　2．開源和成本約束

　　是否“開源”，也是NoSQL被關注的一個重點，主要原因同樣在于，過度的商業化有形或無形中會導致關系數據庫的復雜化。兩個技術特征的差異是互為因果的。

　　和超市搭售一樣，用戶往往會因為價格因素買一個相對“成熟”、“全面”的關系數據庫產品。因為那樣除了顯性成本的優勢外，還包括消除了出現問題時廠商間相互推諉等隱憂。這就要求商用產品自身擴充功能，擴充那些在每個用戶的情境下都可冗余的功能。

　　不過，一旦購買了這種“包治百病”的產品后，因為產品特性間的相互制肘，本應更快地讀/寫操作，尤其是寫入操作變得慢了。這也就不難理解，為什么NoSQL大會的矛頭最后指向了曾經的開源領袖——MySQL。NoSQL的支持者認為，曾經可以在巨量廉價設備上使用的MySQL，在被商用化后增加了一些他們用不到的功能。雖然每個許可看起來都是小錢，但如果乘以一個龐大的基數就無法承受了。

　　那么，NoSQL所提出的開源理念能否獲得用戶的認可呢？很有可能。

　　隨著技術門檻的降低，以及開源運動的深入，越來越多以往只有通過嚴密技術轉讓合同才能了解的技術領域，現在可以通過互聯網就可免費學習和使用了。而開源軟件的大多數常用的功能領域也趨于強健。同時，圍繞開源產品也形成了一個新的技術生態圈，企業用戶可以從這些圈中獲得所需的技術支持和第三方服務。尤其在關系型數據庫領域，已經有很多企業開始采用或嘗試使用開源產品。雖然受到企業技術戰略的影響，質疑之聲在所難免，但很多非核心系統采用開源關系型數據庫配合開源框架成為越來越多企業的共同選擇。

　　NoSQL提出的分布式設計對很多企業而言暫時還用不到，或者說企業IT環境暫時還沒有演變到這個階段。但分布式非數據庫信息系統會在類似Google、Amazon這樣的互聯網廠商的催化下漸漸催生出新的綜合性應用產品，而屆時一些IT演進快速的企業也正好到了適用階段。所以，NoSQL旗手們的開拓之路很有可能被普通用戶或者是企業用戶接受。

　　3．加工對象容量設計的分歧

　　NoSQL強調“大”數據量，那么這些TB，甚至PB級的寫入對于絕大多數的用戶有多少實際的意義呢？

　　經典的關系數據模型并沒有對數據容量有明確的限制，但現實環境下用戶（尤其是Web 2.0產品的運營商們）卻不得不考慮數據容量的限制問題。借助各種信息平臺，掩蓋在互聯網下面的海量用戶無時無刻地不在制造或者拼湊著大量的信息，這些信息可能小到Twitter上的一句“Hi！”，也可能大到一張藍光電影。如果繼續用關系型數據庫來處理他們，運營商不僅僅是賠本賺吆喝了，很可能是賣血也聽不到吆喝聲。NoSQL的領袖們正是看到了這一點，嘗試自主策劃全新的技術實現手段。

　　在正視大容量數據情景的同時，我們是否應該立即扔掉傳統的關系型數據庫，轉向“大小通吃”的NoSQL環境呢？也不是。

　　現實中，絕大部分應用并沒有這么大的信息量，尤其當信息是來自用戶輸入和登記的情況下。而且，即便是圖片信息，大多數情況下，在現有顯示設備支持下也沒必要個個都異常細致。隨著一個個行業信息標準的推出，很多行業的數據容量不僅可以評估，甚至可以較為準確地預測。而NoSQL雖然提供了很好的寫入效率，但并沒有對查詢操作提供兼具關系數據庫豐富功能和NoSQL寫入效率優勢的解決方案。甚至很多方案在檢索相同信息的時候，效率還會遠遠低于關系型數據庫。從這個角度分析，關系型數據庫盡管提供的容量支持有限，但對于絕大多數的商業數據處理，它則更好地兼顧了讀取和寫入，而且功能更符合絕大部分商業情景的需要。

　　數據庫的用戶應該如何看待這個問題呢？筆者認為，關系型數據庫和NoSQL的差異性反而有利于用戶根據自己的應用情景靈活選擇，我們不僅要利用NoSQL的快速寫入能力，更要兩者兼融并蓄，取長補短。

　　向NoSQL學習

　　NoSQL的理念固然尖銳，它質疑關系型數據庫的積弊和不足。那么，從這些批評聲中，傳統的關系數據庫應該學習點什么呢？

　　首先，產品需要補課。關系型數據庫不僅要著眼傳統的商業信息處理，還要照顧到伴隨Web 2.0而來的全新用戶使用場景。要滿足這些特征，需要數據庫廠商苦練內功。以寫入操作為例，需要根據不同類型的數據容量提供多種寫入策略。讓那些需要嚴加管控的能“管得住”，沒有附加條件的寫入就要迅速完成。

　　其次，要賦予用戶更多的自由裁量權，提供更多的版本選擇余地。盡管在商業上捆綁銷售對于用戶，尤其是大型企業用戶是非常有效的營銷手段，但也要看到IT領域中開源軟件強勁的競爭勢頭。傳統數據庫廠商應該在產品“減肥”上多下功夫。

　　除此之外，網格也好，云數據服務也好，在確保集中式一站管理的前提下，都要把單純的集中式接入控制變成滿足更豐富分布式接入的體系，減少現有數據庫的應用瓶頸。避免即便采用數十個高端服務器節點的集群也難于承載應用負荷的情況。從某種程度看上，必須要提供線形、可預測的投入/產出績效。

　　關系型數據庫未死

　　每一次技術變革都會催生出一批新的產品和開發工具。關系型數據庫也許因為太過“四平八穩”了，所以多年來從“現代應用的中心”演變成廠商薄利多銷的傳統市場。NoSQL的出現不僅對促進傳統數據庫廠商改進技術有所幫助，對用戶也會帶來更多啟示。尤其是在大部分企業擁有自己專業IT隊伍的情況下，與SOA類似，借助NoSQL的思想和成果，企業可以更加靈活地設計自己的IT建設框架。筆者認為，在未來一個更好的解決方案或許是歸于以下的架構：

　　1．結構化程度很高、結構相對穩定的數據信息繼續采用關系模型管理；

　　2．雖然結構化程度不高，但信息內容仍然可以通過水平、垂直關系關聯，并明確表示的數據信息采用以XML為代表的層次化模型管理；

　　3．對于較大的流式信息、無結構信息，如果需要“多讀少寫”或者“多讀多寫”，就采用傳統的分布式文件系統，以共享磁盤陣列的方式保存；

　　4．對于非常巨大的文件，而且“少讀多寫”的信息，可以借鑒或采用NoSQL的方案解決。

　　而在整個架構中，關系型數據庫仍然是信息管理的核心，保存著最重要的、最控制商業價值的數據信息。總之，只要把握住關鍵商業環節和關鍵商業價值，關系型數據庫現在看來依然會活得有聲有色。