NoSQL理論體系及應用

李馮筱，羅高松

（廣州優億信息科技有限公司 廣州 510630）

1 引言

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

2 NoSQL基礎理論

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

2.1 CAP理論

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

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

可用性：一個系統能夠持續不間斷使用的問題。嚴格定義上的高性能可用性意味著一個系統從設計到實施都應該能夠提供可持續的操作（如讀寫操作），無論是操作沖突，還是軟硬件部分因為升級而導致失效。

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

現在Brewer提出，在數據共享系統中這3種特性是無法同時實現的，最多只能選擇其中兩種執行，這個理論已經得到了大量的驗證。很簡單的例子，如復制必須能在多節點上進行，從而提升可用性，那么數據副本（replica）之間就面臨調試。但為了在網絡分區的情況下也能夠正常工作，復制或數據間的調試就很難執行。所以CAP僅能得以部分保證。

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

對于數據庫，Brewer總結道，由于一致性和可用性無法兼得，大多數NoSQL擁護者都選擇了一致性高于可用性的設計模式，除了NoSQL，這些理論也影響到了部分關系型數據庫。表2總結了一些現存常用產品的設計架構的CAP取舍以及其對應的功能分類。

2.2 BASE思想

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

表1 CAP理論應用特點及例子

表2 CAP理論數據庫應用實例及功能分類

要解釋BASE思想，首先要對ACID有一個了解，因為BASE是相對于DBMS中的ACID所提出來的新思想。ACID指的是傳統數據庫對于數據特性的要求，詳細介紹如下。

·原子性（A）：即事務執行作為原子，不可再分離，整個語句要么執行，要么不執行，不可能停在中間某個環節。

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

·隔離性（I）:兩個事務的執行互不干擾，一個事務不可能看到其他事務運行時中間某一時刻的數據。兩個事務不會發生交互。

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

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

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

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

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

表3 BASE與ACID的優缺點對比

2.3 最終一致性

有兩種方式看待一致性。一種是從開發者/客戶端的角度，如何觀察數據更新；另一種是從服務器端，更新如何在系統中流動以及對于更新系統能提供什么樣的保證。客戶端觀察到的一致性指的是，何時以及如何能觀察到對存儲系統中的數據對象所做的更新。

對于一致性的解釋，根據強度的不同，分為強一致性和弱一致性兩種。

強一致性，即所有的讀取操作都必須返回最新的寫入操作的數據，而忽略復寫操作的路徑。這樣的需求要求對于數據的操作（寫入和讀取）都必須在同一節點上，否則強一致性將受到分布式事務傳輸協議的影響 （如2PC和Paxos）。因此，根據CAP理論，強一致性無法和可用性、分區容忍性同時實現。

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

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

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

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

·Session Consistency指的是在一定范圍內（通常為同一服務器內），客戶端能看到同范圍內的實時更新。

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

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

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

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

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

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

2.4 三大基石的意義

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

三大基石互相補充，互相以各自為基礎進行衍伸，形成了一個標準的理論體系。然而，由于開發應用尚未進入完全成熟的階段，因此這個理論細節也在不斷的變革中。與傳統RDBMS“以一適用全部”的思想相比，NoSQL的理論體系發展更強調個體適應性。針對具體產品，需要有嚴格的考核思量過程，明確需要什么、可以放寬什么，進而進行合理設計。

3 NoSQL產品分類

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

4 NoSQL與RDBMS對比

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

表4 NoSQL產品分類

4.1 傳統RDBMS瓶頸

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

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

（1）數據與事務要求過高，很難達成

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

·要保證原子性，那么2PC這樣的協議就必須在與特定事務相關的全部系統中都用。

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

所以要在分散式環境中保證原子性的獨立性，當分布式事務協議被處理時，所有的相關系統都要被鎖住；系統的服務越多，鎖的任務越繁重。這就是向外擴展結構很難的原因。

（2）復制和分散數據是RDBMS向外擴展結構的另一個限制

·用2PC方法進行事務性的復制存在一個問題，就是當一個相關系統的復制操作失敗時，事務本身也會失效并且變得不可用。

·WAL日志方法能夠優化事務DBMS的事務提交過程。如果將系統中的復制進程看作主，變化應用進程是從，那么系統就是主從式或者多主式的。當用多主式時，就很難解決多個主進程同時寫進程或阻止進程的沖突問題。

·數據本身存儲結構為關系型，數據庫本身的擴展限制很多，技術很麻煩。

（3）并行數據庫

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

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

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

并行數據庫擴展性的有限主要因為如下兩點。

·并行數據庫軟件級容錯能力較差，并行數據庫基于高端硬件設計，并且假設查詢失敗屬于稀有事件，因此當查詢失敗時，一般采取重做查詢的方式；而在大規模機群環境下，查詢失敗將會變為一個普通事件，極端情況下，并行數據有可能出現不停重做查詢的局面。

·并行數據庫對異構硬件的支持非常有限，且對于處理較慢的節點反應敏感，容易出現“木桶效應”。所以RDBMS的功能雖然非常強大，但針對個別化問題的解決方案卻很難進行擴展，于是出現了NoSQL來解決問題。

4.2 NoSQL優勢

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

將NoSQL的應用優勢總結為以下3個方面。

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

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

（2）維護簡單

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

（3）易擴展

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

4.3 NoSQL劣勢

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

（1）開發消耗高

之前提到NoSQL的優勢是開發成本低，這里為什么又說成本高呢？這是從學習轉型的角度出發的。現在大部分公司都是RDBMS系統框架，平穩遷移的方式目前還不成熟。同時，目前NoSQL的專家級應用者還很少，公司很難尋找到合適的人員。就目前來說，人力資源的缺口還很大，人力成本并不會減少。另一方面，NoSQL的設計目標是減少人力維護資源，但現階段并沒有達成，因此相對RDBMS并沒有特別明顯的優勢。對于用戶來說，大部分仍保持觀望狀態，采納的心理成本也需要考慮。

（2）商業資源模式少

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

（3）功能不夠齊全

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

5 數據庫選擇

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

5.1 現階段RDBMS是主流

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

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

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

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

5.2 NoSQL是重要發展

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

·當只需要將應用實體以一個持續且一致的方式存儲時，那么RDBMS太過龐大，key-value式的NoSQL也許是個好選擇。

·當有一個繼承式的應用對象并且需要加入一些事務處理機制時，那么所有的NoSQL方式都很適合。RDBMS也能用ORM做到，但需要掩蓋復雜性本身的復雜結構。

·當需要存儲大型的樹狀結構或網狀結構式的數據時，圖型NoSQL數據庫比較實用。

·當運行基于云系統并且需要數據庫的持久性和可用性時，Dynamo和BigTable類的NoSQL數據庫比RDBMS表現更為出色。

·列式數據庫對于分析有很好的作用，因為它保存了數據本身的自然性。如果需要在獨立的機器上進行大型計算，Hadoop之類的MapReduce解決方案則很適合。

6 NoSQL Benchmarking

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

6.1 測試需求

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

6.2 YCSB

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

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

實際上除了YCSB，還有NoSQL等很多測試框架，如VoltDB等。這些測試框架各有千秋，對于實際應用設計還需要能夠對專門的參數設置進行全面分析。針對現在的一些標桿測試，有學者提出無用居多，究其原因就是忽略了實際環境的一些問題，而比較單純地進行基礎比較。所以對于NoSQL的標桿，也需要針對具體問題進行實際測試。

7 結束語

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

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

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 王珊，王會舉，覃雄派等.架構大數據:挑戰、現狀與展望.計算機學報,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 孟小峰.云數據管理與NoSQL運動.中國計算機學會通信，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