NoSQL運動：資料庫架構抉擇

導讀：Mike Loukides是O'Reilly傳媒的內容戰略副總裁，他對程式設計語言和UNIX系統管理非常感興趣，著作有System Performance Tuning和Unix Power Tools。 本文中，Mike Loukides提出了自己對NoSQL的精闢見解，並對現代資料庫架構的方方面面進行了深入思考。

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

那麼，為什麼說NoSQL是一場運動，而非技術呢？ Justin的說法直截了當：之所以說NoSQL是一場運動，是因為這是對資料庫架構的選擇。 任何一種單一的技術主題，反而會掩蓋NoSQL運動的實質。

自八十年代以來，關聯式資料庫（如SQL Server、Oracle和DB2）一直都是後端業務系統的主導。 這些關聯式資料庫產品都非常優秀，它們之間有許多共通之處。

回顧一下以往15年的軟體發展歷程，我們已經構建了許多優秀的大型資料庫應用，其中不乏Web應用。 但是自關聯式資料庫誕生以來，資料庫領域已經產生了許多變化：

資料激增。 雖然存儲的容量和CPU的速度都在飛速發展，使得資料庫可以應對資料量的激增，但是資料量的確是一個棘手的問題，對於任何重要的資料庫而言，分散式必不可少。 亞秒級的查詢回應。 在八十年代，資料庫查詢以批次處理的方式運行，查詢效率低下。 現在的互聯網，已經從靜態檔發展到由複雜資料庫支撐的網站，而且對於大多數查詢，我們需要亞秒級的回應時間。 7*24小時正常運行。 為靜態HTML檔設置冗余伺服器非常容易，但複雜的資料庫複製就另當別論了。 對高速資料流程的捕捉越來越重要。 許多應用的後臺資料庫吸納資料的速度遠遠快于處理資料查詢的速度。 比如，在日誌應用或者分散式傳感應用資料庫中，寫入比查詢頻繁的多。 ETL（資料擷取、轉換和下載）固然不可或缺，但對高速資料流程的捕捉顯得越來越重要。 非結構化資料。 非結構化資料早就存在，並不是資料世界裡的新景觀，但我們越來越不希望強制資料結構。 犧牲ACID。 ACID（原子性、一致性、隔離性、持久性）雖然很重要，但現代應用帶來的挑戰讓我們意識到，為了實現其它特性（如低延遲和可用性），我們必須做出犧牲。

需求的不斷變化，迫使我們不得不思考全新的資料庫解決方案：

分散式。 龐大的資料庫只是採用分散式的一個原因，另一個原因是現代應用（尤其是Web應用）要求滿足許多線上使用者的暫態回應。 回應時間每超時一秒，都會造成大量使用者流失。 即時計算。 如果你正通過構建線上應用支援業務分析，那麼使用者必然期望即時業務分析。 這不僅便捷，每天執行成百上千的查詢，徹底改觀了我們的工作。 可擴充性。 如果你正在構建一個面向客戶的應用，進行業務分析，那麼可擴充性是一個大問題。 垂直可擴充性已經近乎極限，物理定律的制約使得Intel架構的時鐘頻率在3.5GHz的範圍內徘徊不前，水準可擴充性（構建多節點分散式系統）成了唯一的途徑。 高可用性。 應用系統架構中的任何一部分出現單點故障，都會導致災難性的後果，資料庫系統必須提供高可用性支援。 一個高可用性系統天然就是一個分散式系統。 資料分片。 對於一個給定的分散式資料庫，接下來的問題就是資料分片。 關聯式資料庫在多台主機之間採用手動分片，或者基於資料本身的某些屬性對資料集進行分區。 MongoDB非常容易進行資料分片，HBase、Riak和Cassandra本身就是分散式資料庫。 Schemaless（無模式）。 NoSQL資料庫通常稱為schemaless（無模式），因為它們與關聯式資料庫的架構形態無關。 事實上，NoSQL並非完全無模式。 在像CouchDB或MongoDB這樣的文檔資料庫中，文檔是許多鍵值對（key-value）。 Riak也可以被看做是一個文檔資料庫，但比文件類型更靈活。 Cassandra和HBase被稱為面向列的資料庫。 在大多數應用開發中，NoSQL資料庫前期規劃更少，靈活性更大，更適合敏捷開發。 ACID和CAP。 ACID屬性深入人心，但如果我們仔細思考資料庫的架構，就會發現對一個分散式系統實現一致性和隔離性等ACID屬性非常困難。 ACID屬性非常重要，但自由的選擇需要折中。 CAP定律指出，對於一個分散式運算系統，一致性、可用性和分區容錯性只能同時滿足其中二者。 指令碼語言。 所有的關聯式資料庫都有SQL語言變種（例如，T-SQL和PL/SQL）作為資料指令碼語言。 在非關聯式資料庫的世界裡，也有一些指令碼語言可用。 CouchDB和Riak支援JavaScript腳本，MongoDB也是如此。 Hadoop專案分裂出的幾個腳本程式設計語言專案（包括Pig和Hive）適用于HBase。 Redis專案正在試驗集成Lua指令碼語言。 RESTful介面。 只有CouchDB和Riak提供了RESTful介面。 圖形。 Neo4J是一個為維護圖形而專門設計的資料庫。 圖形是非常靈活的資料結構，圖資料庫可以類比其它任何類型的資料庫。 SQL。 我們一直在探討NoSQL運動，但也無法忽略SQL這門熟悉的程式設計語言。 有人正在致力於將SQL移植到Hadoop之上，也許我們未來會採用混合的資料庫架構。 科學資料。 SciDB是一個面向大型科研應用的資料庫專案，其存儲模型基於多維陣列。 SciDB的存儲可以輕鬆擴展到數百PB，每晚收集數十TB的資料。 混合架構。 NoSQL運動與資料庫架構的選擇息息相關。 也許最後的資料庫架構選擇是混合架構，而不是某種單一的資料庫技術。 只有選擇混合架構，才能博採眾長，與技術的發展相適應。 混合架構是在傳統電子商務網站中融入社會化特性的最佳方式。

寫在最後

NoSQL運動引發了我們的思考，究竟什麼才是我們想要的資料庫架構解決方案。 也許我們最終會明白，沒有放之四海而皆準的真理。 （張志平/編譯）

(責任編輯：蒙遺善)