文 / Adam Marcus  譯 / iammutex

何為NoSQL？NoSQL不是一個(gè)工具，而是由一些具有互補(bǔ)性和競爭性的工具組成的一個(gè)概念，是一個(gè)生態(tài)圈。這些被稱為NoSQL的工具，在存儲數(shù)據(jù)的方式上，提供了一種與（基于SQL語言的）關(guān)系型數(shù)據(jù)庫截然不同的思路。要想了解NoSQL，必須先了解現(xiàn)有的這些工具，去理解那些引導(dǎo)它們開拓出新的存儲領(lǐng)域的設(shè)計(jì)思路。

NoSQL其名

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

NoSQL的啟示

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

特性概述

NoSQL系統(tǒng)舍棄了一些SQL標(biāo)準(zhǔn)中的功能，取而代之的是一些簡單靈活的功能。NoSQL的構(gòu)建思想就是盡量簡化數(shù)據(jù)操作，盡量讓操作的執(zhí)行效率可預(yù)估。當(dāng)你去考查一個(gè)NoSQL系統(tǒng)時(shí)，下面的幾點(diǎn)是值得注意的。

• 數(shù)據(jù)模型及操作模型：你的應(yīng)用層數(shù)據(jù)模型是行、對象還是文檔型的呢？這個(gè)系統(tǒng)是否能支持你進(jìn)行一些統(tǒng)計(jì)工作呢？

• 可靠性：當(dāng)你更新數(shù)據(jù)時(shí)，新的數(shù)據(jù)是否立刻寫到持久化存儲中去了？新的數(shù)據(jù)是否同步到多臺機(jī)器上了？

• 擴(kuò)展性：你的數(shù)據(jù)量有多大，單機(jī)是否能容下？你的讀寫量需求單機(jī)是否能支持？

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

• 一致性：你的數(shù)據(jù)是否被復(fù)制到了多臺機(jī)器上？這些不同節(jié)點(diǎn)的數(shù)據(jù)如何保證一致性？

• 事務(wù)機(jī)制：業(yè)務(wù)是否需要ACID事務(wù)機(jī)制？

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

• 負(fù)載可評估：對于一個(gè)讀多寫少的應(yīng)用，諸如響應(yīng)用戶請求的網(wǎng)絡(luò)應(yīng)用，我們總會花很多精力來關(guān)注負(fù)載情況。你可能需要進(jìn)行數(shù)據(jù)規(guī)模的監(jiān)控，對多個(gè)用戶的數(shù)據(jù)進(jìn)行匯總統(tǒng)計(jì)。你的應(yīng)用場景是否需要這樣的功能呢？

NoSQL數(shù)據(jù)模型及操作模型

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

基于Key值存儲的NoSQL數(shù)據(jù)模型

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

• Key-Value存儲

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

• Key-結(jié)構(gòu)化數(shù)據(jù)存儲

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

• Key-文檔存儲

Key-文檔存儲的代表有CouchDB、MongoDB和Riak。這種存儲結(jié)構(gòu)下Key-Value的Value是結(jié)構(gòu)化的文檔，通常這些文檔是被轉(zhuǎn)換成JSON或者類似于JSON的結(jié)構(gòu)進(jìn)行存儲。文檔可以存儲列表，鍵值對以及層次結(jié)構(gòu)復(fù)雜的文檔。

• BigTable的列簇式存儲

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

列式存儲可以這樣理解：將行ID、列簇號，列號以及時(shí)間戳一起，組成一個(gè)Key，然后將Value按Key的順序進(jìn)行存儲。Key值的結(jié)構(gòu)化使這種數(shù)據(jù)結(jié)構(gòu)能夠?qū)崿F(xiàn)一些特別的功能，最常用的就是將一個(gè)數(shù)據(jù)的多個(gè)版本存成時(shí)間戳不同的幾個(gè)值，這樣就能方便地保存歷史數(shù)據(jù)。這種結(jié)構(gòu)也能天然地進(jìn)行高效的松散列數(shù)據(jù)（在很多行中并沒有某列的數(shù)據(jù)）存儲。當(dāng)然，對于那些很少有某一行有NULL值的列，由于每一個(gè)數(shù)據(jù)必須包含列標(biāo)識，這又會造成空間的浪費(fèi)。

圖結(jié)構(gòu)存儲

圖結(jié)構(gòu)存儲是NoSQL的另一種存儲實(shí)現(xiàn)。其指導(dǎo)思想是：數(shù)據(jù)并非對等的，關(guān)系型的存儲或者鍵值對的存儲，可能都不是最好的存儲方式。圖結(jié)構(gòu)是計(jì)算機(jī)科學(xué)的基礎(chǔ)結(jié)構(gòu)之一，Neo4j和HyperGraphDB是當(dāng)前最流行的圖結(jié)構(gòu)數(shù)據(jù)庫。

復(fù)雜查詢

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

事務(wù)機(jī)制

與關(guān)系型數(shù)據(jù)庫不同的是，NoSQL系統(tǒng)通常注重性能和擴(kuò)展性，而非事務(wù)機(jī)制。傳統(tǒng)的SQL數(shù)據(jù)庫的事務(wù)通常都是支持ACID的強(qiáng)事務(wù)機(jī)制。ACID的支持使得應(yīng)用者能夠很清楚他們當(dāng)前的數(shù)據(jù)狀態(tài)。對很多NoSQL系統(tǒng)來說，對性能的考慮遠(yuǎn)在ACID的保證之上。通常NoSQL系統(tǒng)僅提供行級別的原子性保證，也就是說同時(shí)對同一個(gè)Key下的數(shù)據(jù)進(jìn)行的兩個(gè)操作，在實(shí)際執(zhí)行時(shí)是會串行的，保證了每一個(gè)Key-Value對不會被破壞。

Schema-free的存儲

還有一個(gè)很多NoSQL的共同點(diǎn)，就是它通常并沒有強(qiáng)制的數(shù)據(jù)結(jié)構(gòu)約束。即使是在文檔型存儲或者列式存儲上，也不會要求某一個(gè)數(shù)據(jù)列在每一行數(shù)據(jù)上都必須存在。

數(shù)據(jù)可靠性

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

單機(jī)可靠性

單機(jī)可靠性理解起來非常簡單，它的定義是寫操作不會由于機(jī)器重啟或者斷電而丟失。通常單機(jī)可靠性的保證是通過把數(shù)據(jù)寫到磁盤來完成的，而這通常會造成磁盤I/O成為整個(gè)系統(tǒng)的瓶頸。下面我們談?wù)勔恍┰趩螜C(jī)可靠性的保證下提高性能的方法。

• 控制fsync的調(diào)用頻率

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

• 使用日志型的數(shù)據(jù)結(jié)構(gòu)

Cassandra、HBase、Redis和Riak都會把寫操作順序的寫入到一個(gè)日志文件中。相對于存儲系統(tǒng)中的其他數(shù)據(jù)結(jié)構(gòu)，上面說到的日志文件可以頻繁地進(jìn)行fsync操作，這樣就把對磁盤的隨機(jī)寫變成順序?qū)懥恕?/p>

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

Cassandra有一個(gè)機(jī)制，它會把一小段時(shí)間內(nèi)的幾個(gè)并發(fā)的寫操作放在一起進(jìn)行一次fsync調(diào)用，這種做法叫g(shù)roup commit。

多機(jī)可靠性

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

• Redis采用傳統(tǒng)的主從數(shù)據(jù)同步的方式。

• MongoDB提供了一種叫Replica Sets高可用架構(gòu)。

• Riak、Cassandra和Voldemort提供了一些更靈活的可配置策略，并提供一個(gè)可配置的參數(shù)N，代表每一個(gè)數(shù)據(jù)會被備份的份數(shù)。為了應(yīng)對整個(gè)數(shù)據(jù)中心出現(xiàn)故障的情況，需要實(shí)現(xiàn)跨數(shù)據(jù)中心的多機(jī)備份功能。

橫向擴(kuò)展帶來性能提升

橫向擴(kuò)展的目標(biāo)是達(dá)到線性的效果，即如果你增加一倍的機(jī)器，那么負(fù)載能力應(yīng)該也能相應(yīng)的增加一倍。其主要需要解決的問題是如何讓數(shù)據(jù)在多臺機(jī)器間分布，這里面涉及到分片技術(shù)。

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

如非必要，請勿分片

分片會導(dǎo)致系統(tǒng)復(fù)雜程度大增，所以，如果沒有必要，請不要使用分片。普通情況下，我們可以使用讀寫分離和構(gòu)建緩存的方式來緩解我們的數(shù)據(jù)讀壓力。但如果寫操作達(dá)到單點(diǎn)無法承擔(dān)的程度，那我們可能就真的需要進(jìn)行分片了。

通過協(xié)調(diào)器進(jìn)行數(shù)據(jù)分片

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

一致性hash環(huán)算法

一致性hash是一種被廣泛應(yīng)用的技術(shù)，其最早在一個(gè)叫distributed hash tables（DHTs）的系統(tǒng)中進(jìn)行使用。那些類Dynamo的應(yīng)用，比如Cassandra、Voldemort和Riak，基本上都使用了一致性hash環(huán)算法。

如圖1所示，一致性hash環(huán)算法有一個(gè)hash函數(shù)H，所有存儲數(shù)據(jù)的節(jié)點(diǎn)和數(shù)據(jù)本身都可以通過這個(gè)函數(shù)算出一個(gè)hash值，作為自己在下面環(huán)上的位置。然后每個(gè)節(jié)點(diǎn)會負(fù)責(zé)存儲其hash值到下一個(gè)節(jié)點(diǎn)間的所有數(shù)據(jù)的存儲。這樣使得即使節(jié)點(diǎn)數(shù)變化了，大部分?jǐn)?shù)據(jù)并不需要進(jìn)行遷移。

圖1 一致性hash環(huán)算法的hash函數(shù)

連續(xù)范圍分區(qū)

使用連續(xù)范圍分區(qū)的方法進(jìn)行數(shù)據(jù)分片，需要我們保存一份映射關(guān)系表，標(biāo)明哪一段Key值對應(yīng)存在哪臺機(jī)器上。與一致性hash類似，連續(xù)范圍分區(qū)會把Key值按連續(xù)的范圍分段，每段數(shù)據(jù)會被指定保存在某個(gè)節(jié)點(diǎn)上，然后會被冗余備份到其他節(jié)點(diǎn)。

• BigTable的處理方式

Google BigTable論文中描述了一種范圍分區(qū)方式，它將數(shù)據(jù)切分成一個(gè)個(gè)的tablet數(shù)據(jù)塊。每個(gè)tablet保存一定數(shù)量的鍵值對。然后存儲在Tablet 服務(wù)器上。tablet塊的大小會保持在一定范圍，太大的塊會分裂成兩個(gè)，太小的塊又會合并成一個(gè)。BigTable通過一個(gè)叫Chubby的模塊來實(shí)現(xiàn)節(jié)點(diǎn)狀態(tài)檢測。類似的在Hadoop中有一個(gè)叫ZooKeeper的工具實(shí)現(xiàn)此功能。

一致性

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

• 一致性（C）：在分布式系統(tǒng)中的所有數(shù)據(jù)備份，在同一時(shí)刻是否同樣的值。

• 可用性（A）：在集群中一部分節(jié)點(diǎn)故障后，集群整體是否還能響應(yīng)客戶端的讀寫請求。

• 分區(qū)容忍性（P）：集群中的某些節(jié)點(diǎn)在無法聯(lián)系后，集群整體是否還能繼續(xù)進(jìn)行服務(wù)。

而CAP理論就是說在分布式存儲系統(tǒng)中，最多只能實(shí)現(xiàn)上面的兩點(diǎn)。再加之當(dāng)前的網(wǎng)絡(luò)硬件肯定會出現(xiàn)延遲丟包等問題，所以分區(qū)容忍性是我們必須需要實(shí)現(xiàn)的。結(jié)果就是我們只能在一致性和可用性之間進(jìn)行權(quán)衡，沒有NoSQL系統(tǒng)能同時(shí)保證這三點(diǎn)。

對一致性的保證，通常有強(qiáng)一致性和弱一致性的選擇，而在弱一致性里，又以最終一致性的實(shí)現(xiàn)較為普遍。

如果我們采用NRW的設(shè)定，N為數(shù)據(jù)需要備份的份數(shù)，R為讀操作需要讀到的不同節(jié)點(diǎn)上的數(shù)據(jù)份數(shù)，W為寫操作需要成功寫到不同節(jié)點(diǎn)的數(shù)據(jù)份數(shù)，那么當(dāng)R＋W>N時(shí)，既是強(qiáng)一致性的保證，當(dāng)R+W<N時(shí)，就是弱一致性。在弱一致性中，可以通過vector clock多版本控制等方法，來實(shí)現(xiàn)數(shù)據(jù)的最終一致性。

寫在最后的話

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

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