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

原文連接：http://radar.oreilly.com/2012/02/nosql-non-relational-database.html