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

時間 2019-11-16

標籤一文讀懂關係數據庫 nosql 欄目 SQL 简体版

原文原文鏈接

爲了更好的理解非關係型數據庫，我又深刻的度娘了下前端

原文地址：https://baijiahao.baidu.com/po/feed/share?wfr=spider&for=pc&context=%7B"sourceFrom"%3A"bjh"%2C"nid"%3A"news_3690540158463624329"%7Dnode

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

本文爲你們解析非關係型數據庫（NoSQL）。web

前言redis

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

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

但隨着信息化的浪潮和互聯網的興起，傳統的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

地址：