導讀：Mike Loukides是O'Reilly傳媒的內(nèi)容戰(zhàn)略副總裁，他對編程語言和UNIX系統(tǒng)管理非常感興趣，著作有System Performance Tuning和Unix Power Tools。

在去年的一次談話中，basho公司的CTO Justin Sheehy認為，NoSQL是一場運動，而非技術(shù)。我立刻深表贊同，因為以往關(guān)于NoSQL的探討并不舒心。

那么，為什么說NoSQL是一場運動，而非技術(shù)呢？Justin的說法直截了當：之所以說NoSQL是一場運動，是因為這是對數(shù)據(jù)庫架構(gòu)的選擇。任何一種單一的技術(shù)主題，反而會掩蓋NoSQL運動的實質(zhì)。

自八十年代以來，關(guān)系型數(shù)據(jù)庫（如SQL Server、Oracle和DB2）一直都是后端業(yè)務(wù)系統(tǒng)的主導。這些關(guān)系型數(shù)據(jù)庫產(chǎn)品都非常優(yōu)秀，它們之間有許多共通之處。

回顧一下以往15年的軟件開發(fā)歷程，我們已經(jīng)構(gòu)建了許多優(yōu)秀的大型數(shù)據(jù)庫應(yīng)用，其中不乏Web應(yīng)用。但是自關(guān)系型數(shù)據(jù)庫誕生以來，數(shù)據(jù)庫領(lǐng)域已經(jīng)產(chǎn)生了許多變化：

——數(shù)據(jù)激增。雖然存儲的容量和CPU的速度都在飛速發(fā)展，使得數(shù)據(jù)庫可以應(yīng)對數(shù)據(jù)量的激增，但是數(shù)據(jù)量的確是一個棘手的問題，對于任何重要的數(shù)據(jù)庫而言，分布式必不可少。

——亞秒級的查詢響應(yīng)。在八十年代，數(shù)據(jù)庫查詢以批處理的方式運行，查詢效率低下。現(xiàn)在的互聯(lián)網(wǎng)，已經(jīng)從靜態(tài)文件發(fā)展到由復雜數(shù)據(jù)庫支撐的站點，而且對于大多數(shù)查詢，我們需要亞秒級的響應(yīng)時間。

——7*24小時正常運行。為靜態(tài)HTML文件設(shè)置冗余服務(wù)器非常容易，但復雜的數(shù)據(jù)庫復制就另當別論了。

——對高速數(shù)據(jù)流的捕捉越來越重要。許多應(yīng)用的后臺數(shù)據(jù)庫吸納數(shù)據(jù)的速度遠遠快于處理數(shù)據(jù)查詢的速度。比如，在日志應(yīng)用或者分布式傳感應(yīng)用數(shù)據(jù)庫中，寫入比查詢頻繁的多。ETL（數(shù)據(jù)提取、轉(zhuǎn)換和加載）固然不可或缺，但對高速數(shù)據(jù)流的捕捉顯得越來越重要。

——非結(jié)構(gòu)化數(shù)據(jù)。非結(jié)構(gòu)化數(shù)據(jù)早就存在，并不是數(shù)據(jù)世界里的新景觀，但我們越來越不希望強制數(shù)據(jù)結(jié)構(gòu)。

——犧牲ACID。ACID（原子性、一致性、隔離性、持久性）雖然很重要，但現(xiàn)代應(yīng)用帶來的挑戰(zhàn)讓我們意識到，為了實現(xiàn)其它特性（如低延遲和可用性），我們必須做出犧牲。

需求的不斷變化，迫使我們不得不思考全新的數(shù)據(jù)庫解決方案：

——分布式。龐大的數(shù)據(jù)庫只是采用分布式的一個原因，另一個原因是現(xiàn)代應(yīng)用（尤其是Web應(yīng)用）要求滿足許多在線用戶的瞬時響應(yīng)。響應(yīng)時間每超時一秒，都會造成大量用戶流失。

——實時計算。如果你正通過構(gòu)建在線應(yīng)用支持業(yè)務(wù)分析，那么用戶必然期望實時業(yè)務(wù)分析。這不僅便捷，每天執(zhí)行成百上千的查詢，徹底改觀了我們的工作。

——可擴展性。如果你正在構(gòu)建一個面向客戶的應(yīng)用，進行業(yè)務(wù)分析，那么可擴展性是一個大問題。垂直可擴展性已經(jīng)近乎極限，物理定律的制約使得Intel架構(gòu)的時鐘頻率在3.5GHz的范圍內(nèi)徘徊不前，水平可擴展性（構(gòu)建多節(jié)點分布式系統(tǒng)）成了唯一的途徑。

——高可用性。應(yīng)用系統(tǒng)架構(gòu)中的任何一部分出現(xiàn)單點故障，都會導致災難性的后果，數(shù)據(jù)庫系統(tǒng)必須提供高可用性支持。一個高可用性系統(tǒng)天然就是一個分布式系統(tǒng)。

——數(shù)據(jù)分片。對于一個給定的分布式數(shù)據(jù)庫，接下來的問題就是數(shù)據(jù)分片。關(guān)系型數(shù)據(jù)庫在多臺主機之間采用手動分片，或者基于數(shù)據(jù)本身的某些屬性對數(shù)據(jù)集進行分區(qū)。MongoDB非常容易進行數(shù)據(jù)分片，HBase、Riak和Cassandra本身就是分布式數(shù)據(jù)庫。

——Schemaless（無模式）。NoSQL數(shù)據(jù)庫通常稱為schemaless（無模式），因為它們與關(guān)系型數(shù)據(jù)庫的架構(gòu)形態(tài)無關(guān)。事實上，NoSQL并非完全無模式。在像CouchDB或MongoDB這樣的文檔數(shù)據(jù)庫中，文檔是許多鍵值對（key-value）。Riak也可以被看做是一個文檔數(shù)據(jù)庫，但比文檔類型更靈活。Cassandra和HBase被稱為面向列的數(shù)據(jù)庫。在大多數(shù)應(yīng)用開發(fā)中，NoSQL數(shù)據(jù)庫前期規(guī)劃更少，靈活性更大，更適合敏捷開發(fā)。

——ACID和CAP。ACID屬性深入人心，但如果我們仔細思考數(shù)據(jù)庫的架構(gòu)，就會發(fā)現(xiàn)對一個分布式系統(tǒng)實現(xiàn)一致性和隔離性等ACID屬性非常困難。ACID屬性非常重要，但自由的選擇需要折中。CAP定律指出，對于一個分布式計算系統(tǒng)，一致性、可用性和分區(qū)容錯性只能同時滿足其中二者。

——腳本語言。所有的關(guān)系型數(shù)據(jù)庫都有SQL語言變種（例如，T-SQL和PL/SQL）作為數(shù)據(jù)腳本語言。在非關(guān)系型數(shù)據(jù)庫的世界里，也有一些腳本語言可用。CouchDB和Riak支持JavaScript腳本，MongoDB也是如此。Hadoop項目分裂出的幾個腳本編程語言項目（包括Pig和Hive）適用于HBase。Redis項目正在試驗集成Lua腳本語言。

——RESTful接口。只有CouchDB和Riak提供了RESTful接口。

——圖形。Neo4J是一個為維護圖形而專門設(shè)計的數(shù)據(jù)庫。圖形是非常靈活的數(shù)據(jù)結(jié)構(gòu)，圖數(shù)據(jù)庫可以模擬其它任何類型的數(shù)據(jù)庫。

——SQL。我們一直在探討NoSQL運動，但也無法忽略SQL這門熟悉的編程語言。有人正在致力于將SQL移植到Hadoop之上，也許我們未來會采用混合的數(shù)據(jù)庫架構(gòu)。

——科學數(shù)據(jù)。SciDB是一個面向大型科研應(yīng)用的數(shù)據(jù)庫項目，其存儲模型基于多維數(shù)組。SciDB的存儲可以輕松擴展到數(shù)百PB，每晚收集數(shù)十TB的數(shù)據(jù)。

——混合架構(gòu)。 NoSQL運動與數(shù)據(jù)庫架構(gòu)的選擇息息相關(guān)。也許最后的數(shù)據(jù)庫架構(gòu)選擇是混合架構(gòu)，而不是某種單一的數(shù)據(jù)庫技術(shù)。只有選擇混合架構(gòu)，才能博采眾長，與技術(shù)的發(fā)展相適應(yīng)?；旌霞軜?gòu)是在傳統(tǒng)電子商務(wù)站點中融入社會化特性的最佳方式。

寫在最后

NoSQL運動引發(fā)了我們的思考，究竟什么才是我們想要的數(shù)據(jù)庫架構(gòu)解決方案。也許我們最終會明白，沒有放之四海而皆準的真理。（CSDN 張志平/編譯）