導讀：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運動引發了我們的思考，究竟什麼纔是我們想要的數據庫架構解決方案。也許我們最終會明白，沒有放之四海而皆準的真理。（張志平/編譯）
原文鏈接：The NoSQL movement
