文 / Adam Marcus  譯 / iammutex

何為NoSQL？NoSQL不是一個工具，而是由一些具有互補性和競爭性的工具組成的一個概念，是一個生態圈。這些被稱為NoSQL的工具，在存儲數據的方式上，提供了一種與（基于SQL語言的）關系型數據庫截然不同的思路。要想了解NoSQL，必須先了解現有的這些工具，去理解那些引導它們開拓出新的存儲領域的設計思路。

NoSQL其名

在給NoSQL下定義之前，我們先來試著從它的名字上做一下解讀。顧名思義，NoSQL系統的數據操作接口應該是非SQL類型的。但在NoSQL社區，NoSQL被賦予了更具有包容性的含義，其意為Not Only SQL，即NoSQL提供了一種與傳統關系型數據庫不同的存儲模式，這為開發者提供了關系型數據庫之外的另一種選擇。

NoSQL的啟示

NoSQL運動受到了很多相關研究論文的啟示，在所有資料中，最核心的有兩個：Google的BigTable論文和Amazon的Dynamo論文。

特性概述

NoSQL系統舍棄了一些SQL標準中的功能，取而代之的是一些簡單靈活的功能。NoSQL的構建思想就是盡量簡化數據操作，盡量讓操作的執行效率可預估。當你去考查一個NoSQL系統時，下面的幾點是值得注意的。

• 數據模型及操作模型：你的應用層數據模型是行、對象還是文檔型的呢？這個系統是否能支持你進行一些統計工作呢？

• 可靠性：當你更新數據時，新的數據是否立刻寫到持久化存儲中去了？新的數據是否同步到多臺機器上了？

• 擴展性：你的數據量有多大，單機是否能容下？你的讀寫量需求單機是否能支持？

• 分區策略：考慮到對擴展性、可用性或者持久性的要求，你是否需要一份數據被存在多臺機器上？你是否需要知道或者說你能否知道數據在哪臺機器上？

• 一致性：你的數據是否被復制到了多臺機器上？這些不同節點的數據如何保證一致性？

• 事務機制：業務是否需要ACID事務機制？

• 單機性能：如果你打算持久化的將數據存在磁盤上，哪種數據結構能滿足你的需求（你的需求是讀多還是寫多）？寫操作是否會成為磁盤瓶頸？

• 負載可評估：對于一個讀多寫少的應用，諸如響應用戶請求的網絡應用，我們總會花很多精力來關注負載情況。你可能需要進行數據規模的監控，對多個用戶的數據進行匯總統計。你的應用場景是否需要這樣的功能呢？

NoSQL數據模型及操作模型

數據庫的數據模型指的是數據在數據庫中的組織方式，數據庫的操作模型指的是存取這些數據的方式。通常數據模型包括關系模型、鍵值模型以及各種圖結構模型。操作語言可能包括SQL、鍵值查詢及MapReduce等。NoSQL通常結合了多種數據模型和操作模型，提供不一樣的架構方式。

基于Key值存儲的NoSQL數據模型

在鍵值型系統中，復雜的聯合查詢以及滿足多個條件的數據查詢操作就不那么容易實現了，需要換一種思維來建立和使用鍵名。比如要獲取部門號為20的所有員工的信息，應用層可以先獲取Key為employee_departments:20的這個列表，然后再循環地拿這個列表中的ID通過獲取employee:ID得到所有員工的信息。

• Key-Value存儲

Key-Value存儲可以說是最簡單的NoSQL存儲，每個Key值對應一個任意的數據值。對NoSQL系統來說，這個任意的數據值是什么，它并不關心。比如在員工信念數據庫里，employee:30這個Key對應的可能就是一段包含員工所有信息的二進制數據。這個二進制的格式可能是Protocol Buffer、Thrift或者Avro都無所謂。

• Key-結構化數據存儲

Key-結構化數據存儲的典型代表是Redis，Redis將Key-Value存儲的Value變成了結構化的數據類型。Value的類型包括數字、字符串、列表、集合以及有序集合。除了set/get/delete操作以為，Redis還提供了很多針對以上數據類型的特殊操作，比如針對數字可以執行增、減操作，對list可以執行push/pop操作，通過提供這種針對單個Value進行的特定類型的操作，Redis可以說實現了功能與性能的平衡。

• Key-文檔存儲

Key-文檔存儲的代表有CouchDB、MongoDB和Riak。這種存儲結構下Key-Value的Value是結構化的文檔，通常這些文檔是被轉換成JSON或者類似于JSON的結構進行存儲。文檔可以存儲列表，鍵值對以及層次結構復雜的文檔。

• BigTable的列簇式存儲

HBase和Cassandra的數據模型都借鑒自Google的BigTable。這種數據模型的特點是列式存儲，每一行數據的各項被存儲在不同的列中（這些列的集合稱作列簇）。而每一列中每一個數據都包含一個時間戳屬性，這樣列中的同一個數據項的多個版本都能保存下來。

列式存儲可以這樣理解：將行ID、列簇號，列號以及時間戳一起，組成一個Key，然后將Value按Key的順序進行存儲。Key值的結構化使這種數據結構能夠實現一些特別的功能，最常用的就是將一個數據的多個版本存成時間戳不同的幾個值，這樣就能方便地保存歷史數據。這種結構也能天然地進行高效的松散列數據（在很多行中并沒有某列的數據）存儲。當然，對于那些很少有某一行有NULL值的列，由于每一個數據必須包含列標識，這又會造成空間的浪費。

圖結構存儲

圖結構存儲是NoSQL的另一種存儲實現。其指導思想是：數據并非對等的，關系型的存儲或者鍵值對的存儲，可能都不是最好的存儲方式。圖結構是計算機科學的基礎結構之一，Neo4j和HyperGraphDB是當前最流行的圖結構數據庫。

復雜查詢

在NoSQL存儲系統中，有很多比鍵值查找更復雜的操作。比如MongoDB可以在任意數據行上建立索引，可以使用Javascript語法設定復雜的查詢條件。BigTable型的系統通常支持對單獨某一行的數據進行遍歷，允許對單列的數據進行按特定條件的篩選。CouchDB允許你創建同一份數據的多個視圖，通過運行MapReduce任務來實現一些更為復雜的查詢或者更新操作。很多NoSQL系統都支持與Hadoop或者其他MapReduce框架結合來進行一些大規模數據分析工作。

事務機制

與關系型數據庫不同的是，NoSQL系統通常注重性能和擴展性，而非事務機制。傳統的SQL數據庫的事務通常都是支持ACID的強事務機制。ACID的支持使得應用者能夠很清楚他們當前的數據狀態。對很多NoSQL系統來說，對性能的考慮遠在ACID的保證之上。通常NoSQL系統僅提供行級別的原子性保證，也就是說同時對同一個Key下的數據進行的兩個操作，在實際執行時是會串行的，保證了每一個Key-Value對不會被破壞。

Schema-free的存儲

還有一個很多NoSQL的共同點，就是它通常并沒有強制的數據結構約束。即使是在文檔型存儲或者列式存儲上，也不會要求某一個數據列在每一行數據上都必須存在。

數據可靠性

最理想的狀態是，數據庫會把所有寫操作立刻寫到持久化存儲的設備，同時復制多個副本到不同地理位置的不同節點上，以防止數據丟失。但這種對數據安全性的要求對性能是有影響的，所以不同的NoSQL系統在自身性能的考慮下，在數據安全上采取了不太一樣的策略。

單機可靠性

單機可靠性理解起來非常簡單，它的定義是寫操作不會由于機器重啟或者斷電而丟失。通常單機可靠性的保證是通過把數據寫到磁盤來完成的，而這通常會造成磁盤I/O成為整個系統的瓶頸。下面我們談談一些在單機可靠性的保證下提高性能的方法。

• 控制fsync的調用頻率

Redis提供了幾種對fsync調用頻率的控制方法。應用開發者可以配置Redis在每次更新操作后都執行一次fsync，這樣會比較安全，當然也就比較慢。Redis也可以設置成N秒種調用一次fsync，這樣性能會更好一點。但這樣的后果就是一旦出現故障，最多可能導致N秒內的數據丟失。而對一些可靠性要求不太高的場合（比如僅僅把Redis當Cache用的時候），應用開發者甚至可以直接關掉fsync的調用：讓操作系統來決定什么時候需要把數據flush到磁盤（譯者注：這只是Redis append only file的機制，Redis是可以關閉aof日志的，另外，Redis本身支持將內存中數據dump成rdb文件的機制，和上面說的不是一回事）。

• 使用日志型的數據結構

Cassandra、HBase、Redis和Riak都會把寫操作順序的寫入到一個日志文件中。相對于存儲系統中的其他數據結構，上面說到的日志文件可以頻繁地進行fsync操作，這樣就把對磁盤的隨機寫變成順序寫了。

• 通過合并寫操作提高吞吐性能

Cassandra有一個機制，它會把一小段時間內的幾個并發的寫操作放在一起進行一次fsync調用，這種做法叫group commit。

多機可靠性

由于硬件層面有時會造成無法恢復的損壞，單機可靠性的保證在這時就鞭長莫及了。對于一些重要數據，跨機器做備份保存是必備的安全措施。一些NoSQL系統提供了多機可靠性的支持。

• Redis采用傳統的主從數據同步的方式。

• MongoDB提供了一種叫Replica Sets高可用架構。

• Riak、Cassandra和Voldemort提供了一些更靈活的可配置策略，并提供一個可配置的參數N，代表每一個數據會被備份的份數。為了應對整個數據中心出現故障的情況，需要實現跨數據中心的多機備份功能。

橫向擴展帶來性能提升

橫向擴展的目標是達到線性的效果，即如果你增加一倍的機器，那么負載能力應該也能相應的增加一倍。其主要需要解決的問題是如何讓數據在多臺機器間分布，這里面涉及到分片技術。

分片的意思，就是沒有任何一臺機器可以處理所有寫請求，也沒有任何一臺機器可以處理對所有數據的讀請求。下面我們將會對hash分片和范圍分片兩種分片方式進行描述。

如非必要，請勿分片

分片會導致系統復雜程度大增，所以，如果沒有必要，請不要使用分片。普通情況下，我們可以使用讀寫分離和構建緩存的方式來緩解我們的數據讀壓力。但如果寫操作達到單點無法承擔的程度，那我們可能就真的需要進行分片了。

通過協調器進行數據分片

一種分片策略是通過引入一個中間代理層來實現，該代理層記錄數據在各個節點的分布狀況，所有讀寫請求都通過代理層來做路由。比如與CouchDB的兩個項目：Lounge和BigCouch。類似的，Twitter自己也實現了一個叫Gizzard的協調器，可以實現數據分片和備份功能。

一致性hash環算法

一致性hash是一種被廣泛應用的技術，其最早在一個叫distributed hash tables（DHTs）的系統中進行使用。那些類Dynamo的應用，比如Cassandra、Voldemort和Riak，基本上都使用了一致性hash環算法。

如圖1所示，一致性hash環算法有一個hash函數H，所有存儲數據的節點和數據本身都可以通過這個函數算出一個hash值，作為自己在下面環上的位置。然后每個節點會負責存儲其hash值到下一個節點間的所有數據的存儲。這樣使得即使節點數變化了，大部分數據并不需要進行遷移。

圖1 一致性hash環算法的hash函數

連續范圍分區

使用連續范圍分區的方法進行數據分片，需要我們保存一份映射關系表，標明哪一段Key值對應存在哪臺機器上。與一致性hash類似，連續范圍分區會把Key值按連續的范圍分段，每段數據會被指定保存在某個節點上，然后會被冗余備份到其他節點。

• BigTable的處理方式

Google BigTable論文中描述了一種范圍分區方式，它將數據切分成一個個的tablet數據塊。每個tablet保存一定數量的鍵值對。然后存儲在Tablet 服務器上。tablet塊的大小會保持在一定范圍，太大的塊會分裂成兩個，太小的塊又會合并成一個。BigTable通過一個叫Chubby的模塊來實現節點狀態檢測。類似的在Hadoop中有一個叫ZooKeeper的工具實現此功能。

一致性

上面講到了通過將數據冗余存儲到不同的節點來保證數據安全和減輕負載，下面我們來看看這樣做引發的一個問題：保證數據在多個節點間的一致性是非常困難的。在多個點間保持數據的一致性的問題，也就是本章的主題。下面我們首先來看一下在著名的CAP理論。

• 一致性（C）：在分布式系統中的所有數據備份，在同一時刻是否同樣的值。

• 可用性（A）：在集群中一部分節點故障后，集群整體是否還能響應客戶端的讀寫請求。

• 分區容忍性（P）：集群中的某些節點在無法聯系后，集群整體是否還能繼續進行服務。

而CAP理論就是說在分布式存儲系統中，最多只能實現上面的兩點。再加之當前的網絡硬件肯定會出現延遲丟包等問題，所以分區容忍性是我們必須需要實現的。結果就是我們只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證這三點。

對一致性的保證，通常有強一致性和弱一致性的選擇，而在弱一致性里，又以最終一致性的實現較為普遍。

如果我們采用NRW的設定，N為數據需要備份的份數，R為讀操作需要讀到的不同節點上的數據份數，W為寫操作需要成功寫到不同節點的數據份數，那么當R＋W>N時，既是強一致性的保證，當R+W<N時，就是弱一致性。在弱一致性中，可以通過vector clock多版本控制等方法，來實現數據的最終一致性。

寫在最后的話

目前NoSQL系統來處在它的萌芽期，我們上面討論到的很多NoSQL系統，它們的架構、設計和接口可能都會改變。本章的目的，不在于讓你了解這些NoSQL系統目前是如何工作的，而在于讓你理解這些系統之所以這樣實現的原因。NoSQL系統把更多的設計工作留給了應用開發工作者來做。理解上面這些組件的架構，不僅能讓你寫出下一個NoSQL系統，更讓你對現有系統應用得更好。

（編者注：本文根據NoSQLFan網站原載同名文章http://blog.nosqlfan.com/html/2171.html整理而成，英文原文鏈接為http://www.aosabook.org/en/nosql.html）