獨家｜一文讀懂非關係型數據庫（NoSQL）

本文共11000字，閱讀全文約需30分鐘。

本文為大家解析非關係型數據庫（NoSQL）。

前言

NoSQL(NoSQL = Not Only SQL )，意即"不僅僅是SQL"。

現代計算系統每天在網絡上都會產生龐大的數據量。這些數據有很大一部分是由關係型數據庫管理系統（RDBMSs）來處理，其嚴謹成熟的數學理論基礎使得數據建模和應用程序編程更加簡單。

但隨著信息化的浪潮和互聯網的興起，傳統的RDBMS在一些業務上開始出現問題。首先，對數據庫存儲的容量要求越來越高，單機無法滿足需求，很多時候需要用集群來解決問題，而RDBMS由於要支持join，union等操作，一般不支持分佈式集群。其次，在大數據大行其道的今天，很多的數據都“頻繁讀和增加，不頻繁修改”，而RDBMS對所有操作一視同仁，這就帶來了優化的空間。另外，互聯網時代業務的不確定性導致數據庫的存儲模式也需要頻繁變更，不自由的存儲模式增大了運維的複雜性和擴展的難度。

NoSQL 是一項全新的數據庫革命性運動，早期就有人提出，發展至2009年趨勢越發高漲。這類數據庫主要有這些特點：非關係型的、分佈式的、開源的、水平可擴展的。最初的目的是為了大規模web 應用。NoSQL 的擁護者們提倡運用非關係型的數據存儲，通常的應用如下特點：模式自由、支持簡易複製、簡單的API、最終的一致性（非ACID）、大容量數據等。

筆者是MongoDB用戶，也使用過Redis。關係型數據庫使用過MySQL與Oracle，對兩者的區別有一定的體會。Mongo和Redis的操作都非常簡單，速度很快，很多用SQL需要很多條語句的操作在NoSQL數據庫中都是2句以內完成。另外NoSQL配置cluster也很容易，且可以隨時更改partition和replication的數量，Mongo的新版本還內置了MapReduce操作，使其有了做大數據分析的能力。

NoSQL理論基礎

1.關係型數據庫理論 - ACID

ACID，是指數據庫管理系統（DBMS）在寫入或更新資料的過程中，為保證事務（transaction）是正確可靠的，所必須具備的四個特性：原子性（atomicity，或稱不可分割性）、一致性（consistency）、隔離性（isolation，又稱獨立性）、持久性（durability）。

• A – Atomicity – 原子性

一個事務（transaction）中的所有操作，要麼全部完成，要麼全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有被執行過一樣。

• C – Consistency – 一致性

在事務開始之前和事務結束以後，數據庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設規則，這包含資料的精確度、串聯性以及後續數據庫可以自發性地完成預定的工作。

• I – Isolation – 隔離性

數據庫允許多個併發事務同時對其數據進行讀寫和修改的能力，隔離性可以防止多個事務併發執行時由於交叉執行而導致數據的不一致。事務隔離分為不同級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重複讀（repeatable read）和串行化（Serializable）。

• D – Durability – 持久性

事務處理結束後，對數據的修改就是永久的，即便系統故障也不會丟失。

關係型數據庫嚴格遵循ACID理論。但當數據庫要開始滿足橫向擴展、高可用、模式自由等需求時，需要對ACID理論進行取捨，不能嚴格遵循ACID。以CAP理論和BASE理論為基礎的NoSQL數據庫開始出現。

2.分佈式系統理論

2.1 分佈式系統介紹

分佈式系統的核心理念是讓多臺服務器協同工作，完成單臺服務器無法處理的任務，尤其是高併發或者大數據量的任務。分佈式是NoSQL數據庫的必要條件。

分佈式系統由獨立的服務器通過網絡鬆散耦合組成的。每個服務器都是一臺獨立的PC機，服務器之間通過內部網絡連接，內部網絡速度一般比較快。因為分佈式集群裡的服務器是通過內部網絡鬆散耦合，各節點之間的通訊有一定的網絡開銷，因此分佈式系統在設計上儘可能減少節點間通訊。此外，因為網絡傳輸瓶頸，單個節點的性能高低對分佈式系統整體性能影響不大。比如，對分佈式應用來說，採用不同編程語言開發帶來的單個應用服務的性能差異，跟網絡開銷比起來都可以忽略不計。

因此，分佈式系統每個節點一般不採用高性能的服務器，而是使用性能相對一般的普通PC服務器。提升分佈式系統的整體性能是通過橫向擴展（增加更多的服務器），而不是縱向擴展（提升每個節點的服務器性能）實現。

分佈式系統最大的特點是可擴展性，它能夠適應需求變化而擴展。企業級應用需求經常隨時間而不斷變化，這也對企業級應用平臺提出了很高的要求。企業級應用平臺必須要能適應需求的變化，即具有可擴展性。比如移動互聯網2C應用，隨著互聯網企業的業務規模不斷增大，業務變得越來越複雜，併發用戶請求越來越多，要處理的數據也越來越多，這個時候企業級應用平臺必須能夠適應這些變化，支持高併發訪問和海量數據處理。分佈式系統有良好的可擴展性，可以通過增加服務器數量來增強分佈式系統整體的處理能力，以應對企業的業務增長帶來的計算需求增加。

2.2 分佈式存儲的問題 – CAP理論

如果我們期待實現一套嚴格滿足ACID的分佈式事務，很可能出現的情況就是系統的可用性和嚴格一致性發生衝突。在可用性和一致性之間永遠無法存在一個兩全其美的方案。由於NoSQL的基本需求就是支持分佈式存儲，嚴格一致性與可用性需要互相取捨，由此延伸出了CAP理論來定義分佈式存儲遇到的問題。

CAP理論告訴我們：一個分佈式系統不可能同時滿足一致性(C:Consistency)、可用性(A:Availability)、分區容錯性(P:Partitiontolerance)這三個基本需求，並且最多隻能滿足其中的兩項。

對於一個分佈式系統來說，分區容錯是基本需求，否則不能稱之為分佈式系統。因此架構師需要在C和A之間尋求平衡。

• C – Consistency – 一致性（與ACID的C完全不同）

一致性是指“all nodes see the same data at the same time”，即更新操作成功並返回客戶端完成後，所有節點在同一時間的數據完全一致。

對於一致性，可以分為從客戶端和服務端兩個不同的視角。

從客戶端來看，一致性主要指的是多併發訪問時更新過的數據如何獲取的問題。

從服務端來看，則是更新如何複製分佈到整個系統，以保證數據最終一致。一致性是因為有併發讀寫才有的問題，因此在理解一致性的問題時，一定要注意結合考慮併發讀寫的場景。

從客戶端角度，多進程併發訪問時，更新過的數據在不同進程如何獲取的不同策略，決定了不同的一致性。對於關係型數據庫，要求更新過的數據能被後續的訪問都能看到，這是強一致性。如果能容忍後續的部分或者全部訪問不到，則是弱一致性。如果經過一段時間後要求能訪問到更新後的數據，則是最終一致性。

• A – Availability – 可用性

可用性是指“Reads and writes always succeed”，即服務一直可用，而且是正常響應時間。

對於一個可用性的分佈式系統，每一個非故障的節點必須對每一個請求作出響應。也就是說，該系統使用的任何算法必須最終終止。當同時要求分區容忍性時，這是一個很強的定義：即使是嚴重的網絡錯誤，每個請求必須完成。

好的可用性主要是指系統能夠很好的為用戶服務，不出現用戶操作失敗或者訪問超時等用戶體驗不好的情況。在通常情況下，可用性與分佈式數據冗餘、負載均衡等有著很大的關聯。

• P – Partition tolerance – 分區容錯性

分區容錯性是指“the system continues to operate despite arbitrary message loss or failureof part of the system”，即分佈式系統在遇到某節點或網絡分區故障的時候，仍然能夠對外提供滿足一致性和可用性的服務。

分區容錯性和擴展性緊密相關。在分佈式應用中，可能因為一些分佈式的原因導致系統無法正常運轉。好的分區容錯性要求能夠使應用雖然是一個分佈式系統，但看上去卻好像是一個可以運轉正常的整體。比如現在的分佈式系統中有某一個或者幾個機器宕掉了，其它剩下的機器還能夠正常運轉滿足系統需求，或者是機器之間有網絡異常，將分佈式系統分隔成未獨立的幾個部分，各個部分還能維持分佈式系統的運作，這樣就具有好的分區容錯性。

• CA without P

如果不要求P（不允許分區），則C（強一致性）和A（可用性）是可以保證的。但其實分區不是你想不想的問題，而是始終會存在，因此CA的系統更多的是允許分區後各子系統依然保持CA。

• CP without A

如果不要求A（可用），相當於每個請求都需要在Server之間強一致，而P（分區）會導致同步時間無限延長，如此CP也是可以保證的。很多傳統的數據庫分佈式事務都屬於這種模式。

• AP without C

要高可用並允許分區，則需放棄一致性。一旦分區發生，節點之間可能會失去聯繫，為了高可用，每個節點只能用本地數據提供服務，而這樣會導致全局數據的不一致性。現在眾多的NoSQL都屬於此類。

CAP理論定義了分佈式存儲的根本問題，但並沒有指出一致性和可用性之間到底應該如何權衡。於是出現了BASE理論，給出了權衡A與C的一種可行方案。

2.3 權衡一致性與可用性 - BASE理論

Base = Basically Available + Soft state + Eventuallyconsistent 基本可用性+軟狀態+最終一致性，由eBay架構師DanPritchett提出。Base是對CAP中一致性A和可用性C權衡的結果，源於提出者自己在大規模分佈式系統上實踐的總結。核心思想是無法做到強一致性，但每個應用都可以根據自身的特點，採用適當方式達到最終一致性。

• BA - Basically Available - 基本可用

基本可用。這裡是指分佈式系統在出現故障的時候，允許損失部分可用性，即保證核心功能或者當前最重要功能可用。對於用戶來說，他們當前最關注的功能或者最常用的功能的可用性將會獲得保證，但是其他功能會被削弱。

• S – Soft State - 軟狀態

允許系統數據存在中間狀態，但不會影響到系統的整體可用性，即允許系統在不同節點的數據副本之間進行數據同步時存在延時。

• E - Eventually Consistent - 最終一致性

要求系統數據副本最終能夠一致，而不需要實時保證數據副本一致。最終一致性是弱一致性的一種特殊情況。最終一致性有5個變種：

• 因果一致性

• 讀己之所寫(因果一致性特例)

• 會話一致性

• 單調讀一致性

• 單調寫一致性

3.分佈式存儲算法

3.1一致性算法 – Paxos

Paxos 算法解決的問題是一個分佈式系統如何就某個值（決議）達成一致。一個典型的場景是，在一個分佈式數據庫系統中，如果各節點的初始狀態一致，每個節點執行相同的操作序列，那麼他們最後能得到一個一致的狀態。為保證每個節點執行相同的命令序列，需要在每一條指令上執行一個“一致性算法”以保證每個節點看到的指令一致。一個通用的一致性算法可以應用在許多場景中，是分佈式計算中的重要問題。因此從20世紀80年代起對於一致性算法的研究就沒有停止過。節點通信存在兩種模型：共享內存（Shared memory）和消息傳遞（Messages passing）。Paxos 算法就是一種基於消息傳遞模型的一致性算法。

不僅僅是在分佈式系統中，凡是多個過程需要達成某種一致的場合都可以使用Paxos 算法。一致性算法可以通過共享內存（需要鎖）或者消息傳遞實現，Paxos 算法採用的是後者。Paxos 算法適用的幾種情況：一臺機器中多個進程/線程達成數據一致；分佈式文件系統或者分佈式數據庫中多客戶端併發讀寫數據；分佈式存儲中多個副本響應讀寫請求的一致性。

3.2分區（Partitioning）

原來所有的數據都是在一個數據庫上的，網絡IO及文件IO都集中在一個數據庫上的，因此CPU、內存、文件IO、網絡IO都可能會成為系統瓶頸。而分區的方案就是把某一個表或某幾個相關的表的數據放在一個獨立的數據庫上，這樣就可以把CPU、內存、文件IO、網絡IO分解到多個機器中，從而提升系統處理能力。

3.3分片（Replication）

分區有兩種模式，一種是主從模式，用於做讀寫分離；另外一種模式是分片模式，也就是說把一個表中的數據分解到多個表中。一個分區只能是其中的一種模式。

3.4一致性哈希（Consistent Hashing）

一致性哈希算法是分佈式系統中常用的算法。比如，一個分佈式的存儲系統，要將數據存儲到具體的節點上，如果採用普通的hash方法，將數據映射到具體的節點上，如key%N，key是數據的key，N是機器節點數，如果有一個機器加入或退出這個集群，則所有的數據映射都無效了，如果是持久化存儲則要做數據遷移，如果是分佈式緩存，則其他緩存就失效了。

一致性哈希基本解決了在P2P環境中最為關鍵的問題——如何在動態的網絡拓撲中分佈存儲和路由。每個節點僅需維護少量相鄰節點的信息，並且在節點加入/退出系統時，僅有相關的少量節點參與到拓撲的維護中。所有這一切使得一致性哈希成為第一個實用的DHT算法。

4.NoSQL的優點/缺點

4.1優點

• 易擴展

NoSQL數據庫種類繁多，但是有一個共同的特點，都是去掉了關係型數據庫的關係型特性。數據之間無關係，這樣就非常容易擴展。也無形之間，在架構的層面上帶來了可擴展的能力。

• 大數據量，高性能

NoSQL數據庫都具有非常高的讀寫性能，尤其在大數據量下，同樣表現優秀。這得益於它的無關係性，數據庫的結構簡單。一般MySQL使用Query Cache，每次表更新Cache就失效，是一種大粒度的Cache，針對web2.0的交互頻繁的應用，Cache性能不高。而NoSQL的Cache是記錄級的，是一種細粒度的Cache，所以NoSQL在這個層面上來說性能就要高很多了。

• 靈活的數據模型

NoSQL無需事先為要存儲的數據建立字段，隨時可以存儲自定義的數據格式。而在關係型數據庫裡，增刪字段是一件非常麻煩的事情。如果是非常大數據量的表，增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。

• 高可用

NoSQL在不太影響性能的情況下，就可以方便地實現高可用的架構。比如Cassandra、HBase模型，通過複製模型也能實現高可用。

4.1缺點

• 沒有標準

沒有對NoSQL數據庫定義的標準，所以沒有兩個NoSQL數據庫是平等的。

• 沒有存儲過程

NoSQL數據庫中大多沒有存儲過程。

• 不支持SQL

NoSQL大多不提供對SQL的支持：如果不支持SQL這樣的工業標準，將會對用戶產生一定的學習和應用遷移上的成本。

• 支持的特性不夠豐富，產品不夠成熟

現有產品所提供的功能都比較有限，不像MS SQL Server和Oracle那樣能提供各種附加功能，比如BI和報表等。大多數產品都還處於初創期，和關係型數據庫幾十年的完善不可同日而語。

NoSQL與SQL的對比

NoSQL數據庫的分類

1.鍵值(Key-Value)存儲數據庫

這一類數據庫主要會使用到哈希表，在這個表中有一個特定的鍵和一個指針指向特定的數據。Key/value模型對於IT系統來說優勢在於簡單、易部署。但是如果DBA只對部分值進行查詢或更新的時候，Key/value就顯得效率低下了。

E. g:

• TokyoCabinet/Tyrant

• Redis

• Voldemort

• OracleBDB

• 列存儲數據庫

這部分數據庫通常是用來應對分佈式存儲的海量數據。鍵仍然存在，但是它們的特點是指向了多個列。這些列是由列家族來安排的。

E. g:

• Cassandra

• HBase

• Riak

• 文檔型數據庫

文檔型數據庫的靈感來自於Lotus Notes辦公軟件，它同第一種鍵值存儲相類似。該類型的數據模型是版本化的文檔，半結構化的文檔以特定的格式存儲，比如JSON。文檔型數據庫可以看作是鍵值數據庫的升級版，允許之間嵌套鍵值。而且文檔型數據庫比鍵值數據庫的查詢效率更高。

E. g:

• CouchDB

• MongoDB

• SequoiaDB

• 圖形(Graph)數據庫

圖形結構的數據庫同其它行列以及剛性結構的SQL數據庫不同，它是使用靈活的圖形模型，並且能夠擴展到多個服務器上。NoSQL數據庫沒有標準的查詢語言(SQL)，因此進行數據庫查詢需要制定數據模型。許多NoSQL數據庫都有REST式的數據接口或者查詢API。

E. g:

• Neo4J

• InfoGrid

• InfiniteGraph

主流NoSQL數據庫介紹及其適用場景

1. Redis

1.1 介紹

Redis是一個開源的使用ANSI C語言編寫、支持網絡、可基於內存亦可持久化的日誌型、Key-Value數據庫，並提供多種語言的API。從2010年3月15日起，Redis的開發工作由VMware主持。從2013年5月開始，Redis的開發由Pivotal贊助。

1.2 適用場景

• 數據變化較少，執行預定義查詢，進行數據統計的應用程序

• 需要提供數據版本支持的應用程序

• 例如：股票價格、數據分析、實時數據蒐集、實時通訊、分佈式緩存

2. MongoDB

2.1 介紹

MongoDB 是一個基於分佈式文件存儲的數據庫。由 C++ 語言編寫。旨在為 WEB 應用提供可擴展的高性能數據存儲解決方案。

MongoDB 是一個介於關係型數據庫和非關係型數據庫之間的產品，是非關係型數據庫當中功能最豐富，最像關係型數據庫的非關係型數據庫。

2.2 適用場景

• 需要動態查詢支持

• 需要使用索引而不是 map/reduce功能

• 需要對大數據庫有性能要求

• 需要使用 CouchDB但因為數據改變太頻繁而佔滿內存

3.Neo4j

3.1 介紹

Neo4j是一個高性能的NoSQL圖形數據庫，它將結構化數據存儲在網絡上而不是表中。它是一個嵌入式的、基於磁盤的、具備完全的事務特性的Java持久化引擎，但是它將結構化數據存儲在網絡(從數學角度叫做圖)上而不是表中。Neo4j也可以被看作是一個高性能的圖引擎，該引擎具有成熟數據庫的所有特性。

3.2 適用場景

• 適用於圖形一類數據

• 這是 Neo4j與其他NoSQL數據庫的最顯著區別

• 例如：社會關係，公共交通網絡，地圖及網絡拓譜

4.Cassandra

4.1 介紹

Apache Cassandra 是一套開源分佈式 Key-Value 存儲系統。它最初由 Facebook 開發，用於儲存特別大的數據。 Cassandra 不是一個數據庫，它是一個混合型的非關係的數據庫，類似於Google 的 BigTable。Cassandra 的數據模型是基於列族（Column Family）的四維或五維模型。

4.2適用場景

• 銀行業，金融業

• 寫比讀更快

5. HBase

5.1 介紹

HBase是一個分佈式的、面向列的開源數據庫，該技術來源於Google論文“Bigtable：一個結構化數據的分佈式存儲系統”。就像Bigtable利用了Google文件系統（File System）所提供的分佈式數據存儲一樣，HBase在Hadoop之上提供了類似於Bigtable的能力。它是一個適合於非結構化數據存儲的數據庫。另一個不同的是HBase基於列的而不是基於行的模式。

5.2適用場景

• 對大數據進行隨機、實時訪問的場合

• 例如： Facebook消息數據庫

6.CouchDB

6.1 介紹

CouchDB 是一個開源的面向文檔的數據庫管理系統，可以通過 RESTful JavaScript Object Notation (JSON) API 訪問。術語 “Couch” 是 “Cluster Of Unreliable CommodityHardware” 的首字母縮寫，它反映了 CouchDB 的目標具有高度可伸縮性，提供了高可用性和高可靠性，即使運行在容易出現故障的硬件上也是如此。

6.2適用場景

• 數據變化較少，執行預定義查詢，進行數據統計的應用程序

• 需要提供數據版本支持的應用程序。

• 例如： CRM、CMS系統。 master-master複製對於多站點部署是非常有用的。

NoSQL優秀應用實例

1. 新浪微博 - Redis

新浪微博從技術上來說，每天用戶發表微博特別容易，這造成每天新增的數據量都是百萬級、上千萬級的這樣一個量。你經常要面對的一個問題就是增加服務器，因為一般一臺MySQL服務器，它可能支撐的規模也就是幾千萬，或者說複雜一點只有幾百萬，這樣，可能每天都要增加服務器，從而解決所你面對的這些問題。

目前新浪微博是Redis全球最大的用戶，在新浪有200多臺物理機，400多個端口正在運行著Redis, 有4G的數據跑在Redis上來為微博用戶提供服務。

新浪微博面臨的問題如下：

• 數據結構(Data Structure)需求越來越多, 但memcache中沒有, 影響開發效率

• 隨著讀操作的量的上升，性能問題需要解決，經歷的過程有:

數據庫讀寫分離(M/S)-->數據庫使用多個Slave-->增加Cache (memcache)-->轉到Redis

• 解決寫的問題：

水平拆分，對錶的拆分，將有的用戶放在這個表，有的用戶放在另外一個表。

• 可靠性需求

Cache的"雪崩"問題難以解決，面臨著快速恢復的挑戰。

• 開發成本需求

Cache和DB的一致性維護成本越來越高，但開發需要跟上不斷湧入的產品需求。且硬件成本最貴的就是數據庫層面的機器，基本上比前端的機器要貴幾倍，主要是IO密集型，很耗硬件。

• 維護性複雜

一致性維護成本越來越高

BerkeleyDB使用B樹，會一直寫新的，內部不會有文件重新組織；這樣會導致文件越來越大；大的時候需要進行文件歸檔，歸檔的操作要定期做，這樣，就需要有一定的down time。

基於以上考慮，新浪微博選擇了Redis。

在新浪NoSQL和MySQL在大多數情況下是結合使用的，根據應用的特點選擇合適的存儲方式。譬如：關係型數據，例如：索引使用MySQL存儲；非關係型數據，例如：一些K/V需求的，對併發要求比較高的放入Redis存儲。

新浪微博團隊通過修改Redis源碼滿足自己的業務需求：完善它的replication機制，加入position的概念，讓維護更容易，同時failover能力也大大增強。改善Hashset在RDB裡面的存儲方式，提升複雜數據類型的加載速度。

業務場景如下：

1. 業務使用方式：

• hash sets: 關注列表, 粉絲列表, 雙向關注列表(key-value(field), 排序)

• string(counter): 微博數, 粉絲數, ...(避免了select count(*) from ...)

• sort sets(自動排序): TopN, 熱門微博等, 自動排序

• lists(queue): push/sub提醒,...

• 上述四種, 從精細化控制方面，hash sets和string(counter)推薦使用, sort sets和lists(queue)不推薦使用

• 還可通過二次開發，進行精簡。比如: 存儲字符改為存儲整形, 16億數據,只需要16G內存

• 存儲類型保存在3種以內，建議不要超過3種；

• 將memcache +mysql 替換為Redis：

• Redis作為存儲並提供查詢，後臺不再使用mysql，解決數據多份之間的一致性問題；

2. 對大數據表的存儲（eg：140字微博的存儲）

• 一個庫就存唯一性id和140個字；

• 另一個庫存id和用戶名，發佈日期、點擊數等信息，用來計算、排序等，等計算出最後需要展示的數據時再到第一個庫中提取微博內容；

3. 一些技巧

• 很多應用, 可以承受數據庫連接失敗, 但不能承受處理慢

• 一份數據, 多份索引(針對不同的查詢場景)

• 解決IO瓶頸的唯一途徑: 用內存

• 在數據量變化不大的情況下，優先選用Redis

2. 淘寶數據平臺 – Oceanbase,Tair（均為自研）

數據產品的一個最大特點是數據的非實時寫入，正因為如此，可以認為在一定的時間段內，整個系統的數據是隻讀的。這為設計緩存奠定了非常重要的基礎。一些對實效性要求很高的數據，例如針對搜索詞的統計數據，希望能儘快推送到數據產品前端，所以在內存中做實時計算，並把計算結果在儘可能短的時間內刷新到 NoSQL存儲設備中，供前端產品調用。

淘寶Oceanbase的設計之初，是這樣的。公司通過對淘寶的在線存儲需求進行分析發現：

淘寶的數據總量比較大，未來一段時間，比如五年之內的數據規模為百TB級別，千億條記錄，另外，數據膨脹很快，傳統的分庫分表對業務造成很大的壓力，必須設計自動化的分佈式系統。所以有了淘寶Oceanbase，它以一種很簡單的方式滿足了未來一段時間的在線存儲需求，並且還獲得了一些其它特性，如高效支持跨行跨表事務，這對於淘寶的業務是非常重要的。

OceanBase由如下幾個部分組成：

• 客戶端：用戶使用OceanBase的方式和MySQL數據庫完全相同，支持JDBC、 C客戶端訪問，等等。基於MySQL數據庫開發的應用程序、工具能夠直接遷移到OceanBase。

• RootServer：管理集群中的所有服務器，子表（tablet）數據分佈以及副本管理。 RootServer一般為一主一備，主備之間數據強同步。

• UpdateServer：存儲OceanBase系統的增量更新數據。UpdateServer一般為一主一備，主備之間可以配置不同的同步模式。部署時，UpdateServer進程和RootServer進程往往共用物理服務器。

• ChunkServer：存儲OceanBase系統的基線數據。基線數據一般存儲兩份或者三份，可配置。

• Merge Server：接收並解析用戶的SQL請求，經過詞法分析、語法分析、查詢優化等一系列操作後轉發給相應的ChunkServer或者UpdateServer。如果請求的數據分佈在多臺ChunkServer上，MergeServer還需要對多臺ChunkServer返回的結果進行合併。客戶端和MergeServer之間採用原生的MySQL通信協議，MySQL客戶端可以直接訪問MergeServer。

淘寶Tair是由淘寶自主開發的Key/Value結構數據存儲系統，並且於 2010年6月30號在淘寶開源平臺上正式對外開源，在淘寶網有著大規模的應用。用戶在登錄淘寶、查看商品詳情頁面或者在淘江湖和好友“搗漿糊”的時候，都在直接或間接地和Tair交互。淘寶將Tair開源，希望有更多的用戶能從我們開發的產品中受益，更希望依託社區的力量，使Tair有更廣闊的發展空間。

Tair 的分佈採用的是一致性哈希算法, 對於所有的key, 分到Q個桶中, 桶是負載均衡和數據遷移的基本單位. config server 根據一定的策略把每個桶指派到不同的data server上. 因為數據按照key做hash算法, 所以可以認為每個桶中的數據基本是平衡的. 保證了桶分佈的均衡性, 就保證了數據分佈的均衡性。

3. 優酷運營數據分析 – HBase,MongoDB, Redis

優酷作為一家大型視頻網站，擁有海量播放流暢的視頻。它秉承注重用戶體驗這一產品技術理念，將絕大部分存儲用在視頻資源上。通過建設專用的視頻CDN，建立了可自由擴展、性能優異的架構，在提供更好用戶體驗的同時優化了存儲資源。在除視頻資源外的其它方面，優酷也累積了海量數據：僅運營數據，每天收集到的網站各類訪問日誌總量已經達到TB級，經分析及壓縮處理後留存下來的歷史運營數據已達數百TB，很快將會達到 PB級，5年後數據量將會達到幾十PB級。

目前優酷的在線評論業務已部分遷移到MongoDB，運營數據分析及挖掘處理目前在使用Hadoop/HBase;在Key-Value產品方面，它也在尋找更優的 Memcached替代品，如Redis，相對於Memcached，除了對Value的存儲支持三種不同的數據結構外，同一個Key的Value進行部分更新也會更適合一些對Value頻繁修改的在線業務;同時在搜索產品中應用了Tokyo Tyrant;對於Cassandra等產品也進行過研究。

對於優酷來說，仍處於飛速發展階段，已經在考慮未來自建數據中心，提高數據處理能力，從網站的運營中發掘出更多信息，為用戶提供更好的視頻服務。

4. 豆瓣社區 – BeansDB（自研KV數據庫）

它採用類似memcached的去中心化結構，在客戶端實現數據路由。目前只提供了Python版本的客戶端，其它語言的客戶端可以由memcached的客戶端稍加改造得到。它具有如下特性：

• 高可用：通過多個可讀寫的用於備份實現高可用

• 最終一致性：通過哈希樹實現快速完整數據同步(短時間內數據可能不一致)

• 容易擴展：可以在不中斷服務的情況下進行容量擴展。

• 高性能：異步網絡IO, 日誌結構的存儲方式Bitcask.

• 簡單協議：Memcache兼容協議，大量可用客戶端

目前，BeansDB在豆瓣主要部署了兩個集群：一個集群用於存儲數據庫中的大文本數據，比如日記、帖子一類;另外一個豆瓣FS集群，主要用於存儲媒體文件，比如用戶上傳的圖片、豆瓣電臺上的音樂等。

BeansDB採用Key-Value存儲架構，其最大的特點是具有高度的可伸縮性;在BeansDB的架構下，在大數據量下，擴展數據節點將輕而易舉，只需要添加硬件，安裝軟件，修改相應的配置文件即可。

BeansDB項目可以說是一個簡化版的AWS DynamoDB。BeansDB對key做哈希運算找到節點來實現分佈和冗餘， 一個寫操作會寫好幾個節點，而現在的配置是寫三份讀一份。BeansDB主要的特點是支持海量KV數據庫——相比Redis這種支持幾十個G到幾百個G的內存KV數據庫，BeansDB可以支持到上百T的數據。另外BeansDB最大的好處就是運維很簡單，性能、擴容都很好，也實現了最終一致性。

BeansDB在可用性方面也有很大的優勢，任何一個節點宕機都不會受到影響，數據是自動伸縮冗餘的。在運維方面也很簡單，基本上沒有什麼用戶數據的冗餘殘餘，所有數據通過一個同步腳本可以快速同步。

學習資料

1.書籍

1.1 MongoDB: The Definitive Guide（Kristina Chodorow）

MongoDB是入門NoSQL數據庫的最好選擇之一。本書講解了所有關於MongoDB的基礎知識，是本很好的入門書籍。

1.2 NoSQL精粹 （Pramod J.Sadalage,Martin Fowler）

本書全方位比較關係型數據庫與NoSQL數據庫的異同，詳細講解4大主流NoSQL數據庫的優劣勢、用法和適用場合，深入探討實現NoSQL數據庫系統的各種細節。此書對於技術選型有很好的指導作用。

1.3 各種NoSQL數據庫的官方文檔

有一定計算機基礎的人還是最推薦看官方文檔，官方文檔對其產品的理解永遠是最深的，對於開發者若能理解其設計原則，上手比看書要快。

2.視頻

2.1 GettingStarted - NoSQL - MongoDB

地址：

https://www.youtube.com/watch?v=5rbFoSGHErA&list=PLf0swTFhTI8ra5T5B7QsNuu5yxiEdd6Ro

老外的視頻，MongoDB的一個比較通俗易懂的教程。

2.2 Cassandra-NoSQL-Tutorials

地址：

https://www.youtube.com/watch?v=8G4a4G3S654&list=PLpE_8MUgZj5vSp1Q_5GyDKBgy9dG1ifdE

同樣是老外的Cassandra的系列教程。

2.3 Redis ServerTutorial

地址：

https://www.youtube.com/watch?v=fyV3OK1fCr0&list=PLpIXNzrq3JHQ8-QCJqrC2ihrGJkjdN2J6

Redis的系列教程，不過側重於分佈式緩存功能的實現。這也是Redis的主要使用場景。

3.邊用邊Google

工具類的事物永遠是邊用邊學最快，真正用過了（尤其是遇到過超高併發/存儲的情況）才會體驗到NoSQL的好處。

進一步學習

在數據派THU後臺（非留言區）回覆"綜述"即可獲取資源。

1.分佈式算法

• Paxos made simple

一篇通俗講解paxos算法的論文，由paxos算法發明者Leslie Lamport所寫，是其發明paxos算法的論文的簡化版。此算法用於確定分佈式系統的共識。

• Byzantine generals problem

一篇研究“拜占庭將軍”問題的論文。“拜占庭將軍”是分佈式場景的典型問題，paxos算法就是用來解決此問題的。

• Research on the improvement of MongoDBAuto-Sharding in cloud environment

一篇研究MongoDB分片算法的論文。分片是NoSQL數據庫的基本功能。

2. NoSQL數據庫的研究及底層實現

• Bigtable:A distributed storage system for structured data

BigTable的設計論文，HBase是其開源實現，是一個典型的基於列的NoSQL數據庫。此篇論文是Google的“三大馬車”之一。

• Optimizingevent polling for network-intensive applications: A case study on redis

一篇研究Redis底層Networking IO的論文，並優化了原有的epoll模型，命名為FlexPoll。

• Performanceevaluation of a MongoDB and Hadoop platform for scientific data analysis

一篇研究MongoDB和Hadoop在科學計算場景的性能的論文（科學計算是cpu/gpu-intensive而非i/o密集型）。

3. NoSQL應用案例

• Big dataanalysis with MongoDB for decision support system

這篇論文使用MongoDB對商業數據做了大數據分析，為企業提供決策，並比較了RDBMS與NoSQL在數據分析方面的優劣。

• Implementingjoins over HBase on cloud platform

一篇在論述如何在HBase上實現Join功能的論文。Join在分佈式環境下實現非常困難，為此此篇論文設計了2種算法：MapReduceJoin與ParallelHashJoin。