NoSQL數據庫介紹（2）

2 NoSQL潮流

     在這一章中，將一塊兒討論NoSQL潮流的動機和主要驅動力。以及NoSQL主張的批評和反饋。本章將經過不一樣的嘗試得出結論來分類和描寫敘述NoSQL數據庫。當中一個分類法將在隨後的章節中被提出。

2.1 動機和主要驅動力

     NoSQL這個詞彙首先用在1998年對關係數據庫排除SQL使用的論文（[ Str10 ]）。這個詞在2009年再次被選出來。並用於非關係數據庫擁護者（如Last.fm的開發人員Jon Oskarsson，他組織了三藩的NoSQL見面會）的會議（[ Eva09a ]）。一個博主。一般被以爲使該詞彙流行的人是Rackspace公司員工Eric Evans。後來提出了NoSQL運動的雄心是「尋求替代方案的重點是。要解決關係數據庫不適合的問題」（[ Eva09b ]）。

     本節將討論這一領域中發展和使用非關係數據庫的實踐者並展現理論上的成果。此外，將介紹NoSQL運動的起源和主要驅動力。

2.1.1 NoSQL實踐者的動機

     在計算機世界雜誌一篇關於三藩的NoSQL會面的報道。「NoSQLers來分享他們怎樣推翻緩慢而昂貴的關係數據庫的暴政，有利於用更有效和更廉價的方法來管理數據。」（[Com09a ]）。它表示特別是Web2.0初創公司，已經在沒有Oracle甚至沒有曾經很是流行的MySQL的環境下開始他們的業務。相反，他們創建了本身的數據存儲如Amazon的Dynamo（[DHJ+07]）和Google的Bigtable（[CDG+06]）來存儲和處理大量數據的出現，比方像他們在社交或雲計算應用。同一時候。大部分這些數據存儲變成開源軟件。好比，Cassandra最初是爲Facebook的新搜索功能開發的，現在是Apache軟件項目的一部分。依據project師Avinash Lakshman，它在寫50GB大的數據庫時比MySQL快2500倍（[LM09]）。

    

     計算機世界的文章總結了常用的開發和使用NoSQL數據存儲的緣由：

    

     避免沒必要要的複雜性  關係型數據庫提供了多種功能和嚴格的數據一致性。但RDBMS實現的這樣的豐富的功能和ACID特性可能對特定應用和需求來講是超配的。

     好比，Adobe的ConnectNow持有三份用戶會話數據；這些副本沒必要須接受RDBMS的所有一致性檢查，也不需要持久化。所以，全然足以將它們保存在內存中（[Com09b]）。

    

     高吞吐  一些NoSQL數據庫比傳統RDBMS提供更高的數據吞吐率。

好比，列存儲Hypertable遵循Google的Bigtable方法，贊成本地搜索引擎Zvent儲存天天十億數據單元[Jud09]。再舉一個樣例，Google天天能夠處理20PB存儲在Bigtable的數據。經過它的MapReduce方法[Com09b]。

     水平擴展性和在商用硬件上執行  「確定的，數據量是變得如此巨大，人們在尋找其它的技術」。SpringSourceproject師Jon Travis說（[Com09a]）。博客做者Jonathan Ellis容許這一觀點，提到現有的關係型數據庫的三個問題，NoSQL數據庫試圖解決（[Ell09a]）：

     1.擴展數據（如Digg的綠色徽章特性（注：不明真相）3TB，Facebook的inbox搜索50GB，eBay總量2PB。注：都是10年數據）

     2.單點性能

     3.剛性模式設計

     與RDBMS相反，大部分NoSQL數據庫被設計爲在水平方向可擴展，且不依靠高度可用的硬件。機器可以加入和刪除（或崩潰），並避免形成如同RDBMS的集羣方案中實施數據分片那樣的操做努力；一些NoSQL數據甚至提供本身主動分片（如MongoDB截至2010年3月，參見[ Mer10g ]）。Javier Soltero，SpringSource的CTO是這樣說的：「Oracle會告訴你。使用正確的硬件級別和正確的Oracle RAC（Real Application Clusters）配置和其它相關軟件。可以實現一樣的可擴展性。但是以什麼代價？」（[Com09a]）。

尤爲是對Web 2.0公司，可擴展性方面的考慮對他們的業務相當重要，就像Last.fm的Johan Oskarsson指出：「Web 2.0公司可以抓住機會，他們需要可擴展性。當你將這二者組合，會使NoSQL很引人注目。

」（Johan Oskarsson。Last.fm的meetup組織者和web開發。參見[Com09a]）。

博主Nati Shalom容許：「成本壓力也迫使不少組織尋找更具成本效益的替代品，研究代表。基於商用硬件的分佈式存儲可以比不少現有的高端數據庫更可靠」（參見[ Sha09a ]和進一步閱讀[ Sha09c ]）。

他總結道：「所有的這些致使了一個高效成本的'擴展第一數據庫’的需求」。

     避免昂貴的O-R Mapping  大部分的NoSQL數據庫被設計成存儲要麼簡單的、要麼與關係數據結構相比更相似於面向對象編程語言的數據結構。它們不會使昂貴的對象-關係映射成爲必需（如鍵/值存儲或文檔存儲）。

這對具備低複雜度的數據結構的應用特別重要。因其很是難從關係數據庫的特性中受益。

Dare Obasanjo聲稱「所有你真的需要[做爲一個Web開發者]是支持某種程度的查詢功能並具備良好的持久性語義的鍵-值或元組存儲。」（[Oba09a]）。博主和數據庫分析師Curt Monash也在這方面表示：「SQL是過程式代碼的一個尷尬的選擇，差點兒所有的代碼是過程式的。

對用戶但願作重的、反覆操做的數據而言，映射數據到SQL的成本是值得的。

但當你的數據庫結構是很很的簡單，SQL可能不是故意的。

」SpringSourceproject師Jon Travis容許：「關係型數據庫給你太多。他們強迫你扭曲你的對象數據以適合RDBMS。」（在[Com09a]引用）。

     在一篇計算機世界的博客中，GigaSpaces首席技術官和創始人Nati Shalom指出下面驅動了NoSQL潮流（[ Sha09b ]）：

     數據庫集羣的複雜性與成本  他指出，NoSQL數據庫被設計成在某種程度上「PC集羣可以很是easy和廉價地擴展並避免分片的複雜性和成本」，涉及到將數據庫切分爲多個表以便在大的集羣或網格上執行。

     爲更好性能妥協的可靠性  Shalom以爲有「應用程序願意爲更好的性能而在可靠性上妥協的不一樣場景」。做爲一個這種妥協樣例，他提到HTTP會話數據「需要在不一樣的網絡server之間共享，但由於數據是臨時的。在本質上（當用戶登出時它會消失）沒有必要將它存儲在持久存儲中。

」

     現有「一刀切」的數據庫思想是錯誤的  Shalom以爲「愈來愈多的應用場景不能用傳統的數據庫方法來解決」。他以爲。「這樣的認識實際上並無那麼新」，因爲Michael Stonebraker的研究（見下文）已經有很是多年了。但過去幾年，老的「新聞」已經蔓延到了一個更大的社區。Shalom以爲，對傳統RDBMS的替代品的實現和研究可以用兩個主要趨勢解釋：

     1.連續增加的數據量（需存儲）

     2.在更短的時間內處理大量的數據的需求不斷增加

     一些公司特別是Web系的，已經採用NoSQL數據庫，Shalom估計隨着這些數據存儲的成熟，他們會找到本身的方式用於主流開發。博主Dennis Forbes容許這一觀點。強調銀行的要求不是廣泛的，尤爲是社交媒體站點有不一樣的特色：「數據的孤島」、一個「很低的用戶/事務比值」和數據完整性的需求不強。考慮到這些特色，關於社交媒體站點和大型網絡應用他有例如如下觀點：

     「事實是。Facebook更新狀態或推特或Slashdots評論不需要ACID。

僅僅要你的業務和表現層可以有力地處理不一致數據，這並不真的很是重要。

很是明顯這不是理想的，並且最好沒有不論什麼數據損失、不一致或服務中斷，但是接受數據丟失或不一致（甚至僅僅是臨時的）做爲一種可能性，打破了迄今爲止關係數據庫世界最大的’障礙’，可以產生巨大的靈活性。

     這是不少社交媒體站點的狀況：數據的完整性基本是可選的。保證完整性的費用是沒必要要的開支。成千上萬的用戶和成千上萬的事務後，當你從廣告點擊賺到錢。你開始尋找優化。」

     Shalom建議當心走向NoSQL解決方式和熟悉他們的詳細優點和劣勢（好比：業務邏輯處理不一致的能力）。其它。像10gen（MongoDB背後的公司）的David Merriman也強調，數據存儲沒有一個單一的工具或技術。但數據庫領域有一個分裂眼下正在進行中，帶來了新的和不一樣的數據存儲。好比商業智能vs.在線事務處理vs.大量二進制數據的持久化（[Tec09]）。

     簡易分佈和集中數據模型劃分的神話  Shalom進一步提到環繞這一直覺的神話，即數據模型最初設計爲一個單一的數據庫（集中式數據模型，正如他所指出的）經常不能輕易在數據庫server間分區和分散。這意味着，假設沒有進一步的努力。應用程序將既沒法按需擴展也不能正確工做。Ajatus的專家容許這樣的說法。在博客中說，假設數據庫會增加。首先應配置複本。此外，隨着數據量的進一步增加，數據庫分片需要昂貴的系統管理，需要大量資金或財產聘用DBMS供應商來經營分散的數據庫（[ Aja09 ]）。

Shalom報道了2009夏天eBay的一次架構峯會。與會者一致容許。儘管一般狀況下，抽象被引入以試圖隱藏應用程序（如經過代理層將請求路由到特定的server）中分散和分區問題，「這個抽象沒法將應用與分區和分散的現實隔離。故障幅度在一個網絡內全然不一樣於一臺機器內的故障。

應用程序需要注意到延遲、分佈式故障等，使得它有足夠的信息來作出詳細的上下文相關的決定。系統是分佈式的事實滲透到這樣的抽象中。」（[ Sha09b ]）。所以他建議設計數據模型以適應分區環境，即便最初僅僅有一個集中式數據庫server。這樣的方法提供的優點是避免極晚且昂貴的應用代碼更改。

     Shalom總結，在他看來，DBMS將不會很是快消失。

然而，更專業的解決方式會實用武之地，因爲一個「一刀切」的思想之前是並且現在仍是對於數據庫的錯誤認識。

     編程語言和開發框架的潮流  博主David Intersimone額外觀察了編程語言和開發框架（其提供對數據庫訪問的抽象時試圖隱藏SQL以及關係數據庫的使用（[ Int10 ]））的趨勢。這一趨勢在過去幾年的樣例包含：

•      Java和.NET世界中的實體關係映射。如Java持久化API（JPA，EJB3規範的一部分，[DKE06],[BO06]）。實現如Hibernate（[JBo10a]）。或帶SQLMetal代碼生成器的LINQ Framework（[BH05]）。和從.NET version4 開始的ADO.NET Entity Framework（[Mic10]）。
•      相同的，流行的Ruby on Rails框架（[HR10]）和其它隱藏關係型數據庫使用的嘗試（如實現RoR中的動態記錄模式）
•      NoSQL數據存儲以及一些雲計算供應商提供的數據庫全然省略了關係數據庫。

  這種雲數據存儲的一個樣例是Amazon的SimpleDB。一個無模式，基於Erlang的終於一致性的數據存儲，其特色是做爲一個實體的屬性值（EAV）。

  它可以存儲大量items的集合，當中items是裝載由鍵值對組成的屬性集的hashtable（[ Nor09 ]）。

     這些NoSQL數據庫反應這一趨勢。並嘗試在他們的API中提供接近於編程語言的數據結構（好比，鍵/值結構，文檔。圖表）。

     雲計算的需求  在一次採訪中10gen（MongoDB背後的公司）的Dwight Merriman提到了在雲計算環境中數據存儲的兩個主要需求（[ Tec09 ]）：

     一、高直到差點兒無限的可擴展性。特別是在水平方向

     二、低管理開銷

     在他看來，如下幾類數據庫在雲中工做很是好：

•      數據倉庫型特定數據庫，爲批量數據處理和Map/Reduce做業設計的
•      簡單，可擴展和高速的鍵值對存儲
•      包括比鍵值對存儲更豐富特性的數據庫。填補了傳統RDBMS的空白，並提供良好的性能和擴展性（如文檔數據庫）

     博主Nati Shalom容許Merriman。其實應用領域如雲計算等對NoSQL數據庫是助力：「過去是僅僅有少數至關高端的組織面對的利基問題。隨着社交網絡和雲計算的引入更爲廣泛了（[ Sha09a ]）。

     RDBMS加緩存層模式/工做區 vs. 考慮擴展性從零開始構建系統  在他的文章「MySQL和Memcached：一個時代的結束？」中，Todd Hoff說「在雲出現前，關係型數據庫爲主的世界」的可擴展性是「利用MySQL和memcached」的一個問題：

     「對MySQL分片以處理高寫入負載，再memcached中緩存對象以處理高讀負載，而後寫了大量的膠水代碼使其全部工做在一塊兒。那之前是藝術，那之前是必須這樣作的。今天不少主要站點的架構仍遵循這樣的模式。很是大程度上是因爲在投入足夠的力氣時，它可以工做。」（[ Hof10c ]）

     但隨着可擴展性要求的增加，這些技術愈來愈不能夠適應他們。

此外，隨着NoSQL數據存儲的發展Hoff得出結論：「看遠一點，很是明顯MySQL + memcached的時代正在過去。它將堅持一段時間。

舊技術很是少全然消失。

」（[ Hof10c ]）。

做爲樣例。他列舉了大站點和玩家走向非關係數據存儲包含LinkedIn、Amazon、Digg和Twitter。Hoff提到下面使用NoSQL解決方式的緣由，已在本文前面解釋：

•      關係數據庫在讀時計算，這對大型網絡應用（如Digg）被以爲是錯誤的。

  NoSQL數據庫所以不提供或避免複雜的讀操做。

•      應用程序的線性特性需要經常等待從數據存儲的I/O，這對可擴展性和低響應時間不利。

•      大數據量和高的生長因子促進Twitter開始使用Cassandra，它被設計爲可操做大尺度數據。
•      此外，像Twitter這種公司執行和維護系統的運營成本不斷上升。

  這種規模的網絡應用於是「需要一個可以以更本身主動化的方式來發展並高度可用的系統」（在[ hof10c ]引用）。

     由於這些緣由以及MySQL和memcached時代的「笨拙性」（Hoff所謂的），現在的大型（網絡）應用程序可以利用從頭開始創建可擴展性的、非堵塞和異步數據庫I/O、海量數據、維護和操做任務的本身主動化處理的系統。他以爲這些系統是更好的替代品，相比RDBMS加對象緩存。

Amazon的James Hamilton容許這一聲明。對不少大型站點的可擴展性，從零開始是相當重要的。甚至比與傳統RDBMS相比缺乏部分特性的劣勢更重要：

     「擴展第一的應用程序是那些絕對必須不受約束地擴展。且無約束擴展這件事比不少其它的特性更重要。這些應用有大規模大型站點如Facebook、MySpace、Gmail、Yahoo和Amazon。一些站點其實是利用關係數據庫，但很是多不是。

所有這些服務的共同主題是。擴展比特性更重要。他們沒有可能執行在一個單獨的RDBMS上。」（參見[ Ham09 ]引用[ Sha09a ]）

     昨日的需要 vs. 今日的需要  在關於CouchDB的討論中，Lehnardt和Lang指出對於數據存儲的需要已經發生了很是大的變化（[ PLL09 ]。這一論點由Stonebraker進一步迭代，見下文）。

在上世紀60和70年代的數據庫被設計爲單一的大型高端機器。

與此相反，今天。不少大型（網絡）公司使用可能會故障的商用硬件。所以應用程序被設計來處理這種故障，被以爲是「操做的標準模式」。就像Amazon指出的（參見[ DHJ+07。205頁]）。此外。關係數據庫適合的數據是剛性結構的關係。並贊成用一個複雜語言表示的動態查詢。Lehnhardt和Lang指出，今天。特別是在網絡領域。數據既不是嚴格的結構，也不需要動態查詢，大多數應用程序已經使用準備語句或存儲過程。所以。數據庫內提早定義查詢和動態賦值給變量是足夠的（[ PLL09 ]）。

     此外。關係數據庫最初設計爲集中部署，而不是分佈。儘管對集羣的強化已被增長，它仍然是經過傳統的沒有分佈式的概念開始設計（像例如如下提出的「網絡計算的設施」問題）。做爲一個樣例，一般同步未有效地實現，而是需要昂貴的協議，如兩或三階段提交。Lehnhardt和Lang看到的還有一個困難是，關係數據庫集羣的嘗試是「透明」的應用。這意味着應用程序不該該包括不論什麼它在和一個單獨的機器或一個集羣進行交談的概念，所有分佈式的方面都試圖從應用程序中隱藏。

他們質疑這樣的保持應用程序感知不到不論什麼分佈式的後果的方法，如在著名的八個分佈式計算的謬誤中描寫敘述的（[ Gos07 ] ）：

     「基本上每個人，當他們初次構建一個分佈式應用程序時，會作出下面八若是。它們在長期執行過程當中都被證實是錯誤的。都會致使大麻煩和痛苦的學習經驗：

     一、網絡是可靠的

     二、延遲是0

     三、帶寬是無限的

     四、網絡是安全的

     五、拓撲是不變的

     六、有一個管理員

     七、傳輸的消耗是0

     八、網絡是同構的」

     儘管典型的使用RDBMS的業務應用程序，在大多數狀況下，嘗試在應用中隱藏分佈式細節（好比：經過集羣、持久層作對象關係映射），但不少大型網絡公司和大部分的NoSQL數據庫不追求這樣的方法。相反，他們讓應用程序知道並利用它們。這在Lehnardt和Lang眼中被以爲是一個範式轉變（參見[ PLL09 ]）。     

     進一步的動機  除了上面提到的，David Intersimone看到NoSQL潮流的下面三目標（[ Int10 ]）：

•      得到較關係數據庫小的的開銷和內存佔用
•      經過Web技術和RPC調用訪問
•      數據查詢的可選形式

2.1.2 理論工做

     在普遍採用的論文「架構時代的終結」（[ SMA+07 ] ）中，Michael Stonebraker等得人出結論「現有的RDBMS的代碼，試圖成爲一個’一刀切’解決方式。其實不擅長於不論什麼事」。在這樣的狀況下沒有不論什麼東西意味着他們能與超越他們「1–2個數量級」（[ Sc05 ]、[ SBc+07]）的「數據倉庫、數據流處理、文本和科學數據庫市場的專用引擎」競爭，在他們熟悉的業務數據處理/在線事務處理（OLTP）市場也表現很差，當中一個麻省理工開發的名叫H-Store的原型在TPC-C基準上戰勝RDBMS將近兩個數量級。由於這些結果，他們得出結論。RDBMS是「應退休的25歲的遺留代碼，取而代之的是一系列‘從零開始’研發的專用引擎。

數據庫管理系統供應商（和研究界）應該開始用一張白紙爲明天的要求設計系統。而不是繼續爲昨天的需求推進代碼行和架構設計」。但Stonebraker等人怎樣得出這個結論？他們在關係型數據庫管理系統中發現什麼固有的缺陷？他們爲「全然重寫」提供什麼建議？

     首先，Stonebraker等以爲。RDBMS架構已經超過25年。當時硬件特性、用戶需求和數據庫市場與今天的不一樣。

他們指出，「流行的RDBMS全部能追朔到20世紀70年代的System R」：IBM的DB2是一個System R的直系後代，微軟的SQL Server從Sybase System 5進化而來（還有一個System R的直系後代）。Oracle在其第一個版本號中實現了System R的用戶界面。於是，System R的架構已經被70年代的硬件特性影響了。那之後。處理器速度、內存和磁盤的大小有顯著添加，這些因素今天已經不像過去那樣限制程序。然而。硬盤和內存間的帶寬並不像CPU速度、內存和磁盤大小那樣添加得快。

Stonebraker等批評，硬件領域的發展沒有影響RDBMS的架構。尤爲是下面的System R的架構特色仍然在今天的RDBMS中可以找到：

•      面向磁盤的存儲和索引結構
•      多線程來隱藏時延
•      基於鎖的併發控制機制
•      基於日誌的恢復

     在這方面。他們強調說，儘管「過去幾年有了一些延伸，包含支持壓縮、共享磁盤架構、位圖索引、支持用戶定義的數據類型和操做，但從一開始就沒有不論什麼系統的又一次設計」。

     其次，Stonebraker等人指出，自20世紀70年代以來，新的市場和用例已經出現，但可用的僅僅有商業數據處理。

這些新興市場的樣例包含「數據倉庫、文本管理和流處理」。「它們的需求與商業數據處理有很是大的不一樣」。在先前的文章（[ Sc05 ]）他們已經說明了RDBMS「會在一些應用領域被專業的架構超過一個數量級或不少其它，包含：

•      文本（專業引擎如Google，Yahoo等）
•      數據倉庫（列存儲如Vertica，Monet等）
•      流處理（流處理引擎如StreamBase和Coral8）
•      科學和智能數據庫（數組存儲引擎如MATLAB和ASAP）」

     他們繼續注意到。過去幾十年用戶界面和使用模式也改變了，從「操做員輸入查詢」的終端到富client和網絡應用程序，今天互動查詢和直接的SQL接口是罕見的。

     Stonebraker等現在給出了「眼下RDBMS的架構甚至不適合業務數據處理的證據」。他們設計了一個OLTP的DBMS引擎稱爲H-Store，其在功能上適於跑TPC-C基準。比流行商用DBMS快82倍。基於這種證據，他們總結「它們在不論什麼一個市場都沒有競爭力。所以，他們應該被視爲超過四分之中的一個個世紀的過期技術。全然又一次設計和重構是適當的下一步」。

設計考量

     在一篇關於設計考量的文中。Stonebraker等人解釋爲何即便在業務數據處理的老本行內RDBMS也被超越。以及他們本身的DBMS原型H-Store爲什麼可以實現「比現有的RDBMS好得多的性能」。

特別是他們的考慮反映過去幾十年的硬件發展，以及它怎樣能或應該改變RDBMS的架構以便從更快和更大的硬件中得到優勢。也給他們堅持的「全然重寫」以註解。

     主內存  與70年代相比，大量的主內存變得廉價，因爲「OLTP數據庫絕大多數是小於1TB並且增加得至關緩慢」他們得出這種結論：這種數據庫是「現在或在不久的未來能夠部署在主內存中的」。

Stonebraker等人所以以爲OLTP市場在今天或在不久的未來是內存數據庫市場。

他們所以批評，「眼下RDBMS供應商用面向磁盤的解決方式處理主內存問題。總之。摩爾定律的30年已使OLTP應用程序的面向磁盤的體系結構變得過期」。

儘管有些關係數據庫在內存中執行（好比TimesTen。SolidDB）。但這些系統也從System R繼承了「包袱」——Stonebraker等人對基於磁盤的恢復日誌或動態鎖定的稱呼，這對這些系統的性能有負面影響。

     多線程和資源控制  如前所述，Stonebraker等人以爲數據庫是主內存市場。現在他們表示，事務一般僅僅會影響到僅僅有少數幾個需要讀/寫的數據集（如TPC-C基準測試中最多200讀），假設這個數據是保存在內存中且沒有磁盤IO或出現用戶中斷。將是很划算的。所以。他們以爲在這種主內存數據庫中不需要多線程執行模型。這使得傳統關係數據庫中至關多的「具體代碼」可有可無，即多線程系統爲了最大限度地提升中央處理器和磁盤的使用。資源管理者限制負載以免使用消耗資源的和多線程的數據結構如併發B樹。「這是一個更可靠的系統，一個有更高性能的系統」，他們說。

爲了不在這樣一個單線程系統中長期執行的事務，要求應用程序將此類事務分解爲較小的事務。或——在分析的目的下——在爲該任務優化過的數據倉庫中執行這類事務。

     網格計算和在線擴容  此外，Stonebraker等人概述了70年代共享內存架構、80年代共享磁盤架構、今天和將來的無共享架構的發展，這「一般被稱爲網格計算或刀片計算」。做爲一個結果，Stonebraker等人堅持數據庫必須反映這一發展，比方（和最明顯的）DBMS網格中多節點間的水平切割。此外。他們主張這樣的網格的增量水平擴展應該無需由管理員又一次載入部分或所有數據，也不停機。

他們指出，這些要求顯著影響了DBMS的架構，如在不影響執行事務的條件下數據傳輸的能力，這可能不能很是easy地加入到現有的RDBMS中。但可以在新系統的設計中考慮（像比較新的數據庫如Vertica）。

     高可用性  Stonebraker等人陳述的下一主題是高可用性和故障轉移。

從新，他們概述了這一問題的歷史發展，從線下保存當災難發生時再恢復的日誌磁帶，到將日誌磁帶掛在遠程硬件上並提供災備服務。到今天很是廣泛的熱備份或多網站解決方式。Stonebraker等人把高可用性和內置的災難恢復做爲一個重要的功能。像他們提到的其餘設計問題同樣，在這些系統的架構和設計層面考慮。他們特別需要OLTP領域的DBMS具備：

     一、保持多個副本一致。需要在地理位置上分散的系統上無縫執行的能力

     二、開始在系統底層使用無共享的支持，用於代替SMP架構上多計算機的支持

     三、支持無共享架構的最好方式是，用「對等網絡環境下的多臺機器」以便「負載可以分散在多臺機器。機器間的副本可用於容錯」。在這種配置中。普通操做下可以利用所有的機器資源，且故障僅僅會致使退化的操做因爲僅僅是可用資源較少而已。相比之下。今天的HA解決方式在普通操做下有一個熱備份僅僅利用硬件資源的一部分，因爲熱備機器僅僅是在等待活躍機器死掉。總之「這些觀點說明應全然又一次設計RDBMS引擎，使其在新架構下實現點對點的HA」。他們得出這種結論。

     在這樣一個Stonebraker等人要求的高可用系統。他們看不到不論什麼重作日誌的需要，如在一個網站故障的狀況下，恢復活動「可在任一網站的數據上刷新」。所以。僅僅需要一個撤銷日誌以贊成回滾事務。這種撤銷日誌不需要儲存超過一個事務的週期。所以，「可以是一個主內存數據結構。在事務提交時被丟棄」。正如「在HA的世界。將沒有持久化的重作日誌，僅僅有一個短暫的撤銷日誌」。Stonebraker等人發現還有一個潛在的機會以去掉從重作日誌恢復的複雜代碼；但他們也認可。這種恢復邏輯僅僅是轉化爲「當失敗網站恢復執行時從執行中網站獲得最新數據的新功能」。

     無調整  最後，Stonebraker等人指出當前的RDBMS是在一個「電腦很是貴，人很是廉價的時代」被設計的。

今天偏偏相反。人員成本是一個IT公司的主要支出。他們特別批評說「RDBMS有大量複雜的

性能調整，這是舊時代的過期特性」但仍在使用。因爲RDBMS的本身主動調整輔助「不會帶來比一個熟練DBA的更好效果」。

爲代替提供這類僅僅是爲了調整而尋找更好配置的特性，Stonebraker等人需要一個數據庫。沒有這種調整僅僅有「自個人一切」（自我恢復，自我維護，自我調節等）。

關於事務，處理和環境的考慮

     探討了自上世紀70年代時設計RDBMS以來IT企業的發展歷史，以及這樣的發展對架構的影響，Stonebraker等人現在轉向其它問題。這些會對系統的性能產生不利影響：

•      重作日誌持久化必須避免，因爲它們是「差點兒保證是一個顯著的性能瓶頸」。

  在HA/故障恢復系統上面它們可以全然省略。

•      client與數據庫之間經過JDBC/ODBC接口的通訊是他們提到的下一個引發性能衰退的問題。代替這種接口，他們「提倡在數據庫系統中‘在進程內’執行應用程序邏輯，經過存儲過程的形式」。以免「傳統的數據庫客戶機/server模式所隱含的進程間開銷」。
•      他們建議進一步消除撤銷日誌。「不管實際狀況，因爲它也將是一個重要的瓶頸」。
•      解決的下一個性能瓶頸是贊成併發訪問的動態鎖。動態鎖定的成本也應下降或消除。
•      多線程的數據結構致使事務加鎖。

  假設事務的執行時間很是短，一個單線程執行模型可以消除這種閉鎖與多線程數據結構的開銷，僅僅會「在性能上有小損失」。

•      最後，兩階段提交（2PC）事務應儘量避免。因爲該協議形成的網絡傳輸回合將致使性能降低，因爲它們「一般以毫秒級的時間前後發生」。

     假設這些建議可以被知足。Stonebraker等人隨後指出基於OLTP特色的事務和大綱（schema）特性。

事務和大綱特性

     除了以上討論的硬件特性、線程模型、分佈式或可用性要求。Stonebraker等人還指出了數據庫大綱的特性以及事務屬性也顯著影響DBMS的性能。關於數據庫大綱和事務，他們以爲DBMS應該利用下面特色：

     樹形大綱  是例如如下的數據庫大綱：「每一個表除了一個叫根的節點。都有且僅僅有一個與祖先節點是1-n關係的鏈接（join）。

所以，大綱是一個1-n關係的樹」。

有此屬性的大綱。特別easy在一個網格上的節點之間分佈。「這樣所有樹中的等值鏈接跨度僅僅有一個單一的網站」。這樣的模式的根表一般由它的主鍵分區並移動到網格的其它節點，使每一個節點上有根表的分區以及其它表中該根表分區的主鍵值所相應的數據。

     受約束樹應用（CTA）    在Stonebraker等人的概念中，CTA是一個有着樹形大綱的應用程序。且僅僅運行有下列特性的事務：

     一、每一個事務類中的每一個命令都有根節點主鍵的相等謂詞

     二、「對一個網站而言，每一個事務類的每一個SQL命令是本地的」

    事務類是「一樣的SQL語句和程序邏輯的集合，僅僅有每個事務的執行時常量不一樣」。Stonebraker等人在他們的H-Store原型中預先定義了。他們進一步以爲，眼下的OLTP應用一般設計爲CTA的，或至少可以以這樣的方式將其分解，並建議系統地應用大綱變換以使應用知足CTA（[ SMA+07。頁1153 ]）。這些努力的優勢是「CTA可以頗有效地執行」。

     單網站事務  僅僅能在一個節點上運行，而不需要與DBMS網格的其它節點進行通訊。

如受約束樹應用知足這樣的屬性。

     一次性應用  全然由「可並行運行且不需要在網站中傳輸中間結果的事務」構成。此外。一次性應用中的查詢從不使用更早的查詢結果。這些屬性贊成DBMS分解事務「到一個單網站運行計劃的集合，它可以被分派到適當的網站運行」。一個普通的使應用一次性的技術是在網站間進行垂直分表。

     兩階段事務  是指這種事務：包括第一階段的讀取操做，該操做可以依據它的結果致使事務的取消，和第二階段的寫操做，該操做保證不會形成不論什麼完整性衝突。

Stonebraker等人說，很是多OLTP事務具備這種屬性。所以利用它在他們的H-Store原型中替代撤消日誌。

     強兩階段事務  在兩階段事務以外。增長了第二階段所有網站回滾或完畢事務的屬性。

     事務可交換性  由Stonebraker等人定義例如如下：「來自相同或不一樣的類的兩個併發事務可交換，僅當不管怎麼交織時單網站的子運行計劃都產生相同的終於數據庫狀態（若是兩個事務都提交）」。

     無菌事務類  是「和所有事務類（包含其自身）」可交換的事務類。

H-Store概述

     討論了數據庫管理系統設計時應考慮的參數。Stonebraker等人給出H-Store原型。在TPC-C基準中性能明顯優於商業數據庫。他們的系統草圖不在本文中反覆（具體信息可以在[ SMA+07頁154 ]）。但一些屬性應當說起：

•      H-Store執行在網格上
•      表的每一行在內存中連續存放
•      使用B樹索引
•      網站被劃分紅邏輯網站，每個相應一個CPU核
•      邏輯網站是全然獨立的，具備本身的索引、元組存儲和他們所在機器的主內存的分區
•      單線程工做。事務不可中斷
•      僅贊成執行以存儲過程實現的提早定義事務
•      省去了重作日誌並試圖儘量避免寫撤消日誌。假設撤消日誌沒法避免它在事務提交時被丟棄
•      假設可能，查詢執行計劃利用上述討論的單網站和一次性屬性
•      嘗試實現無調整和高可用性需求，以及經過「指定水平分區、複製位置、索引字段的全本身主動物理數據庫設計器」實現事務的單網站變換
•      因爲H-Store保存每個表的多個副本。需要事務地進行更新。讀命令可以去表的不論什麼副本，而更新是針對所有副本
•      H-Store利用上述事務和大綱特性進行優化，好比在兩階段事務中省略撤消日誌

TPC-C基準

     當比較他們的H-Store原型與商業DBMS，Stonebraker等人應用了一些針對基準測試實現的重要技巧。首先。他們在對數據庫大綱和它的副本分區時。使用了「分解模式。這樣每個網站都有一個源於一個獨特的倉庫分區記錄的子集」的方法。其次。他們討論怎樣利用上面討論的事務特性。假設基準將執行「在一個單核心，單CPU的機器」那麼「每一事務類會是單網站的，且每個事務可以執行在一個單線程環境」。在一個「成對HA的網站，所有的事務類都可以當成強兩階段，這意味着所有事物將在這兩個網站上成功或停止。

所以，在一個單一的成對HA的網站上。ACID特性可以沒有不論什麼開銷地實現」。經過進一步應用技巧。他們實現「使用[模式分區和複製的]基本策略並用上面描寫敘述的技巧加強，所有事物類成爲一次性的和強兩階段的。僅僅要咱們加一個短延時，ACID特性可以在無不論什麼併發控制開銷的狀況下實現。

」

     基於此設置，他們實現了比商業DBMS的性能好82倍。

他們還分析了在商業DBMS的性能開銷，發現主要是由日誌和併發控制引發的。

     聽說Stonebraker等人僅實施TPC-C基準測試的一部分，且彷佛並未調整TPC-C基準測試使之全然適合商業DBMS，就像他們爲本身的H-Store原型作的。雖然他們聘請了專業的DBA調整與H-Store對照的DBMS，並嘗試優化系統的日誌以贊成它更好地運行。

結論

     鑑於他們的分析，Stonebraker等人得出這種結論：「咱們正走向一個至少有5個（可能不少其它）專用引擎和‘一刀切’的過期系統死亡的世界」。這適用於關係模型以及它的查詢語言SQL。

     Stonebraker等人說與「DBMS世界中僅僅包括業務數據處理」的上世紀70年代相反。如今至少有下面市場需要專用DBMS：

     一、數據倉庫  一般有星形或雪花形模式。如「一箇中心事實表與周圍的維度表做1-n鏈接。並可能進一步的與第二層的維度表做1-n鏈接。等等」。這些數據可以很是easy地使用關係模型建模。但Stonebraker等人建議一個實體關係模型對建模和查詢來講將更簡單、更天然。

     二、流處理  這個市場有不一樣的需求。即「快速處理信息流[和]關聯這種流與存儲的數據」。

一個SQL的泛化稱爲StreamSQL。贊成使用SQL的FROM語法混合流和關係型數據。引起了一些熱情，並被建議看成此領域的標準。Stonebraker等人還提到在流處理中經常需要流數據是扁平的（如一些新聞機構提供的數據流），但也有層次化結構數據的需要。所以。他們「期待流處理廠商更積極地進軍層次數據模型」，「他們必定會偏離Ted Codd原則」。

     三、文本處理  是一個關係型數據庫從未被用到的領域

     四、面向天然科學的數據庫  因爲基礎數據結構的緣由更可能支持向量而不是表

     五、半結構化數據  該領域實用的數據模型仍在討論。

一些建議包含XML大綱（因爲其複雜性爭論激烈）和RDF

     「當關系模型爲‘一刀切’的世界而設計，咱們設想的各類專業系統可以讓咱們又一次思考什麼樣的數據模型將更適合他們的特定需求」，Stonebraker等總結道。

     關於DBMS查詢語言他們反對「一刀切的語言」如SQL，在他們看來，根本沒有需要SQL的用例：在OLTP市場即席查詢很是少或不需要。應用程序以預備語句方式查詢。或查詢邏輯以存儲過程形式被部署到DBMS中。與此相反，其它DBMS市場如數據倉庫需要複雜的即席查詢能力，這是SQL不能知足的。爲此，Stonebraker等人看不到還需要這種語言。

     針對上述市場中的專業DBMS。他們進一步探討怎樣將這些語言與編程語言集成。且反對「鏈接到不論什麼編程語言」的數據子語言如JDBC和ODBC作的。

「[這]致使了高開銷的接口」。Stonebraker等人所以建議「在編程語言中嵌入數據庫的功能」。

這種語言嵌入樣例包含。上世紀70年代的Pascal R和Rigel，或今天微軟在.NET平臺的LINQ方法。關於語言整合這種能力。他們喜歡他們所謂的「小語種」如Python，Perl。Ruby和PHP，他們「開放源代碼。可以經過社區改進」，此外「比眼下通用的語言（被看做編程語言世界中的一刀切的方案）更easy改動」。他們的H-Store原型中的存儲過程計劃從C++遷移到Ruby。

2.1.3 主要驅動

     在過去的幾年中NoSQL潮流吸引了大量的企業和項目。

特別執行大型和高頻站點的大網絡公司或企業已經從關係數據庫（一般有一個緩衝層典型地如memcached，參見[ Hof10c ],[ Hof10b ]）切換到非關係數據存儲。樣例包含最初由Facebook開發的Cassandra（[ Apa10d ]）且今天還被Twitter和Digg使用（[ Pop10a ]、[ Eur09 ]）。LinkedIn開發和使用的Project Voldemort，存儲雲服務如NoSQL存儲Amazon SimpleDB（[ Ama10b ]），以及Ubuntu One，一種基於CouchDB的雲存儲和同步服務（[ Can10c ]、[ Hof10c ]）。這些NoSQL數據存儲的用戶，自然地對他們使用的非關係型解決方式的進一步發展很感興趣。然而，最流行的NoSQL數據存儲所採用的思想是Google的Bigtable（[ CDG+06 ]）或Amazon的Dynamo（[ DHJ+07 ]）。Bigtable啓示的NoSQL存儲一般被稱爲列存儲（好比HyperTable，HBase），而Dynamo主要影響鍵/值存儲（如Cassandra[ Apa10d ]。Redis[ S+10 ]，Project Voldemort[ K+10a ]）。其它項目追求不一樣的嘗試，如圖形數據庫造成一類本身的數據存儲；和文件存儲。這可以被看做是具備附加功能的鍵/值存儲（至少贊成鍵/值對具備不一樣的、通常是分層的命名空間。提供了「文檔」的抽象）；後者中至少一個（CouchDB）是現有文檔存儲如上世紀90年代的Lotus Notes的又一次實現，所以沒有結合當前的網絡技術進行設計（這被CouchDB開發人員們批評，他們又從零開始實現他們的文檔存儲，參見[ Apa10c ]、[ PLL09 ]）。綜上所述，可以得出的結論是NoSQL潮流的先驅主要是大型網絡公司或執行大型站點的公司，如Facebook，Google和Amazon（[ Oba09a ]），和在這一領域的其它人經過他們的想法和改動以知足本身的需求。

2.2 批評

2.2.1 商業方面的懷疑

     在一篇計算機世界關於三藩的NoSQL見面會的文章。提到一些NoSQL數據庫的業務相關的問題。它們中的大多數都是開源軟件，被不關心許可證和商業支持問題的開發人員讚揚。

然而，特別是出問題後沒有人可責怪的狀況會嚇到商務人士。

即便在Adobe。開發人員使用Terracotta集羣替代關係數據庫，也僅僅有在讓他們的經理看到了系統啓動和執行時才幹說服他們（參見[ Com09a ]）。

2.2.2 過分宣傳的NoSQL

     一些企業開始慎重面對NoSQL，因爲這一潮流彷佛是一個炒做。潛在地缺少對承諾的履行。這是一種對新技術喚起熱情的廣泛懷疑態度。如James Bezdek在IEEE通信中表述例如如下：

     「每一個新的技術開頭老是天真愉悅，它的發明者一般淹沒在他們本身的想法中；他們最初的同僚體驗了大部分狂熱的熱情。大多數技術過分承諾，每每不是簡單地生成資金繼續這項工做，資金是科學發展的一個組成部分，除了它，僅僅有最具想象和革命性的想法使它度過胚胎階段。

炒做是過分承諾的天然伴生，大多數技術高速構建以達到炒做的頂點。以後，差點兒老是對沒有獲得充分開發的想法的過激反應，這不可避免地致使崩潰。接下去是一個時期的冷嘲熱諷。不少新技術的發展到這一點，而後消失。倖存下來的那些是因爲有人發現了一個基本思想的好應用（=真實的用戶利益）。

」（[ For10 ]引用[ Bez93 ]）

     三藩NoSQL見面會的參與者給出務實的建議：假設公司有一個關係數據庫在工做。並且不切換到NoSQL數據庫的話什麼都不會失去，那就沒有不論什麼理由來代替它。即便見面會的組織者，Last.fm的Johan Oskarsson也認可。截至2009年6月Last.fm還沒有在生產中使用NoSQL數據庫。他還指出NoSQL數據庫「眼下和主流企業不相關，但一兩年後可能會改變」（[ Com09a ]）。然而，NoSQL見面會的參與者建議假設可能的話看一下NoSQL方案，它是有意義的（好比，在開發新軟件）（[ Com09a ]）。

博主Dennis Forbes說在非關係型數據存儲的發明者和開發人員之間看不見不論什麼過分熱情（「他們大部分是聰明的。務實的開發人員」），但使用這些技術開發人員卻但願「這個潮流解決他們的弱點」。

他——一個爲金融、保險、電信、電力等行業作傳統的關係數據庫開發——卻說「無疑是很是多奇異的工做發生的NoSQL陣營中，很是關注可伸縮性」。

還有一方面。在他博客的評論中批評說：「爭論的是。聚會的自己。被正在或但願創建很是大的網絡公司的人劫持了（都但願成爲下一個Facebook）。該領域的價值觀和推斷投射到整個數據庫產業——其包含一系列使社交媒體的邊緣樣例也相形見絀的解決方式——這真是諷刺」（[ For10 ]）。（注：不懂，好像是在罵人）

2.2.3 NoSQL沒有什麼創新

     相似於炒做的論點。對NoSQL的還有一種批評是。NoSQL數據庫沒什麼創新因爲其它嘗試如對象數據庫已經存在了幾十年。做爲這個爭論的樣例，博主David Intersimone提到Lotus Notes可以納入早期的文檔存儲，且支持分佈和複製而有利於併發控制的性能（除非另有說明，[ Int10 ]）。一個特別有意思的樣例是，CouchDB的主要開發人員，Damien Katz，曾爲Lotus Notes工做幾年。

NoSQL的擁護者以爲CouchDB是「Notes的成功」。因爲Notes的分佈特徵並無利用當前的網絡技術，軟件自己也不是一個精幹的數據存儲而是因業務相關的特性而臃腫（[ PLL09 ]）。

     好比Lotus Notes。商業分析或面向流處理的數據存儲顯示，這類關係數據庫的替代品已經存在了很是長的時間。博主Dennis Forbes所以批評，「一刀切」的說法僅僅只是是一些人的擋箭牌，因爲他們僅僅使用過RDBMS做爲處理所有的結構化和非結構化數據存儲需求的工具（[ For10 ]）。

2.2.4 NoSQL表明全然的「沒有SQL」

     首先，很是多NoSQL的主張特別是在博客上的。將這個術語和潮流看做RDBMS的全然否認和這些系統的死亡宣告。「NoSQL」術語一般與Eric Evans聯繫在一塊兒，儘管他不是第一個用它（見2.1節，如[ Ell09a ]）。2009年的一篇博客以爲。現在這個詞的意思是「不該僅僅有SQL（Not Only SQL）」而不是「沒有SQL」（[ Eva09b ]）。這個詞已經被不少博客做者所採納。因爲它強調了數據庫中的持久性不意味着僅僅能使用RDBMS而是有替代品存在。

博主Nati Shalom評論例如如下：「我以爲咱們所示是不少其它的一種現實，現有的SQL數據庫方案可能不會很是快消失，但同一時候他們不能解決世界上所有的問題。

有趣的是，NoSQL這個詞已經變爲Not Only SQL，以表明這一思路」（[ Sha09a ]）。一些博主強調這個詞語不精確。如Dare Obasanjo說，「尚未什麼產品是‘NoSQL’數據庫的確切技術定義，當其實它不是一個關係數據庫」（[ Oba09a ]）。其它人。如Michael Stonebraker聲稱。根本和SQL沒半毛錢關係，應該叫「NoACID」之類，這是由Dennis Forbes提出的並在他的建議裏引用了Stonebraker（[ For10 ]）。另外一些人如Adam Keys批評術語「NoSQL」僅僅定義了它不表明什麼趨勢（[ Key09 ]）：「這個名字的問題是，它僅僅定義了它不是什麼。這使得它是對抗性的，它所包括或排除的東西不使人吃驚。咱們看到的是，它終結了有價值的數據應該保存在某種關係數據庫的若是。終結了SQL和ACID是解決咱們問題的惟一工具的若是。終結了主/從模式的活力；終結了在咱們的應用程序代碼裏編織關係模式」。他建議把這樣的潮流和數據存儲納入「後關係型」而不是「NoSQL」：「咱們看到關於應怎樣存儲關鍵數據的思惟爆炸；咱們審視數據來看是否值得持久化；咱們嘗試新的語義結構、一致性和併發性。如同後現代主義是反思過去的藝術和建築的方式，後關係型是軟件開發商又一次考慮本身方式的一個機會。正如後現代主義並不是否能定整個藝術史，後關係型不會終結關係數據庫的有用性。」（[ Key09 ]）。然而。像他博客的讀者評論的，這個詞並不比「NoSQL」更好，因爲它仍僅僅是定義這個潮流和這種數據庫不反映（或更好的：他們所省略）的東西。而不是它們主張什麼。

     對這個詞的刺激和做爲關係數據庫的忽視部分的第一觀念，已經帶來了NoSQL支持者們不少發人深省的語句。並形成一些無益的討論和一些激烈爭論（好比[ Dzi10 ]和它的響應[ Sch10 ]）。

2.2.5 Stonebraker對NoSQL數據庫的關鍵觀點

     在他的博文「‘NoSQL’討論與SQL無關」（[Sto09]）中，Michael Stonebraker說最近已有大量對NoSQL數據庫的討論。在他的觀點裏美國的NoSQL研討背後的驅動力是文檔存儲和鍵/值存儲的倡導者，在他眼中它們提供「低層、一次一條記錄的DBMS接口。以代替SQL」。Stonebraker看到兩個走向非關係數據存儲的緣由——靈活性和性能。

     靈活性的爭論  Stonebraker未進一步研究，但它包括下列觀點：可能有這種數據。其不符合剛性的關係模型，且和RDBMS的結構緊密綁定。對於這種數據更靈活是必要的。

     性能的爭論  Stonebraker描寫敘述例如如下：起先使用MySQL存儲數據但性能隨時間降低。

這致使了下面選擇：要麼在應用程序中對多個網站上的數據碎片/分區致使「管理分佈式數據的嚴重問題」。或從MySQL走向商業RDBMS可引發大的許可費；或甚至全然放棄RDBMS。

     Stonebraker在他的博客中研究了後者。他針對「NoSQL數據庫最一般考慮的負載：更新和查詢密集型的OLTP負載，不是查詢密集型的數據倉庫負載」，或專業的負載如文檔知識庫。

     Stonebraker看到兩個選項提升OLTP事務的性能：

     一、「無共享處理環境」上的本身主動分片實現的水平縮放。在這樣的狀況下。性能因添加新的節點獲得改善。在他看來。在過去的十年裏寫的RDBMS提供了「無共享的架構」。「沒有人應該執行不提供這個功能的DBMS」。

     二、單點OLTP性能的改進

    Stonebraker集中在第二項，分析減小單點OLTP事務性能開銷的來源；他的博客文章的標題代表。這些都和查詢語言（SQL）無關。他說，僅僅有一小部分的事務消耗是由實用的工做引發的。並看到五個性能開銷的來源，單節點性能應優化應據此進行：

     通訊  應用和DBMS間經過ODBC或JDBC進行的通訊。這被以爲是OLTP事務開銷的主要來源，一般例如如下描寫敘述：「基本上所有性能敏感的應用程序使用存儲過程接口來執行DBMS內的應用程序邏輯。避免了應用與DBMS之間來回通訊的沉重的開銷」。

爲了下降通訊開銷的還有一個選擇是使用一個嵌入式DBMS。指的是應用程序和DBMS在同一地址空間中執行；因爲強耦合。安全性和訪問控制問題對「安全是一個大問題的主流OLTP」沒有可行的替代。Stonebrakers以爲。

     日誌  每個事務除改動關係型數據外由DBMS負責記錄日誌。

由於日誌文件被保存到磁盤以確保持久性，日誌是昂貴的且會減小事務性能。

     加鎖  數據集的加鎖操做會致使開銷，因爲加鎖表的寫操做僅僅能在事務改動操做以前或以後才幹發生。

     閂鎖  因爲RDBMS中共享的數據結構（如B樹、鎖表、資源表）進一步添加事務開銷。

這些數據結構都是由多個線程訪問短時間鎖（稱爲閂鎖）通常用於提供並行的但慎重的訪問。

     緩存管理  當討論事務開銷時緩存管理也有其責任。因傳統RDBMS中的數據以固定頁的方式組織。必須管理內存中的磁盤頁面緩存（經過緩衝池完畢）。並解決數據庫條目寫到磁盤頁（和返回）以及識別字段邊界的問題。

     如前所述。依據Stonebraker，通訊是開銷的主要來源，並遠超過其它的項目（從這個調查：[ HAMS08 ]），其它項目近似相等地添加總事務成本。除了避免應用程序和數據庫之間的通訊，其它四個性能開銷的來源必須消除。以大大提升單節點性能。

     現在。無論是不是關係型的數據存儲一般都有特定的主題。NoSQL數據庫也需要找出上述性能開銷的組成部分。在這種背景下，Stonebraker提出如下的樣例：

•      在多個網站之間數據分佈且無共享的方法在關係型以及非關係型數據存儲中都提供了。

  「顯然，一個精心設計的多網站系統。無論是否基於SQL或其它，都比單網站系統更具可擴展性」，據Stonebraker說。

•      不少NoSQL數據庫是基於磁盤的。實現一個緩衝池和多線程。當提供這些特性和性能時，四個性能開銷來源中的兩個仍然存在（鎖定。緩存管理）。不能被消除。
•      很是多智能事務的NoSQL數據存儲僅僅提供帶BASE屬性（見第3章）的單記錄事務。與關係型DBMS相反，ACID屬性爲性能而犧牲。

     因而Stonebraker總結他的觀點例如如下：「然而。一個NoSQL、基於磁盤、非ACID、多線程系統的單節點性能被限制爲比設計良好的存儲過程SQL的OLTP引擎略快。 本質上，ACID事務因適度的性能提高而被拋棄，且這種性能提高與SQL無關」。

在他的觀點中，加速DBMS的實際任務集中於消除加鎖、閂鎖、日誌和緩衝區管理。以及支持存儲過程從高級語言（如SQL）編譯爲低級語言。這種系統的樣子在論文「架構時代的終結：是全然重寫的時候了」（[SMA+07]）中被闡述並已經在上文討論了。

     Stonebraker也不期望 SQL數據存儲的死，而是說：「我全然期待快速度的、開源的SQL引擎在不久的未來提供本身主動分片。此外，他們將繼續提供ACID事務以提升程序猿的工做效率，減小維護成本，以及由SQL支持的更好的數據獨立性」。所以「高性能不需要拋棄SQL或ACID事務」。這也「取決於消除由傳統的ACID事務、多線程管理、磁盤管理帶來的開銷」。消除這些開銷的來源「在SQL上下文或其它上下文環境中都是可能的」。Stonebraker總結。

2.2.6 運維和操做人員的需求

     Schmidt在他的博客「NoSQL」的黑暗面（[ Sch09 ]）中以爲，NoSQL的辯論被開發人員的觀點主宰。其一般反覆着開發人員喜歡的特性和能力（如性能、用途、無模式、好的API），而操做人員和系統管理員的需求一般被遺忘在他的視線中。他報道了一些公司遇到困難特別是在下面領域：

     即席數據修復  要贊成對即席數據修復。首先必須有某種查詢和操做語言。其次，在分佈式數據庫（如Project Voldemort和Cassandra）中更難以修復數據，與在一個節點上執行或有專門分片的數據存儲相比。

     即席數據查詢  與數據修復類似。當遇到即席查詢時針對特定數據存儲的查詢和操做是必須的，和查詢集中式存儲相比查詢分佈式數據存儲更難。

Schmidt指出，對一些報表任務來講MapReduce方法（[ DG04 ]）是合適的，但不是對每一個即席查詢。此外，他看到的是文化而不是技術問題。客戶已經被培訓和「上癮」使用即席查詢。於是不喜歡這些手段的缺失。針對詳盡報表的需求。Schmidt建議使用鏡像了線上庫的關係型數據庫，而線上庫可能因爲性能和可擴展性要求而使用NoSQL存儲。

     數據導出  Schmidt指出，這方面NoSQL數據庫之間有巨大差別。一些提供了實用的API來訪問所有的數據。還有一些中則不存在。他也指出。從非分佈式NoSQL存儲像CouchDB，MongoDB或Tokyo Tyant中導出數據，要比從分佈式的如Project Voldemort或Cassandra中導出數據更easy。

     Schmidt的觀點在討論「你的NoSQL指南」（[ Ake09 ]）中被幽默和普遍地反覆。特別是惡搞了NoSQL支持者的用MapReduce風格處理每個查詢需求的論點。

2.2.7 性能 vs. 可擴展性

     BJ Clark介紹了一個在各類NoSQL數據庫和MySQL間的性能和可擴展性實驗。發表在他的博客「NoSQL：假設它是那麼easy」。首先，他定義可擴展性爲「在保持比例的前提下改變大小，在計算機學科中這一般意味着添加吞吐量。」博主Dennis Forbes容許這一可擴展性的概念，「務實地衡量一個解決方式的能力，其以可實現的方式增加到一個最高的現實水平。同一時候保持可接受的服務水平」（[ For10 ]）。

BJ Clark繼續說：「擴展不是：性能。在現實中，擴展和變快沒有什麼關係。它僅僅與大小有關。現在。擴展和性能典型地如此聯繫到一塊兒，假設什麼是高效的，它實際上可能不需要擴展。」（[ Cla09 ]）。

     對於關係數據庫Clark指出：「RDBMS的問題不是他們不擴展，是他們很是難以規模。

分片是最明顯的擴展方式，但分片多個能訪問隨意列的表會很是快令人崩潰。」博主Dennis Forbes容許他。「有一些老派的關係數據庫確實有擴展性問題」（[ For10 ]），但使用如Adam Wiggins的技術仍是有可能讓它們擴展的（[ Wig09 ]）。

     除了關係數據庫的分片和典型錯誤的迴避（如死板的規格化和不良索引致使的昂貴的鏈接），Forbes以爲垂直縮放仍然是一種選擇，它很是easy且計算上有效，且能遠遠率先於「成隊的強力核心，數百GB的內存，在成堆的SSD組成的SAN陣列上操做」。缺點是，Forbes也認可垂直縮放相對昂貴。

但Forbes也主張關係數據庫經過數據分區和將每臺機器增長失敗恢復集羣實現的水平縮放。以達到冗餘和可用性。考慮到約束很是少且錢一般不是問題的大公司的部署狀況。他以本身的經驗說，「這樣的擴展存在於差點兒所有的銀行、交易系統、能源平臺、零售系統等等。要聲稱SQL系統不能擴展，是對這樣明顯的證據的蔑視，無視所有的理由」（[ For10 ]）。Forbes主張使用本身的server。因爲他看到一些雲計算環境的人爲限制，如單一實例的Amazon EC2的IO限制和相對高費用；他以爲「這些金融和人爲限制解釋了對贊成你螺旋上升的技術的強烈興趣」（[ For10 ]）。

     BJ Clark在他的博客上發表對一些NoSQL數據存儲的評價，該評價關注於本身主動可擴展性（好比經過本身主動分片），因爲他需要更新數百萬個對象（他稱他們爲主要對象）與其它對象（他稱他們爲輔助對象）是1:1或1:N的依賴關係。輔助對象大可能是在表的結尾處插入。

     他的評價可以歸納例如如下：

•      鍵/值對存儲Tokyo Tyant/Cabinet和Redis不提供本身主動水平伸縮的特性。假設加入機器——相似memcached——必須讓應用知道。而後在數據庫server羣中對數據庫條目（重）哈希，以利用額外的資源。還有一方面他指出，Tokyo Tyant/Cabinet和Redis的表現很是好，橫向擴展的需要不會很是早出現。

•      分佈式鍵/值存儲Project Voldemort本身主動地利用新加入集羣的server並提供故障容錯。鑑於它專一於分片和故障容錯且有一個可插拔的存儲架構，Tokyo Tyant/Cabinet或Redis可以做爲Voldemort的存儲後端。假設這些系統需要擴展的話，這也是一個可能的遷移路徑。
•      文檔數據庫MongoDB表現出良好的性能特色。但在評價時沒有本身主動縮放能力，因爲它沒有提供本身主動分片（在2010年8月的1.6版中已經改變，參見[ Mon10 ]和[ MHC+10b ]）。

•      對於列數據庫Cassandra，Clark以爲它是「絕相應該，且可能在Facebook，是經過簡單地加入還有一臺機器來擴展的（節點間互相掛鉤使用Gossip協議），但OSS版本號不支持一些關鍵的東西，像一塊兒釋放一臺機器「。

  這一結論反映了Cassandra評價時的發展情況。

•      Amazon的鍵/值對存儲S3擴展良好。但據Clark說，它不如其它候選者那樣高性能。

•      MySQL，相比較而言，並不提供本身主動橫向擴展如本身主動分片，但Clark指出。對於大多數應用（甚至是Web應用如Friendfeed，參見[ Tay09 ]）MySQL足夠快。並且是「熟悉的、無處不在的」。

  與Tokyo Tyant/Cabinet和Redis相比，Clark以爲「它可以作Tokyo Tyant和Redis可以作的一切。且真的是沒有那麼慢。其實，對於某些數據集。我見過MySQL比Tokyo Tyant運行地快得多」和「對MySQL分片與Tokyo Tyant和Redis同樣easy甚至更easy，很是難說他們可以在更多問題上贏得勝利。」

     在上述評價中所提到的系統將在本文中更具體地討論。

此外必須提到的是，評估發生在2009的夏天（博客是8月發表），所以，結果反映了被評價系統在那個時候的發展狀態。

     Clark總結了他的研究結果。在他看來RDBMS不比「其餘很是多東西」更難擴展，NoSQL數據庫提供的僅有的一些手段有是本身主動的、水平可擴展性、贊成不需要操做員交互下加入機器。

所以。甚至可以以爲「擴展MySQL（經過MySQL Proxy來分片）和爲這些NoSQL數據庫作分片相同easy。」所以他沒有宣佈RDBMS早早死亡。提醒道MySQL仍然是在大站點如Facebook，Wikipedia和FriendFeed中使用。他建議新的應用程序使用最適合工做的工具，反映了非關係型數據庫——就像關係型的同樣——沒有「一刀切」的解決方式：

     「假設我需要報表，我不會使用不論什麼NoSQL。假設我需要緩存，我很是可能會使用Tokyo Tyant。

假設我需要ACID特性，我不會使用NoSQL。假設我需要一噸值對，我會使用Redis。假設我需要事務，我會使用Postgres。假設我有一噸單一類型的文件，我可能會使用Mongo。假設我需要天天寫10億個對象，我可能會使用Voldemort。假設我需要全文搜索。我可能會使用Solr。

假設我需要易變數據的全文搜索，我可能會使用Sphinx。」

2.2.8 不是所有RDBMS表現得像MySQL

     NoSQL的辯論中經常發現的爭議是RDBMS很是難良好擴展且很是難分片。這通常是經過MySQL的樣例指出。

此外，NoSQL數據庫有時被看做MySQL加memcached方案的繼任者（好比[ Hof10c ]），後者將負載從數據庫帶走以下降和延緩分佈式的需求。關於這些典型爭論博主Dennis Forbes提醒。不easy區分通常的RDBMS和MySQL，其餘數據庫可能更easy或更好地擴展：「MySQL不是RDBMS世界的先鋒。它在高負載站點下的問題和關注很是少與其餘數據庫系統相關」（[ For10 ]）。

2.2.9 批評的誤解

     NoSQL倡導者Ben Scofield回答了一些上面提到的批評。他以爲是被誤解了。他在NoSQL爭論中表達的一些精闢論點回答了這些批評（[ Sco09 ]）：

     「NoSQL僅僅是可擴展性和/或性能。」  Scofield以爲，這對那些「傳統主義者」（他這樣稱呼他們）多是一個有吸引力的觀點，以爲僅僅要讓RDBMS更快和更具可擴展性就能使NoSQL數據存儲過期。他聲稱「NoSQL除了性能和擴展外還有不少其它」，好比「NoSQL數據庫一般爲業務域建模提供更好的基礎」。

     「NoSQL僅僅是文檔數據庫。或鍵值存儲，或……」  Scofield指出。不少NoSQL文章僅僅介紹面向文件的數據庫或鍵值存儲。有時提到列存儲。

他指出「對特定狀況下的每一個解決方式都可以提出好的討論，但上述那些僅僅是討論某一特定類型的存儲引擎。」Scofield所以批評，將討論範圍縮小到僅僅有一類NoSQL數據庫，會使得傳統主義者很是easy地否認整個潮流或全套不一樣的NoSQL方法。

     「我在NoSQL能作的在關係數據庫中同樣能。

」  考慮到Friendfeed使用MySQL的頻繁爭論（[ Tay09 ]）。Scofield指出，雖然微調一個關係型數據庫是可能的。但這對所有類型的數據沒有意義。「不一樣的應用適合不一樣的事情。關係數據庫對關係數據是偉大的，但對非關係數據爲何要使用他們？」他問道。

     「NoSQL是一個關係數據庫的普遍排斥。」  前一段時間這樣的說法在NoSQL社區經常被聽到，後來成了不常見的。Scofield觀賞：「看來咱們正在走向一個多元化的方法來儲存咱們的數據，這是一件好事。我已經爲這樣的作法提出了’多語言持久化’（儘管我沒有杜撰一個術語）。但我也喜歡如Ezra Zygmuntowicz的’LessSQL'做爲標籤。」

2.3 NoSQL數據庫的分類和比較

     在過去的幾年裏。各類NoSQL數據庫主要由從業人員和網絡公司開發，以知足他們對可擴展性的性能、維護和功能集的詳細需求。

已經透露的是這些數據庫中的一些借鑑了Amazon的Dynamo（[DHJ+07 ]）或Google的Bigtable（[ CDG+06 ]）或二者的思想。

其它一些移植了針對現代網絡技術開發的現有數據庫的思想如CouchDB。另外一些人追求全然不一樣的方案如Neo4j或HypergraphDB。

     因爲各類不一樣的方法、重疊的非功能性需求、不一樣的功能集。可能很是難得到和維護一個非關係型數據庫狀況的概述。因此有各類不一樣的方法對NoSQL數據庫分門別類，每種都有不一樣的類別和子類別。這裏介紹一些分類方法。應當用哪個對NoSQL數據存儲分類將在興許的章節介紹。

2.3.1 按數據模型的分類法

     關於NoSQL存儲伸縮性的分類法，做者Todd Hoff引用了一個Stephen Yen在他的博文「NoSQL分類法的贊同」中的演示文稿（[ Hof09c ]）。在演示文稿「NoSQL是一個沒有馬的馬車」（[ Yen09 ]）中Yen建議的分類法可以在表2.1中找到。

詞彙	符合的數據庫
Key-Value-Cache	Memcached Repcached Coherence Infinispan EXtreme Scale Jboss Cache Velocity Terracoqa
Key-Value-Store	keyspace Flare Schema Free RAMCloud
Eventually-Consistent Key-Value- Store	Dynamo Voldemort Dynomite SubRecord Mo8onDb Dovetaildb
Ordered-Key-Value-Store	Tokyo Tyrant Lightcloud NMDB Luxio MemcacheDB Actord
Data-Structures Server	Redis
Tuple Store	Gigaspaces Coord Apache River
Object Database	ZopeDB DB4O Shoal
Document Store	CouchDB Mongo Jackrabbit XML Databases ThruDB CloudKit Perservere Riak Basho Scalaris
Wide Columnar Store	Bigtable Hbase Cassandra Hypertable KAI OpenNeptune Qbase KDI

表2.1：分類——Stephen Yen的NoSQL分類法（[Yen09]）

     一個相似的分類法，比上面的分類法更粗粒度和易理解。可以在文章「雲數據庫」（[ Nor09 ]）中找到。

表2.2總結了他的數據倉庫分類，另外包含一些僅僅在雲計算環境中可用的數據存儲。

歸類	符合的數據庫
Distributed Hash Table, Key-Value Data Stores	memcached MemcacheDB Project Voldemort Scalaris Tokyo Cabinet
Entity-Attribute-Value Datastores	Amazon SimpleDB Google AppEngine datastore Microsoft SQL Data Services Google Bigtable Hadoop HyperTable HBase
Amazon Platform	Amazon SimpleDB
Document Stores, Column Stores	Sybase IQ Vertica Analytic Database Apache CouchDB

表2.2：分類——Ken North的歸類（[Nor09]）

     與上面的分類法相似。Rick Cattel主要按數據模型將不一樣的NoSQL數據庫分類。見表2.3。

歸類	符合的數據庫
Key-value Stores	Redis Scalaris Tokyo Tyrant Voldemort Riak
Document Stores	SimpleDB CouchDB MongoDB Terrastore
Extensible Record Stores	Bigtable HBase HyperTable Cassandra

表2.3：分類——Rick Cattel的歸類（[Cat10]）

2.3.2 Ben Scofield的歸類

     博主Alex Popescu總結了由Ben Scofield給出的一份演示文稿。該文稿給出了NoSQL數據庫一個通用的帶分類法的介紹，以及不一樣NoSQL數據庫的Ruby樣例（[ Sco10 ]）。

這一分類法其實是一個簡短的NoSQL數據庫非功能類型（「稱爲ities」）的比較，外加功能覆蓋率的評分。

Popescu總結了Scofield的思想。如表2.4。

	性能	擴展性	靈活性	複雜性	功能性
Key-Value Stores	high	high	high	none	variable (none)
Column stores	high	high	moderate	low	minimal
Document stores	high	variable (high)	high	low	variable (low)
Graph databases	variable	variable	high	high	graph theory
Relational databases	variable	variable	low	moderate	relational algebra

表2.4:分類——Scofield和Popescu的分類法及比較（[Pop10b], [Sco10]）

2.3.3 可擴展性、數據和查詢模型、持久化設計的比較

     在博客「NoSQL生態系統」中Jonathan Ellis討論了NoSQL數據存儲的三個重要方面：

     一、可擴展性

     二、數據和查詢模型

     三、持久化設計

可擴展性

     Ellis以爲，經過數據副本和這些副本上的負載分佈很是easy實現讀操做的可擴展。

所以，他僅僅研究真正分佈式和提供本身主動數據分區的數據庫的寫操做擴展。

當數據大小超過單一機器的能力時，假設不肯意手動分區的話後者系統彷佛是他惟一的選擇（這不是一個好主意，依據[ Oba09b ]）。對於相關的提供本身主動分片的分佈式系統，Ellis看到兩個重要特色：

•      支持多數據中心
•      加入機器到現有羣集的可能性，對使用該羣集的應用程序透明

     依據這些特色Ellis比較了一些實現這些要求的真分佈式和本身主動分片的NoSQL數據庫（參見表2.5）。

數據存儲	在線加入機器	多數據中心支持
Cassandra	X	X
HBase	X
Riak	X
Scalaris	X
Voldemort		Some code required

表2.5:分類——擴展性對照（[Ell09a]）

     下面的NoSQL存儲已被排除在這樣的比較外，因爲他們在分佈式上不知足Ellis的要求（在2009年11月他公佈博客的時間）：CouchDB。MongoDB。Neo4j，Redis和Tokyo Cabinet。然而據他說，這些系統可以做爲一個分佈式系統的持久層使用。文檔數據庫MongoDB和CouchDB支持有限的本身主動分片，在他調查的時間（MongoDB開箱，CouchDB經過劃分／聚類框架Lounge）。關於Tokyo Cabinet，Ellis說它可以用做Project Voldemort的存儲後端。

數據和查詢模型

     Ellis研究的第二個領域是數據模型和不一樣的NoSQL存儲提供的查詢API。

表2.6顯示了他的調查結果，指出了各類數據模型和查詢APIs的巨大區別。

數據存儲	數據模型	查詢API
Cassandra	Columnfamily	Thrift
CouchDB	Document	map/reduce views
HBase	Columnfamily	Thrift, REST
MongoDB	Document	Cursor
Neo4j	Graph	Graph
Redis	Collection	Collection
Riak	Document	Nested hashes
Scalaris	Key/value	get/put
Tokyo Cabinet	Key/value	get/put
Voldemort	Key/value	get/put

表2.6：分類——數據模型和查詢API的比較（[Ell09a]）

     Ellis對這些系統的數據模型和查詢API進行了下面評論：

•      Columnfamily模型，由Cassandra和HBase實現，是由Google的Bigtable論文第二節的相關段落獲得啓示（[ CDG+06，2頁]）。Cassandra與HBase相檢討略了歷史版本號，引入了超列的進一步概念。在Cassandra和HBase裏列是稀疏的，這意味着他們可能有不一樣數量的單元。且列沒必要預先定義。

•      鍵/值模型是最easy實現的，但多是低效的，假設一我的僅僅對請求或更新與某個鍵相關的部分值感興趣。此外。在鍵/值存儲上很是難構建複雜的數據結構（正如Ellis在還有一篇博客中描寫敘述的。參見[ Ell09b ]）。
•      Ellis將文檔數據庫看作是鍵/值存儲的下一步，因爲它們贊成嵌套的值。他們贊成比鍵/值存儲更效率地查詢數據結構，因爲當他們請求一個鍵時不需要返回整個BLOB值。
•      圖數據庫Neo4j具備獨特的數據模型。因對象及其關係被做爲一個圖的節點和邊來建模和持久化。適合此模型的查詢可能比其餘數據存儲上一樣的查詢快三個數量級（由Emil Eifrem。Neo4j背後公司的首席運行官，參見[ Eif09 ]）。
•      Scalaris在所評價的鍵/值存儲中是獨一無二的，因爲它贊成多個鍵上的分佈式事務。

持久化設計

     Ellis對照他所選的NoSQL數據存儲的第三方面，是他們儲存數據的方式（見表2.7）。

數據存儲	持久化設計
Cassandra	Memtable / SSTable
CouchDB	Append-only B-tree
HBase	Memtable / SSTable on HDFS
MongoDB	B-tree
Neo4j	On-disk linked lists
Redis	In-memory with background snapshots
Riak	?
Scalaris	In-memory only
Tokyo Cabinet	Hash or B-tree
Voldemort	Pluggable (primarily BDB MySQL)

表2.7:分類——持久化設計的比較（[Ell09a]）

     Ellis以爲持久化設計對預計何種負載下這些數據庫會表現得好是特別重要的：

     內存數據庫很快（如Redis可在單機達到每秒100000次操做），但數據的大小天生的受RAM限制大小。還有一個缺點是耐久性可能成爲一個問題，因爲潛在地大量數據可能在兩次磁盤寫中間丟失（好比因爲server崩潰或掉電）。

Scalaris經過複製解決問題——但它不支持多個數據中心——掉電的威脅依舊存在。

     內存表和SSTables以例如如下方式工做：在寫入一個僅僅能追加的提交日誌以確保耐久性後，寫操做在內存中緩存（在內存表內）。通過必定數量的寫，內存表做爲一個整體被刷新到磁盤（這時被稱爲SSTable；這些想法都來自Google的Bigtable論文，參見[ CDG+06，5.3和5.4節 ]）。

這一持久化策略具備與內存數據庫相媲美的性能特色（因爲——與基於磁盤的策略相比——因爲追加日誌和將整個內存表寫回磁盤減少了尋道時間），且避免了純內存數據庫的耐久性問題。

     B樹因爲能提供一個強大的索引支持已在數據庫中使用。他們在磁盤上的性能特性不是很是正面，緣由是讀寫操做所需的大量尋道。文檔數據庫CouchDB內部使用B樹。但經過僅僅追加到B樹試圖避免尋道的開銷，這意味着一次僅僅能有一個寫操做的缺點，因爲這樣的狀況下併發讀B樹的不一樣段是不一樣意的。

基於用戶需要的分類法

     Todd Hoff（[Hof09b]）引用博主James Hamilton提供了一種不一樣的劃分NoSQL數據庫的方法（[Ham09]），依據用戶需求劃分數據庫：

     特性第一  這一類的數據庫提供了一個（大）量的高層次的特性。使 程序猿的工做更easy。不足之處是他們很是難擴展。樣例包含：Oracle，Microsoft SQL Server，IBM DB2，MySQL，PostgreSQL，Amazon RDS。

     擴展第一  這樣的類型的數據庫從一開始就需要擴展。

不足之處是，他們缺少特定的特性且把責任還給程序猿。樣例包含：Project Voldemort，Ringo。Amazon SimpleDB，Kai，Dynamite，Yahoo PNUTS，ThruDB。Hypertable，CouchDB。Cassandra，MemcacheDB。

     簡單結構存儲  這個類包括鍵/值對存儲。強調存儲和檢索隨意結構的集合。依據Hamilton他們的缺點是「一般不具備其它系統的功能或可擴展性」。

樣例包括：文件系統，Cassandra，BerkelyDB。Amazon SimpleDB。

     特定目的優化的存儲  這些數據庫被設計和建造以擅長作一件事，如數據倉庫或流處理。這種數據庫的樣例有：StreamBase。Vertica，VoltDB。Aster Data。Netezza，Greenplum。

     Hamilton和Hoff以爲。這樣的分類法對將一類數據庫和特定用例匹配是實用的。儘管這樣的分類是不完整的。如不包括圖數據庫，且怎樣符合上述四類是不明白的。

此外。重要的是要注意。一些數據庫可以在不一樣的類中找到（Cassandra。SimpleDB），所以這樣的分類不提供一個肯定的差異使每個數據庫僅僅納入一個類（這——在做者看來——在NoSQL數據庫領域即便不是不可能至少也很是困難）。

2.3.4 本文的分類法

     考慮基本概念和下一章中的NoSQL數據庫技術後。接下去的章節將研究各類類別的非關係型數據存儲。並審視特定的產品。

這些產品以他們的數據結構來分類。追隨上面所提到的Yen，North和Cattell的分類法（參見2.3.1），這也被本文的其它多數資料來源共享。在這篇文章中使用的分類是：鍵/值存儲、文檔數據庫和麪向列的數據庫。