NoSQL理論體系及應(yīng)用

李馮筱，羅高松

（廣州優(yōu)億信息科技有限公司 廣州 510630）

1 引言

關(guān)系型數(shù)據(jù)管理系統(tǒng)（relationship database management system，RDBMS）在網(wǎng)絡(luò)和商務(wù)應(yīng)用中，對于存儲結(jié)構(gòu)化數(shù)據(jù)，目前仍然占有主導(dǎo)性地位。然而最近幾年，越來越多的學(xué)者和大型網(wǎng)絡(luò)公司開始質(zhì)疑關(guān)系型數(shù)據(jù)庫“以一適用所有”的想法。大數(shù)據(jù)時代的來臨，使得傳統(tǒng)RDBMS的瓶頸成為發(fā)展道路上的阻礙，于是新型數(shù)據(jù)庫改革運(yùn)動掀起了一股熱浪，開發(fā)者們引用NoSQL作為運(yùn)動的名稱。NoSQL是一種概念，根據(jù)應(yīng)用的不同，理解上也有所不同，有些人認(rèn)為應(yīng)該是not only SQL，也有些人認(rèn)為是non-relational database，也有說法是non-SQL。無論說法上有什么區(qū)別，其描述的是越來越多的網(wǎng)絡(luò)開發(fā)商（以下簡稱“網(wǎng)商”）打破傳統(tǒng)局限，應(yīng)用非關(guān)系型數(shù)據(jù)庫方法進(jìn)行革新的趨勢。

2 NoSQL基礎(chǔ)理論

NoSQL作為新興數(shù)據(jù)庫系統(tǒng)概念，由于其具有處理海量數(shù)據(jù)的能力，近年來受到各大IT公司的追捧。Facebook、Google等大型網(wǎng)商紛紛斥資進(jìn)行相關(guān)研究。雖然相對成熟的RDBMS仍存在不少功能問題，但在這個數(shù)據(jù)爆炸的時代，由于數(shù)據(jù)處理需求的不斷提升，預(yù)計(jì)這種發(fā)展熱潮仍將持續(xù)下去，并且普遍化。談及NoSQL數(shù)據(jù)庫概念，首先應(yīng)該了解支持NoSQL概念的理論三大基石：CAP理論、BASE思想和最終一致性。理解這三大理論，對于了解NoSQL的本源有著極其重要的作用。本文將對三大基石的理論基礎(chǔ)和其之間的關(guān)系進(jìn)行著重介紹。

2.1 CAP理論

Eric Brewer在發(fā)表于ACM的PODC中名為 “關(guān)于Robust分散式系統(tǒng)”的文章中首次提及CAP理論。此理論目前被大型公司廣泛采納，如Amazon和其他NoSQL擁護(hù)者。CAP 解釋為一致性（consistency）、性能（availability）以及分區(qū)容忍性（partition tolerance）。具體描述如下。

一致性：一個數(shù)據(jù)系統(tǒng)如何處理讀寫操作的一致性問題。分布式系統(tǒng)對于一致性的要求為當(dāng)更新寫入操作完成時，其余讀取操作需要及時看到數(shù)據(jù)的更新。當(dāng)然有些系統(tǒng)對于一致性有更嚴(yán)格定義上的要求。

可用性：一個系統(tǒng)能夠持續(xù)不間斷使用的問題。嚴(yán)格定義上的高性能可用性意味著一個系統(tǒng)從設(shè)計(jì)到實(shí)施都應(yīng)該能夠提供可持續(xù)的操作（如讀寫操作），無論是操作沖突，還是軟硬件部分因?yàn)樯壎鴮?dǎo)致失效。

分區(qū)容忍性：可以被理解為系統(tǒng)在提供持續(xù)性操作時分區(qū)處理的能力。一旦開始將數(shù)據(jù)和邏輯分布在不同的節(jié)點(diǎn)上，就有形成分區(qū)的風(fēng)險。假定網(wǎng)線被切斷，就形成分區(qū)，在不同分區(qū)的節(jié)點(diǎn)A和節(jié)點(diǎn)B無法通信。由于Web提供的這種分布式能力，臨時的分區(qū)是一個常見的情況，處理這種情況就屬于分區(qū)容忍性。一些人認(rèn)為分區(qū)容忍性也可以理解為一個系統(tǒng)靈活處理節(jié)點(diǎn)的增加和去除的能力。例如，處于維護(hù)目的時，去除然后再添加節(jié)點(diǎn)的行為可認(rèn)為是一種分區(qū)容忍性的表現(xiàn)。

現(xiàn)在Brewer提出，在數(shù)據(jù)共享系統(tǒng)中這3種特性是無法同時實(shí)現(xiàn)的，最多只能選擇其中兩種執(zhí)行，這個理論已經(jīng)得到了大量的驗(yàn)證。很簡單的例子，如復(fù)制必須能在多節(jié)點(diǎn)上進(jìn)行，從而提升可用性，那么數(shù)據(jù)副本（replica）之間就面臨調(diào)試。但為了在網(wǎng)絡(luò)分區(qū)的情況下也能夠正常工作，復(fù)制或數(shù)據(jù)間的調(diào)試就很難執(zhí)行。所以CAP僅能得以部分保證。

Brewer指出了基于CAP理論的3種應(yīng)用，選擇其中的一些例子，見表1。

對于數(shù)據(jù)庫，Brewer總結(jié)道，由于一致性和可用性無法兼得，大多數(shù)NoSQL擁護(hù)者都選擇了一致性高于可用性的設(shè)計(jì)模式，除了NoSQL，這些理論也影響到了部分關(guān)系型數(shù)據(jù)庫。表2總結(jié)了一些現(xiàn)存常用產(chǎn)品的設(shè)計(jì)架構(gòu)的CAP取舍以及其對應(yīng)的功能分類。

2.2 BASE思想

互聯(lián)網(wǎng)中，類似于wikis、blogs和社交網(wǎng)站等，創(chuàng)造了大量的數(shù)據(jù)等待被處理、分析和傳輸。公司、組織和個人提供大量的相關(guān)應(yīng)用和服務(wù)致力于滿足性能、可信度、可用性、持久性需求。正如上面所討論的那樣，CAP理論指出，對于一致性、可用性和分區(qū)容忍性，必須要做出一個選擇。越來越多的應(yīng)用和使用案例，包括網(wǎng)絡(luò)應(yīng)用，特別是對于一些大型和超大型的案例，甚至于一些電子商務(wù)的范疇中，可用性和分區(qū)容忍性被認(rèn)為比一致性更需要嚴(yán)格設(shè)計(jì)。這些應(yīng)用設(shè)計(jì)更多傾向于降低一致性，而強(qiáng)調(diào)可用性和數(shù)據(jù)冗余機(jī)制（即有序地將數(shù)據(jù)分散于不同節(jié)點(diǎn)中）。這是因?yàn)榇蠖鄶?shù)系統(tǒng)都在普通的機(jī)器上，而非高級的專用機(jī)器，此類模式能夠幫助應(yīng)對相關(guān)問題，并且更具有擴(kuò)展性。傳統(tǒng)ACID模式對于數(shù)據(jù)的屬性要求非常高，在分布式系統(tǒng)中比較難以達(dá)到。所以在CAP理論的基礎(chǔ)上，提出了BASE思想，對一致性進(jìn)行概化處理。

表1 CAP理論應(yīng)用特點(diǎn)及例子

表2 CAP理論數(shù)據(jù)庫應(yīng)用實(shí)例及功能分類

要解釋BASE思想，首先要對ACID有一個了解，因?yàn)锽ASE是相對于DBMS中的ACID所提出來的新思想。ACID指的是傳統(tǒng)數(shù)據(jù)庫對于數(shù)據(jù)特性的要求，詳細(xì)介紹如下。

·原子性（A）：即事務(wù)執(zhí)行作為原子，不可再分離，整個語句要么執(zhí)行，要么不執(zhí)行，不可能停在中間某個環(huán)節(jié)。

·一致性（C）：在事務(wù)開始之前和事務(wù)結(jié)束之后，數(shù)據(jù)庫的完整性約束沒有被破壞。

·隔離性（I）:兩個事務(wù)的執(zhí)行互不干擾，一個事務(wù)不可能看到其他事務(wù)運(yùn)行時中間某一時刻的數(shù)據(jù)。兩個事務(wù)不會發(fā)生交互。

·持久性（D）:在事務(wù)完成以后，該事務(wù)對數(shù)據(jù)庫所做的更改便持久地保存在數(shù)據(jù)庫之中，并不會被回滾。

在數(shù)據(jù)庫系統(tǒng)中，事務(wù)的ACID屬性保證了數(shù)據(jù)庫的一致性，如銀行系統(tǒng)中，付款就是一個事務(wù)，從原賬戶扣除金額以及向目標(biāo)賬戶添加金額，這兩個數(shù)據(jù)庫操作的總和構(gòu)成一個完整的邏輯過程，不可拆分，為原子，從而保證了整個系統(tǒng)中的總金額沒有變化。

然而，這些ACID特性對于大型的分布式系統(tǒng)來說，與高性能是不兼容的。比如，在網(wǎng)店買東西，任何一個人買東西的過程都會鎖住數(shù)據(jù)庫直到買東西徹底完成，買完時，每一個人都可以看到庫存減少了。也就是說，不允許存在兩個人同時買的情況。很明顯對于大多數(shù)網(wǎng)上商城，尤其是大型網(wǎng)商來說，這個方法并不適用。

BASE思想實(shí)際上是CAP理論中AP的衍伸。它通過犧牲高一致性，保證高可用性和分區(qū)容忍性。它同時也是ACID的一個變種。BASE在英文中有基本的意思，也可以說實(shí)際上強(qiáng)調(diào)的就是能保證連續(xù) “基本”可用的一種模型。BASE思想的組成有以下3個部分：基本可用、軟狀態(tài)、最終一致性。

BASE模式指的是一個應(yīng)用在任意時間首先應(yīng)該能完成最基本化的工作（即基本可用），并不需要總是一致（即軟狀態(tài)），但最終應(yīng)該是一致（即最終一致性）的。ACID和BASE應(yīng)該被看作同一范疇內(nèi)的互相補(bǔ)充品，而不是替代品。其優(yōu)缺點(diǎn)對比見表3。

表3 BASE與ACID的優(yōu)缺點(diǎn)對比

2.3 最終一致性

有兩種方式看待一致性。一種是從開發(fā)者/客戶端的角度，如何觀察數(shù)據(jù)更新；另一種是從服務(wù)器端，更新如何在系統(tǒng)中流動以及對于更新系統(tǒng)能提供什么樣的保證?？蛻舳擞^察到的一致性指的是，何時以及如何能觀察到對存儲系統(tǒng)中的數(shù)據(jù)對象所做的更新。

對于一致性的解釋，根據(jù)強(qiáng)度的不同，分為強(qiáng)一致性和弱一致性兩種。

強(qiáng)一致性，即所有的讀取操作都必須返回最新的寫入操作的數(shù)據(jù)，而忽略復(fù)寫操作的路徑。這樣的需求要求對于數(shù)據(jù)的操作（寫入和讀?。┒急仨氃谕还?jié)點(diǎn)上，否則強(qiáng)一致性將受到分布式事務(wù)傳輸協(xié)議的影響 （如2PC和Paxos）。因此，根據(jù)CAP理論，強(qiáng)一致性無法和可用性、分區(qū)容忍性同時實(shí)現(xiàn)。

弱一致性，即讀取操作時能夠見到寫入操作，但僅限一定程度上的最新寫入操作后的數(shù)據(jù)。那么，客戶端在流程中會出現(xiàn)非一致性的數(shù)據(jù)。解決方法有很多，例如，在一個多數(shù)據(jù)副本的數(shù)據(jù)庫中，更新操作會集中于一個節(jié)點(diǎn)，那么這個節(jié)點(diǎn)上的數(shù)據(jù)就能保持一定是最新的版本。

最終一致性屬于弱一致性的一種，即存儲系統(tǒng)保證如果沒有新的更新提交，最終所有的訪問都將獲得最后的更新。如果沒有故障發(fā)生，不一致性取決于通信時延、系統(tǒng)負(fù)載以及復(fù)制策略中涉及的副本數(shù)。實(shí)現(xiàn)最終一致性最常見的系統(tǒng)是DNS。根據(jù)name更新的傳播、配置模式以及時間控制的緩存，最終所有節(jié)點(diǎn)都會看到更新。

弱一致性的系統(tǒng)能夠同時提供更多元化和針對性的操作方案。

·Read Your Own Writes （RYOW）Consistency方案指的是一個客戶端能夠及時看到本方的實(shí)時數(shù)據(jù)更新，但其他方則不需要立即看到這類更新。

·Session Consistency指的是在一定范圍內(nèi)（通常為同一服務(wù)器內(nèi)），客戶端能看到同范圍內(nèi)的實(shí)時更新。

·Casual Consistency指的是一個客戶端讀取了X版本的數(shù)據(jù)，然后寫入了版本Y，那么每個讀取Y版本的客戶端也能看到X版本。

·Monotonic Read Consistency提供時間單一性，保證每個客戶端在之后的請求中獲取到的是最新版本。

當(dāng)同一片區(qū)的數(shù)據(jù)的不同更新同時發(fā)生，客戶端并不需要依靠于讀取數(shù)據(jù)的即時更新時，弱一致性是一個很好的選擇。有關(guān)一致性模型的選擇，需要考慮客戶端如何請求數(shù)據(jù)和處理副本更新的方式。以下舉例進(jìn)行說明。

在GFS中，多客戶端可以持續(xù)地修改或執(zhí)行追加記錄的操作。盡管不同時的寫入操作有可能在多副本中顯示同樣的值，但實(shí)際上每一個客戶端的寫入操作是不明確的。追加記錄操作在每一個副本中的文檔區(qū)域內(nèi)都能出現(xiàn)至少一次來保證原子性，以此來體現(xiàn)一致性。

Dynamo則用一種叫sloppy quorum的方法，通過請求一個總能寫入的服務(wù)來保證顯示和讀取的一致性。Quorum協(xié)議判斷的是系統(tǒng)用于讀取、寫入和每個操作在復(fù)制進(jìn)程中所囊括的系統(tǒng)數(shù)量N，以此來防止由于網(wǎng)絡(luò)分區(qū)造成的信息不一致。處理系統(tǒng)臨時崩潰時，Dynamo允許其他并沒有包含進(jìn)程的系統(tǒng)用Hinted-handoff方法 （也就是sloppy quorum）執(zhí)行一個主要query。它允許每一個系統(tǒng)都能處理可能在復(fù)制過程中發(fā)生數(shù)據(jù)不一致的數(shù)據(jù)版本，并且使用向量時間技術(shù)來判斷參與進(jìn)程的系統(tǒng)中數(shù)據(jù)修改的因果關(guān)系，一次保證每一個系統(tǒng)都能自動識別新的數(shù)據(jù)，并且當(dāng)客戶端能夠決定時，通過傳達(dá)版本號來決定數(shù)據(jù)的顯示。

在Cassandra中，一致性的程度是可以調(diào)控的。用戶可以決定在N個復(fù)制關(guān)系中有多少讀寫操作必須成功。在讀?。?、任意、1仲裁和全部）時和在寫入（1仲裁和全部）時，它都提供明確的方法。它與Dynamo相似，也通過時間戳順序進(jìn)行讀取修復(fù)，從而提供讀取的一致性。

2.4 三大基石的意義

三大基石是墊定NoSQL理論的基礎(chǔ)。它在傳統(tǒng)RDBMS的理論架構(gòu)上，針對分布式數(shù)據(jù)存儲理論進(jìn)行了理論上的革新。CAP理論指出了傳統(tǒng)數(shù)據(jù)庫要求在分布式系統(tǒng)中是很難實(shí)現(xiàn)的，在基礎(chǔ)架構(gòu)中，必須要考慮到產(chǎn)品方向?qū)σ恢滦?、可用性、分區(qū)容忍性的要求，從而進(jìn)行合理的取舍。根據(jù)CAP理論，提出了傳統(tǒng)ACID屬性的變形體BASE思想。BASE思想弱化了傳統(tǒng)ACID思想對事務(wù)屬性的嚴(yán)格要求，提出了保證高可用性的基本工作、軟狀態(tài)和最終一致性想法。實(shí)際上就是根據(jù)CAP理論，在一定程度上放寬對一致性的要求，從而保證可用性和分區(qū)容忍性。最終一致性對傳統(tǒng)一致性進(jìn)行了再定義，并衍生出了很多新的處理方法。首先數(shù)據(jù)的一致性是必須要考慮的，放松不等于放任不管。最終一致性是一種考慮用戶體驗(yàn)的折中辦法，也是與傳統(tǒng)RDBMS最大的不同之一。

三大基石互相補(bǔ)充，互相以各自為基礎(chǔ)進(jìn)行衍伸，形成了一個標(biāo)準(zhǔn)的理論體系。然而，由于開發(fā)應(yīng)用尚未進(jìn)入完全成熟的階段，因此這個理論細(xì)節(jié)也在不斷的變革中。與傳統(tǒng)RDBMS“以一適用全部”的思想相比，NoSQL的理論體系發(fā)展更強(qiáng)調(diào)個體適應(yīng)性。針對具體產(chǎn)品，需要有嚴(yán)格的考核思量過程，明確需要什么、可以放寬什么，進(jìn)而進(jìn)行合理設(shè)計(jì)。

3 NoSQL產(chǎn)品分類

目前NoSQL概念下的數(shù)據(jù)庫應(yīng)用非常多，根據(jù)數(shù)據(jù)模型、功能應(yīng)用、分布方式、復(fù)制方式等分類各有不同。從另一方面來說，也反映了NoSQL理論體系的高擴(kuò)展性和可能性。對現(xiàn)在NoSQL理論下的數(shù)據(jù)庫進(jìn)行分類，見表4。

4 NoSQL與RDBMS對比

眾所周知，NoSQL的應(yīng)用研究熱潮是緊隨著大數(shù)據(jù)時代來臨掀起的。相對于傳統(tǒng)RDBMS，NoSQL的發(fā)展并未成熟。那么為什么要選擇NoSQL呢？是什么讓各大公司紛紛從RDBMS轉(zhuǎn)型做NoSQL呢？NoSQL和RDBMS之間究竟是什么關(guān)系呢？本節(jié)將從這些方面對NoSQL和RDBMS進(jìn)行比較詳盡的對比分析。

表4 NoSQL產(chǎn)品分類

4.1 傳統(tǒng)RDBMS瓶頸

從時代背景來看，將來一定是大數(shù)據(jù)時代。所謂大數(shù)據(jù)，“大”在3個方面：數(shù)據(jù)量、分析量和數(shù)據(jù)種類（非結(jié)構(gòu)化數(shù)據(jù)）。T級數(shù)據(jù)量向P級數(shù)據(jù)量轉(zhuǎn)變時，傳統(tǒng)RDBMS性能瓶頸頻繁出現(xiàn)。單機(jī)處理已經(jīng)很難勝任數(shù)據(jù)處理工作。之前人們致力于縱向擴(kuò)展（scale-up）來解決數(shù)據(jù)量持續(xù)擴(kuò)大的問題。但是事實(shí)證明無法有效解決問題，于是出現(xiàn)了通過向外擴(kuò)展（scale-out）的方式進(jìn)行針對性解決。

向外擴(kuò)展對于RDBMS來說一直是一個難題，原因主要有以下幾個方面。

（1）數(shù)據(jù)與事務(wù)要求過高，很難達(dá)成

假設(shè)RDBMS的表格被分散到幾臺電腦上，每一部分的數(shù)據(jù)在存儲之前都進(jìn)行了復(fù)制備份來保證高可用性。首先，執(zhí)行分散性事務(wù)的同時還保證ACID特征，對于向外擴(kuò)展來說是非常困難的。

·要保證原子性，那么2PC這樣的協(xié)議就必須在與特定事務(wù)相關(guān)的全部系統(tǒng)中都用。

·要保證獨(dú)立性，那么數(shù)據(jù)就必須基本上鎖住。鎖的單位可以是一個記錄、一個表格或者一個字符。

所以要在分散式環(huán)境中保證原子性的獨(dú)立性，當(dāng)分布式事務(wù)協(xié)議被處理時，所有的相關(guān)系統(tǒng)都要被鎖??；系統(tǒng)的服務(wù)越多，鎖的任務(wù)越繁重。這就是向外擴(kuò)展結(jié)構(gòu)很難的原因。

（2）復(fù)制和分散數(shù)據(jù)是RDBMS向外擴(kuò)展結(jié)構(gòu)的另一個限制

·用2PC方法進(jìn)行事務(wù)性的復(fù)制存在一個問題，就是當(dāng)一個相關(guān)系統(tǒng)的復(fù)制操作失敗時，事務(wù)本身也會失效并且變得不可用。

·WAL日志方法能夠優(yōu)化事務(wù)DBMS的事務(wù)提交過程。如果將系統(tǒng)中的復(fù)制進(jìn)程看作主，變化應(yīng)用進(jìn)程是從，那么系統(tǒng)就是主從式或者多主式的。當(dāng)用多主式時，就很難解決多個主進(jìn)程同時寫進(jìn)程或阻止進(jìn)程的沖突問題。

·數(shù)據(jù)本身存儲結(jié)構(gòu)為關(guān)系型，數(shù)據(jù)庫本身的擴(kuò)展限制很多，技術(shù)很麻煩。

（3）并行數(shù)據(jù)庫

對于這些問題，RDBMS擁護(hù)者也做了很多研究，其中并行數(shù)據(jù)庫處理就是一個很典型的例子，也取得了不少成功。

并行數(shù)據(jù)庫起源于20世紀(jì)80年代，現(xiàn)在有很多比較成熟的版本，如Vertica、Greenplum等。這些數(shù)據(jù)庫都支持標(biāo)準(zhǔn)SQL，在過去30年間實(shí)現(xiàn)了很多重要突破。其主要采用shared-nothing結(jié)構(gòu)，將關(guān)系表在節(jié)點(diǎn)間橫向劃分，并且利用優(yōu)化器對執(zhí)行過程進(jìn)行調(diào)度和管理。與NoSQL理論相似，其目標(biāo)是高性能和高可用性。并行數(shù)據(jù)庫的最大優(yōu)勢在于性能和其他功能支持，這主要得益于數(shù)據(jù)庫近幾十年的研究成果、許多先進(jìn)的技術(shù)手段及算法，如索引、數(shù)據(jù)壓縮、物化視圖、結(jié)果緩沖、I/O共享、優(yōu)化的數(shù)據(jù)連接等。但在大數(shù)據(jù)時代，數(shù)據(jù)移動的實(shí)現(xiàn)方式將影響其性能。

并行數(shù)據(jù)庫通過SQL向外提供數(shù)據(jù)訪問服務(wù)，SQL因其語言特性而被廣泛使用。經(jīng)過長時間的積累，市面上的大多數(shù)BI工具都支持SQL語言，數(shù)據(jù)庫本身能兼容很多BI工具。不僅如此，某些數(shù)據(jù)庫，如IBM DB2，還針對一些BI工具進(jìn)行了優(yōu)化。然而大數(shù)據(jù)卻給SQL接口帶來了巨大挑戰(zhàn)。SQL的優(yōu)勢源于其對底層數(shù)據(jù)訪問的封裝，但封裝卻在一定程度上影響了其開放性。而且并行數(shù)據(jù)庫提供的用戶自定義函數(shù)大都基于單數(shù)據(jù)庫實(shí)例設(shè)計(jì)，不能在機(jī)群上并行執(zhí)行，也即意味著傳統(tǒng)的實(shí)現(xiàn)方式不適合大數(shù)據(jù)的處理及分析。而且在并行數(shù)據(jù)庫中實(shí)現(xiàn)用戶自定義函數(shù)往往需要經(jīng)過復(fù)雜的系統(tǒng)交互，甚至要熟悉數(shù)據(jù)庫的內(nèi)部結(jié)構(gòu)及系統(tǒng)調(diào)用等，從而難以使用。并行數(shù)據(jù)庫在擴(kuò)展性、容錯性、成本、對異構(gòu)環(huán)境的支持等幾項(xiàng)上有所欠缺，這幾項(xiàng)實(shí)際上是相互影響的，如并行數(shù)據(jù)庫大多支持有限擴(kuò)展，一般可擴(kuò)至數(shù)百節(jié)點(diǎn)的規(guī)模，尚沒有數(shù)千節(jié)點(diǎn)規(guī)模的應(yīng)用案例。

并行數(shù)據(jù)庫擴(kuò)展性的有限主要因?yàn)槿缦聝牲c(diǎn)。

·并行數(shù)據(jù)庫軟件級容錯能力較差，并行數(shù)據(jù)庫基于高端硬件設(shè)計(jì)，并且假設(shè)查詢失敗屬于稀有事件，因此當(dāng)查詢失敗時，一般采取重做查詢的方式；而在大規(guī)模機(jī)群環(huán)境下，查詢失敗將會變?yōu)橐粋€普通事件，極端情況下，并行數(shù)據(jù)有可能出現(xiàn)不停重做查詢的局面。

·并行數(shù)據(jù)庫對異構(gòu)硬件的支持非常有限，且對于處理較慢的節(jié)點(diǎn)反應(yīng)敏感，容易出現(xiàn)“木桶效應(yīng)”。所以RDBMS的功能雖然非常強(qiáng)大，但針對個別化問題的解決方案卻很難進(jìn)行擴(kuò)展，于是出現(xiàn)了NoSQL來解決問題。

4.2 NoSQL優(yōu)勢

NoSQL的優(yōu)勢是基于其理論體系的革新理念，首先從思想上解放對數(shù)據(jù)的定義問題。得益于此，NoSQL提供一個非關(guān)系型的數(shù)據(jù)庫系統(tǒng)，就長遠(yuǎn)發(fā)展來說，非表格化的模型允許系統(tǒng)的平行擴(kuò)展。比起RDBMS，它沒有那么結(jié)構(gòu)化并且不保證ACID性，由于ACID被放棄，靈活性、擴(kuò)展性和數(shù)據(jù)存儲應(yīng)用性都得到提升。所以它對于爆炸性數(shù)量的數(shù)據(jù)來說是很適合的。

將NoSQL的應(yīng)用優(yōu)勢總結(jié)為以下3個方面。

（1）建立在低成本上的高性能

正如前面所說，NoSQL的簡單數(shù)據(jù)模型令其本身的擴(kuò)展性極強(qiáng)，節(jié)點(diǎn)的擴(kuò)展也較為容易，并且由于分布式的結(jié)構(gòu)，其設(shè)計(jì)理念就是建立在低成本的不穩(wěn)定的機(jī)器上的，因此其可以比較低廉的成本獲取高性能。另一方面的低廉指的是開發(fā)成本。目前大部分的NoSQL都是OSS（open source software），相對于要購買高額License的RDBMS來說，它是比較節(jié)省成本的。對于性能方面，NoSQL的寫入性能非常優(yōu)秀，在NHN的一個調(diào)查中，使用Cassandra對空的數(shù)據(jù)庫插入5×107個1 KB大小的記錄僅用了20 000 ps。

（2）維護(hù)簡單

相對于復(fù)雜的并行RDBMS，NoSQL的設(shè)計(jì)一般都建立在低管理需求上，如自動修復(fù)、數(shù)據(jù)分布和簡單數(shù)據(jù)模型都降低了管理成本。至少，這是開發(fā)目標(biāo)。實(shí)際情況中，也許需要比較有經(jīng)驗(yàn)和高素質(zhì)的開發(fā)者來執(zhí)行開發(fā)核心，但至少就總體來說，NoSQL對人力資源的消耗還是比較少的。

（3）易擴(kuò)展

眾所周知，傳統(tǒng)RDBMS中對于添加字段等改動操作比較難以進(jìn)行，必須要充分權(quán)衡，甚至要考慮崩潰問題。而NoSQL由于解放了數(shù)據(jù)限制，對于數(shù)據(jù)庫的改動并不需要大成本的計(jì)算，對于列式數(shù)據(jù)庫，增加一個列很簡單。

4.3 NoSQL劣勢

NoSQL也有很多不成熟的地方，開發(fā)上也有不少劣勢。這里提到3個方面的劣勢。

（1）開發(fā)消耗高

之前提到NoSQL的優(yōu)勢是開發(fā)成本低，這里為什么又說成本高呢？這是從學(xué)習(xí)轉(zhuǎn)型的角度出發(fā)的。現(xiàn)在大部分公司都是RDBMS系統(tǒng)框架，平穩(wěn)遷移的方式目前還不成熟。同時，目前NoSQL的專家級應(yīng)用者還很少，公司很難尋找到合適的人員。就目前來說，人力資源的缺口還很大，人力成本并不會減少。另一方面，NoSQL的設(shè)計(jì)目標(biāo)是減少人力維護(hù)資源，但現(xiàn)階段并沒有達(dá)成，因此相對RDBMS并沒有特別明顯的優(yōu)勢。對于用戶來說，大部分仍保持觀望狀態(tài)，采納的心理成本也需要考慮。

（2）商業(yè)資源模式少

現(xiàn)階段大多數(shù)NoSQL都是OSS，商業(yè)性的資源比較少。由于OSS本身的發(fā)展模式尚未有很完整的體系，研究也不夠深入。建立于其上的NoSQL開發(fā)也比較分散，商業(yè)資源集中度及力度都比較小。既是優(yōu)勢，讓其能無束縛發(fā)展，但同時也是發(fā)展的一個限制，需要相關(guān)領(lǐng)域研究的支撐。

（3）功能不夠齊全

相對于RDBMS，NoSQL還是新生代，功能支持度不高。相對RDBMS強(qiáng)大的功能，NoSQL仍需要時間進(jìn)行改進(jìn)。對于需要大量功能性操作的數(shù)據(jù)庫，NoSQL并不一定是個好選擇。

5 數(shù)據(jù)庫選擇

第4節(jié)討論了RDBMS和NoSQL的比較。兩者各自有優(yōu)劣勢，那么肯定會有人問，最終的選擇應(yīng)該是什么呢？這一節(jié)將對其進(jìn)行一個指引性的討論。

5.1 現(xiàn)階段RDBMS是主流

RDBMS強(qiáng)大的功能確定了其主導(dǎo)性地位。其中，Oracle鶴立雞群，其功能和性能都遠(yuǎn)遠(yuǎn)超出同行。對于SQL的分析功能，操作比較便捷也被廣泛接受。

RDBMS在讀取性能方面優(yōu)勢明顯。對于需要讀取多過寫入的應(yīng)用，RDBMS是一個不錯的選擇。

再者，最終一致性不是萬能的，對于要求一致性很高的，如銀行轉(zhuǎn)賬之類的功能，如果沒有內(nèi)置的ACID非常容易出問題。這時RDBMS也是一個不錯的選擇。

目前，RDBMS瓶頸可以通過一些向外擴(kuò)展手段進(jìn)行解決。如sharding技術(shù)可以幫助分區(qū)處理，從而提高性能。如果數(shù)據(jù)存儲量非常大，也可以使用OwFS之類的產(chǎn)品。也有一些輔助的系統(tǒng)（如ARCUS緩存系統(tǒng)）來幫助提升性能。對于新型的并行數(shù)據(jù)庫，如Grennplum、Aster等一些基于PostSQL的并行數(shù)據(jù)庫，在性能上都還不錯。

5.2 NoSQL是重要發(fā)展

什么時候考慮放棄RDBMS而使用NoSQL呢?筆者總結(jié)了以下幾種情況。

·當(dāng)只需要將應(yīng)用實(shí)體以一個持續(xù)且一致的方式存儲時，那么RDBMS太過龐大，key-value式的NoSQL也許是個好選擇。

·當(dāng)有一個繼承式的應(yīng)用對象并且需要加入一些事務(wù)處理機(jī)制時，那么所有的NoSQL方式都很適合。RDBMS也能用ORM做到，但需要掩蓋復(fù)雜性本身的復(fù)雜結(jié)構(gòu)。

·當(dāng)需要存儲大型的樹狀結(jié)構(gòu)或網(wǎng)狀結(jié)構(gòu)式的數(shù)據(jù)時，圖型NoSQL數(shù)據(jù)庫比較實(shí)用。

·當(dāng)運(yùn)行基于云系統(tǒng)并且需要數(shù)據(jù)庫的持久性和可用性時，Dynamo和BigTable類的NoSQL數(shù)據(jù)庫比RDBMS表現(xiàn)更為出色。

·列式數(shù)據(jù)庫對于分析有很好的作用，因?yàn)樗４媪藬?shù)據(jù)本身的自然性。如果需要在獨(dú)立的機(jī)器上進(jìn)行大型計(jì)算，Hadoop之類的MapReduce解決方案則很適合。

6 NoSQL Benchmarking

本節(jié)將提供一些NoSQL的標(biāo)桿測試的理論和方法，以幫助在眾多的NoSQL產(chǎn)品中選擇合適產(chǎn)品。NoSQL產(chǎn)品眾多且應(yīng)用范圍廣，并不存在一個絕對完美的選擇，但存在相對合適的產(chǎn)品。性能測試方面，目前有多種方法。作為開發(fā)建立性能模型的第一步，首先要能夠模擬實(shí)際情況的運(yùn)用，因此需要一些標(biāo)桿測試工具來幫助模擬用戶與數(shù)據(jù)庫的實(shí)際操作情況。一個好的NoSQL標(biāo)桿測試解決方案需要能夠調(diào)整參數(shù)來模擬應(yīng)用的特性，而在市面上存在的一些開源方法中，選擇最常見的YCSB作為參考。

6.1 測試需求

數(shù)據(jù)庫的測試最主要的是考慮讀取和寫入能力，這是大多數(shù)性能測試的基礎(chǔ)。雖然看似簡單，但對于NoSQL來說，一個好的性能測試檔案應(yīng)該充分考慮到特定應(yīng)用在不同環(huán)境中的表現(xiàn)。目前大部分NoSQL方案中，無論是讀取性能還是寫入性能都是樂觀的。所以有必要在測試時，使用不同的讀寫比例以多種工作負(fù)荷對性能做比較全面的分析。此外要考慮到環(huán)境的復(fù)雜性，比如Web環(huán)境中的請求率是一直改變的，所以標(biāo)桿工具也要能對請求率進(jìn)行調(diào)控。進(jìn)入路徑對于不同的應(yīng)用來說，需求也是不同的。有些網(wǎng)絡(luò)應(yīng)用會含有一組經(jīng)常被請求的簡化數(shù)據(jù)。如網(wǎng)店里的打折物品，會經(jīng)常被請求數(shù)據(jù)并且購買寫入數(shù)據(jù)。也有些應(yīng)用會對最新的記錄進(jìn)行大量請求，如新聞，最近的文章就會被更多地請求。因此NoSQL標(biāo)桿測試工具也要能對不同的請求分布進(jìn)行支持。另外一個重要的需求是提供公正的對比。應(yīng)用的范疇是不盡相同的，不同的NoSQL方案應(yīng)該在符合應(yīng)用特性的環(huán)境下測試，才能夠真正起到指導(dǎo)選擇的作用。

6.2 YCSB

YCSB（Yahoo!cloud server benchmark）是 NoSQL 數(shù)據(jù)庫標(biāo)桿的代表性應(yīng)用。YCSB是Yahoo!開發(fā)的一個測試框架，可以對市面上比較流行的幾個NoSQL方案提供詳細(xì)的對比資料，包括HBase、Cassandra、MongoDB等，未包含的數(shù)據(jù)庫可以使用提供的API自行編寫測試。

YCSB提供的測試框架非常靈活，用戶可以對特定的參數(shù)進(jìn)行設(shè)置，以針對特別產(chǎn)品進(jìn)行分析。YCSB提供兩個標(biāo)桿層。第一個層次主要是測試存儲性能，而第二個層次是測試擴(kuò)展能力。測試性能的第一層主要是在相同硬件設(shè)置下，對比請求時延和輸出的取舍。常見基本測試方法為記錄工作量增加時時延的變化，直到系統(tǒng)飽和時輸出結(jié)束。第二層次主要是測試系統(tǒng)增加減少節(jié)點(diǎn)時的性能，如增加機(jī)器時如何表現(xiàn)，或者在系統(tǒng)運(yùn)轉(zhuǎn)時加入機(jī)器的變化。此外YCSB提供如分布請求、讀寫率等多種參數(shù)，能夠盡可能地模擬實(shí)際情況，做出相對正確的結(jié)論。

實(shí)際上除了YCSB，還有NoSQL等很多測試框架，如VoltDB等。這些測試框架各有千秋，對于實(shí)際應(yīng)用設(shè)計(jì)還需要能夠?qū)ｉT的參數(shù)設(shè)置進(jìn)行全面分析。針對現(xiàn)在的一些標(biāo)桿測試，有學(xué)者提出無用居多，究其原因就是忽略了實(shí)際環(huán)境的一些問題，而比較單純地進(jìn)行基礎(chǔ)比較。所以對于NoSQL的標(biāo)桿，也需要針對具體問題進(jìn)行實(shí)際測試。

7 結(jié)束語

經(jīng)過上述討論，對NoSQL有一個概念上的認(rèn)識，并且對NoSQL和RDBMS的對比有了一個大致的了解。實(shí)際上NoSQL和RDBMS并不是一個完全對立的概念，也有很多產(chǎn)品致力于整合雙方優(yōu)勢而取得突破。其根本性差別是數(shù)據(jù)屬性。如HadoopDB是在非關(guān)系型數(shù)據(jù)庫上層加入SQL層，而ASTER是在關(guān)系型數(shù)據(jù)query中應(yīng)用MapReduce。面對NoSQL的眾多產(chǎn)品群體，標(biāo)桿測試必須要考慮實(shí)際環(huán)境情況，對參數(shù)的設(shè)置分析有一個比較全面的了解，盡量避免架空測試。

綜上所述，對于數(shù)據(jù)庫的選擇，在大數(shù)據(jù)時代來臨的壓力下，需要更嚴(yán)密的思考。并不存在一個絕對正確的選擇，權(quán)衡利弊，多方調(diào)查才是上策。

1 Padhy R P,Patra M R,Satapathy S C.RDBMS to NoSQL:reviewing some next-generation non-relational database’s.InternetionalJournalofAdvanced Engineerin Sceince and Tecnologies,2011,11(1)

2 Christof S.NoSQL Database.Hochschule Der Medien,Stuttgart,2011

3 Lee K J.What is NoSQL for.http://www.Cubird.com,2011

4 王珊，王會舉，覃雄派等.架構(gòu)大數(shù)據(jù):挑戰(zhàn)、現(xiàn)狀與展望.計(jì)算機(jī)學(xué)報,2011(34)

5 Tudorica B G.A comparison between several NoSQL databases with comments and notes.Roedunet International Conference(RoEduNet),Iasi,Romania,2011

6 Cattell R.Scalable SQL and NoSQL Data Stores.ACM SIGMOD Record,2011

7 孟小峰.云數(shù)據(jù)管理與NoSQL運(yùn)動.中國計(jì)算機(jī)學(xué)會通信，2011,4(7)

8 Michael S.SQL databases vs NoSQL databases.Communications of the ACM,2010,53(4)

9 Laurent A,Sala M,Laurent B,et al.Reduce,you say:what NoSQL can do for data aggregation and BI in large repositories.22nd International Workshop on Database and Expert Systems Applications(DEXA),2011

10 Tauro C J M,Aravindh S,Shreeharsha A B.Comparative study of thenewgeneration,agile,scalable,highperformance NoSQL databases.International Journal of Computer Applications,2012,48(20)

11 Schneider S A.Big data:big challenge,big opportunity.http://www.globant.com,2012