雲計算下的數據庫 分析 以及部分互聯網公司眼下採用的新型數據庫總結

雲計算下的新型數據庫技術 

 

摘要：在這個信息化的時代，咱們的一舉一動都離不開與數據打交道，特別是雲計算和大數據時代的到來，使得傳統數據庫的性能已沒法知足海量數據的實時交易查詢需求。在性能和成本的雙重壓力之下。雲計算下的數據庫需要尋找突破之路。

 

 1.簡單介紹：

雲計算經過整合。管理和調配分佈在互聯網中的所有計算資源，以統一的界面同一時候向用戶提供服務。

互聯網提供的各類計算形式的應用以及提供這些服務的數據中心和軟硬件基礎設施、提供的服務成爲軟件即服務（SaaS），數據中心的軟硬件基礎設施即爲雲，這樣的虛擬化資源提供計算的方式使得服務經過互聯網傳播，而用戶不需要知道雲計算服務的提供者和提供方式。所以。雲計算具備規模大，可靠性高，用戶透明，可擴展性強，提供按需服務和便宜等特色。

而實現以上需求的前提條件就是雲計算系統應該具有足夠大的規模和處理能力。以知足大量的數據訪問，數據存儲和來自不一樣網絡等額請求。

傳統的關係型數據庫儘管在數據存儲方面佔領着不可動搖的地位，但由於其天生的限制，愈來愈不能知足雲計算下的數據擴展、讀寫速度、支撐容量以及建設和運營成本的要求。鑑於此。國內外知名的一些互聯網企業Google、Facebook、Twitter、阿里、騰訊、百度等紛紛展開探索，自主研發新型數據庫，這些企業有擁有衆多的優秀人才。以及豐富的產品經驗，因此對於新型數據庫的探索成果在必定程度上也表明了當下雲計算下數據庫的最新的進展。因此本文主要先對與傳統型數據庫的優劣進行一些分析。接着介紹了現如今新型數據庫的研究進展，對各種型數據庫進行一些對照分析，最後在對於還存在的不足進行總結並對數據庫的發展提出本身一些的見解。

2.背景：

2.1 雲計算和大數據：

大數據是一種大規模數據的管理和利用的商業模式和技術平臺的泛指，它不一樣於傳統的海量數據，除了數據規模呈現幾何級數增加的特徵之外。還包含所有數據類型的採集、分類、處理、分析和展示等多個方面，從而終於實現從大數據中挖掘潛在巨大價值的目的。所以，大數據具備這4方面的特徵：規模性（Volume）、多樣性（Variety）、快速性（Velocity）和真實性（Veracity）。

雲計算是一種基於互聯網的計算方式，經過這樣的方式，共享的軟硬件資源和信息能夠按需提供給計算機和其它設備。能夠像煤氣、水電同樣提供給信息時代的社會化服務。使用方便。費用低廉。雲計算具備下面的特色：

（1） 超大規模。「雲」具備超大的規模，Google雲計算擁有100多萬臺server，Amazon、IBM、微軟等的雲均擁有幾十萬臺server，正是這樣擁有超大規模的「雲」能夠賦予用戶史無前例的計算能力。

（2） 虛擬化。雲計算支持用戶在任何位置，使用各類終端獲取應用服務。所請求的資源來自「雲」，而不是固定的有形的實體。應用在「雲」中某處執行。但實際用戶無需瞭解、也不用操心應用執行的詳細位置。僅僅需要一臺筆記本或者一部手機，就可以經過網絡服務來實現咱們需要的一切，甚至包含超級計算的任務。

（3） 高可靠性。「雲」使用了數據多副本容錯、計算節點同構可互換等措施來保障服務的高可靠性，使用雲計算比使用本地計算可靠。

（4） 通用性。雲計算不針對特定的應用。在雲的支撐下可以構造出變幻無窮的應用。同一個雲可以同一時候支撐不一樣的應用執行

（5） 高可擴展性。

雲的規模可以動態伸縮。知足應用和用戶規模增加的需要。

（6） 按需服務。雲是一個龐大的資源池，可按需購買，象自來水。電，煤氣同樣計費使用。

（7） 極其便宜。

用於「雲」的特殊容錯措施可以採用極其便宜的節點來構成雲。「雲」的本身主動化集中式管理使得大量企業無需負擔日益高昂的數據中心管理成本，「雲」的通用性使資源的利用率較之傳統系統大幅提高，所以用戶可以充分享受「雲」的低成本優點。

 

 

大數據着眼於「數據」，關注實際業務。提供數據採集分析挖掘。看重信息積澱即數據存儲能力。

雲計算着眼於「計算」。關注IT解決方式，提供IT基礎架構，看重計算能力，即數據處理能力，數據是二者之間最重要的聯繫，也是二者存在的意義，因此對於雲計算和大數據時代。數據庫技術的重要性也就不言而喻了。

2.2 雲計算下的傳統型數據庫

隨着web2.0的發展，傳統的關係型數據庫在應對超大規模和高併發的數據量和訪問量時存在難以克服的問題：

（1）高併發讀寫速度慢

在數據量達到必定規模時，由於關係型數據庫的系統邏輯很複雜，使得其easy發生死鎖等併發問題。致使其讀寫速度降低很嚴重。

（2）支撐容量有限

對於數據量巨大的一些站點好比社交站點，天天海量的用戶動態，累計下每個月就能產生幾億條數據記錄，對於關係型數據庫。在這樣一個具備數億條記錄的表中進行SQL查詢，效率會是極其低下乃至不可忍受的。

（3）可擴展性差

在基於web的架構中，數據庫是最難進行橫向擴展的，當一個應用系統的用戶量和訪問量與日俱增的時候，傳統的關係型數據庫卻不能像web service 那樣簡單的經過加入不少其它的硬件和服務節點來擴展性能和負載能力。

對於很是多需要提供不間斷服務的站點來講，對數據庫系統進行升級和擴展是很是痛苦的事情，每每需要停機維護和數據遷移，所以迫切需要關係數據庫也能夠經過不斷加入server節點來實現擴展。

（4）建設和運維成本高

企業級數據庫的價格很是高，並且隨着系統的規模增大而不斷上升。高昂的建設和運維成本沒法知足雲計算應用對數據庫的需求。

（5）對於分佈式系統的制約

爲了支撐更大的訪問量和數據量，咱們一定需要分佈式數據庫系統，然而因爲傳統關係型數據庫的強一致性，就會使得分佈式系統的延遲提升，因爲網絡通訊自己比單機內通訊代價高很是多，這樣的通訊的代價就會直接添加系統單次提交的延遲。延遲提升會致使數據庫所持有時間變長，使得高衝突條件下分佈式事物的性能不升反降，甚至性能距離單機數據庫都還有明顯的差距。

面對這個難題，傳統的關係數據庫選擇了放棄分佈式的方案，因爲在20世紀70-80年代，數據庫主要被用來處理企業內的各種數據，面對的用戶只是幾千人，而數據量最多也就是TB級別。

用單臺機器處理事務。用個磁盤陣列處理一下磁盤容量不夠的問題，基本就能解決一切問題。

然而，在大數據時代，雲計算的數據量已然從TB級別變爲了PB級別甚至不少其它。存在單點的單擊系統無論怎樣努力，都會面對系統處理能力的天花板，原來的這條路就不能再接着走下去了。

2.3 幾種雲計算下的新型數據庫及事實上現原理

 

（1）NoSQL非關係型數據庫

面對傳統數據庫出現的種種挑戰，NoSQL是在新形勢下出現的一種給關係型數據庫的總稱。它用全新的存儲方式。下降了數據交互，下降了編寫、調試的代碼，對海量數據實現高效存儲和高效訪問。同一時候它的開源免費也下降了企業的運營成本。

NoSQL的主要特徵爲：

1）不需要提早定義模式：不需要提早定義數據模式，提早定義表結構。

數據中的每條記錄可能有不一樣的屬性和格式。當插入數據時，並不需要預先定義它們的模式。

 

2）無共享架構：相對於將所有數據存儲的存儲區域網絡中的全共享架構。

NoSQL每每將數據劃分後存儲在各個本地server上。因爲從本地磁盤讀取數據的性能每每好於經過網絡傳輸讀取數據的性能。從而提升了系統的性能。

3）彈性可擴展：可以在系統執行的時候。動態添加或者刪除結點。不需要停機維護，數據可以本身主動遷移。

4）分區：相對於將數據存放於同一個節點，NoSQL數據庫需要將數據進行分區，將記錄分散在多個節點上面。

並且一般分區的同一時候還要作複製。這樣既提升了並行性能。又能保證沒有單點失效的問題。

5）異步複製：和RAID存儲系統不一樣的是，NoSQL中的複製。每每是基於日誌的異步複製。

這樣，數據就可以儘快地寫入一個節點。而不會被網絡傳輸引發拖延。

缺點是並不老是能保證一致性，這種方式在出現問題的時候。可能會丟失少許的數據。

6）BASE：相對於事務嚴格的ACID特性，NoSQL數據庫保證的是BASE特性。BASE是終於一致性和軟事務。

NoSQL數據庫並無一個統一的架構，兩種NoSQL數據庫之間的不一樣，甚至遠遠超過兩種關係型數據庫的不一樣。可以說，NoSQL各有所長。成功的NoSQL一定特別適用於某些場合或者某些應用。在這些場合中會遠遠賽過關係型數據庫和其它的NoSQL。

詳細優點表現有：

1）數據庫的開發效率高，在設計上NoSQL數據庫和傳統的數據庫有很是大的不一樣，傳統應用程序的開發中。需要在內存數據結構和福安息數據庫的映射上花費大量的精力和時間。

NoSQL數據庫更符合應用程序的需求，部分NoSQL數據庫可以在硬盤上直接操做。簡化了數據的交互，下降了編寫、調試程序的工做量。

2）數據庫的擴展能力強。現在企業一般使用更小，更廉價的計算機組成集羣來構建數據庫。NoSQL數據庫的設計正是針對server集羣。因此更適合大規模數據的處理。

3）數據庫的開發成本低廉。因爲NoSQL數據庫主要都是開源軟件，因此沒有昂貴的開發成本。在項目開發中很是多企業爲了節省開發成本而選擇NoSQL數據庫。

4）數據模型靈活。

在關係數據庫中。數據有固定結構。經過各類操做互相關聯。對大型的表格增刪字段很麻煩。NoSQL的存儲僅僅有一對鍵值或者數組。無需事先創建字段，不論何時都可以存儲本身定義的數據格式。

NoSQL數據庫的分類：

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

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

[3] 舉好比：Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB.

列存儲數據庫。

這部分數據庫通常是用來應對分佈式存儲的海量數據。

鍵仍然存在。但是它們的特色是指向了多個列。這些列是由列家族來安排的。如：Cassandra, HBase, Riak.

文檔型數據庫

文檔型數據庫的靈感是來自於Lotus Notes辦公軟件的，而且它同第一種鍵值存儲相相似。

該類型的數據模型是版本號化的文檔，半結構化的文檔以特定的格式存儲，比方JSON。文檔型數據庫可 以看做是鍵值數據庫的升級版，贊成之間嵌套鍵值。

而且文檔型數據庫比鍵值數據庫的查詢效率更高。

如：CouchDB, MongoDb. 國內也有文檔型數據庫SequoiaDB，已經開源。

圖形(Graph)數據庫

圖形結構的數據庫同其它行列以及剛性結構的SQL數據庫不一樣，它是使用靈活的圖形模型，並且能夠擴展到多個server上。NoSQL數據庫沒有標準的查詢語言(SQL)，所以進行數據庫查詢需要制定數據模型。

不少NoSQL數據庫都有REST式的數據接口或者查詢API。如：Neo4J, InfoGrid, Infinite Grap

（2）NewSQL

NewSQL是對各類新的可擴展/高性能數據庫的總稱，這類數據庫不只具備NoSQL對海量數據的存儲管理能力，還有傳統數據庫支持ACID和SQL等特性。

NewSQL系統儘管在的內部結構變化很是大，但是它們有兩個顯着的共同特色：

(1)它們都支持關係數據模型。

(2) 它們都使用SQL做爲其基本的接口。

已知的第一個NewSQL系統叫作H-Store，它是一個分佈式並行內存數據庫系統。

眼下NewSQL系統大體分三類： 

新架構

第一類型的NewSQL系統是全新的數據庫平臺，它們均採取了不一樣的設計方法。

它們大概分兩類：

(1) 這類數據庫工做在一個分佈式集羣的節點上，當中每個節點擁有一個數據子集。 SQL查詢被分紅查詢片斷髮送給本身所在的數據的節點上運行。這些數據庫可以經過加入額外的節點來線性擴展。現有的這類數據庫有： Google Spanner, VoltDB, Clustrix, NuoDB.

(2) 這些數據庫系統一般有一個單一的主節點的數據源。它們有一組節點用來作事務處理，這些節點接到特定的SQL查詢後，會把它所需的所有數據從主節點上取回來後運行SQL查詢，再返回結果。

SQL引擎

第二類是高度優化的SQL存儲引擎。這些系統提供了MySQL一樣的編程接口。但擴展性比內置的引擎InnoDB更好。這類數據庫系統有：TokuDB, MemSQL。

透明分片

這類系統提供了分片的中間件層。數據庫本身主動切割在多個節點執行。

這類數據庫包擴：ScaleBase。dbShards, Scalearc。 

2.4 當今幾家主流互聯網公司的數據庫技術

（1）阿里分佈式數據庫服務DRDS

DRDS也是一個NewSQL的系統，它與ScaleBase、VoltDB等系統相似，都但願能夠找到一條既能保持系統的高擴展性和高性能，又能儘量保持傳統數據庫的ACID事務和SQL特性的分佈式數據庫系統。

 

三層架構，Matrix相應數據庫切分場景，對SQL有必定限制，Group相應讀寫分離和高可用場景。對SQL差點兒沒有限制。

 

DRDS主要功能介紹

分佈式SQL運行引擎
分佈式SQL引擎基本的目的，就是實現與單機數據庫SQL引擎的全然兼容。眼下咱們的SQL引擎能夠作到與MySQL的SQL引擎全兼容，包括各種join和各種複雜函數等。他主要包括SQL解析、優化、運行和合並四個流程，如圖3中綠色部分。

 

儘管SQL是兼容的。但是分佈式SQL運行算法與單機SQL的運行算法卻全然不一樣。緣由也很是easy，網絡通訊的延遲比單機內通訊的延遲大得多。舉個 樣例說明一下。咱們有份文件要從一張紙A上謄寫到另一張紙B上，單機系統就比如兩張紙都在同一個辦公室裏，而分佈式數據庫則就像是一張紙在北京。一張紙 在杭州。

天然地，假設兩張紙在同一個辦公室，因爲傳輸距離近，逐行謄寫的效率是可以接受的。而假設距離是北京到杭州，用逐行謄寫的方式。就立馬顯得代價太 高了，咱們總不能看一行。就打個「飛的」去杭州寫下來吧。

在這樣的狀況下。仍是把紙A上的信息拍個照片。【一整批的】帶到杭州去處理，明顯更簡單一些。這就 是分佈式數據庫特別強調吞吐調優的緣由，僅僅要是涉及到跨機的所有查詢。都必須儘量的積攢一批後一塊兒發送，以下降系統延遲提升帶來的不良影響。

按需數據庫集羣平滑擴縮

DRDS贊成應用按需將新的單機存儲增長或移出集羣，DRDS則能夠保證應用在遷移流程中實現不停機擴容縮容。

 

在內部的數據庫使用實踐中，這個功能的一個最重要應用場景就是雙11了。在雙11以前。會將大批的機器增長到咱們的數據庫集羣中，抗過了雙11，這批機器就會下線。 

因爲全然沒法預測在什麼時間點系統會有爆發性的增加，而假設在這時候系統因爲技術緣由不能使用。就會給整個業務帶來毀滅性的影響，風口一旦錯過，就追悔莫及了。我想這就是雲計算特別強調可擴展能力的緣由吧。

小表廣播
小表廣播也是咱們在分佈式數據庫領域內最常用的工具之中的一個。他的核心目的事實上都是一個——儘量讓查詢僅僅發生在單機。

讓咱們用一個樣例來講明。小表廣播的通常使用場景。

 

圖中，假設我想知道買家id等於0的用戶在商城裏面買了哪些商品，咱們一般會先將這兩個表join起來。而後再用where平臺名=」商城」 and buyerID = 0找到符合要求的數據。然而這樣的join的方式。會致使大量的針對左表的網絡I/O。

假設要取出的數據量比較大。系統延遲會明顯上升。

這時候，爲了提高性能，咱們就必須要下降跨機join的網絡代價。咱們比較推薦應用作例如如下處理，將左表拷貝到右表的每一個庫上。這樣，join操做就由分佈式join一下變回到本地join。系統的性能就有很是大的提高了，如圖所看到的。

 

分佈式事務套件

在阿里巴巴的業務體系中存在許多需要事務類的場景。下單減庫存，帳務，都是事務場景最集中的部分。
而咱們處理事務的方法卻和傳統應用處理事務的方案不大同樣。咱們很強調事務的終於一致性和異步化。利用這樣的方式，能夠極大地減小分佈式系統中鎖持有的時間，從而極大地提高系統性能。

 

這樣的處理機制，是咱們分佈式事務能夠以極低成本大量執行的最核心法門。

在DRDS平臺內，咱們將這些方案產品化，爲了DRDS的分佈式事務解決套件。

利用他們，可讓你以比較低的成本。實現低延遲。高吞吐的分佈式事務場景。

 

（2）MongoDB

MongoDB[1] 是一個基於分佈式文件存儲的數據庫。由C++語言編寫。

旨在爲WEB應用提供可擴展的高性能數據存儲解決方式。

MongoDB[2] 是一個介於關係數據庫和非關係數據庫之間的產品。是非關係數據庫其中功能最豐富，最像關係數據庫的。他支持的數據結構很鬆散，是相似json的bson格式。所以可以存儲比較複雜的數據類型。

Mongo最大的特色是他支持的查詢語言很強大，其語法有點相似於面向對象的查詢語言，差點兒可以實現相似關係數據庫單表查詢的絕大部分功能，而且還支持對數據創建索引。

它的特色是高性能、易部署、易使用，存儲數據很方便。主要功能特性有：

*面向集合存儲，易存儲對象類型的數據。

*模式自由。

*支持動態查詢。

*支持全然索引。包括內部對象。

*支持查詢。

*支持複製和故障恢復。

*使用高效的二進制數據存儲，包含大型對象（如視頻等）。

*本身主動處理碎片。以支持雲計算層次的擴展性。

*支持RUBY。PYTHON。JAVA。C++，PHP，C#等多種語言。

*文件存儲格式爲BSON（一種JSON的擴展）。

*可經過網絡訪問。

使用原理

所謂「面向集合」（Collection-Oriented），意思是數據被分組存儲在數據集中，被稱爲一個集合（Collection)。

每個集合在數據庫中都有一個惟一的標識名，並且能夠包括無限數目的文檔。

集合的概念相似關係型數據庫（RDBMS）裏的表（table），不一樣的是它不需要定義不論什麼模式（schema)。Nytro MegaRAID技術中的閃存快速緩存算法。能夠快速識別數據庫內大數據集中的熱數據，提供一致的性能改進。

模式自由（schema-free)，意味着對於存儲在mongodb數據庫中的文件，咱們不需要知道它的不論什麼結構定義。

假設需要的話，你全然可以把不一樣結構的文件存儲在同一個數據庫裏。

存儲在集合中的文檔，被存儲爲鍵-值對的形式。鍵用於惟一標識一個文檔，爲字符串類型。而值則可以是各類復雜的文件類型。

咱們稱這樣的存儲形式爲BSON（Binary Serialized Document Format）。[3] 

[4] MongoDB已經在多個網站部署，其主要場景例如如下：

1）站點實時數據處理。它很適合實時的插入、更新與查詢。並具有站點實時數據存儲所需的複製及高度伸縮性。

2）緩存。由於性能很是高，它適合做爲信息基礎設施的緩存層。在系統從新啓動以後，由它搭建的持久化緩存層可以避免下層的數據源過載。

3）高伸縮性的場景。很適合由數十或數百臺server組成的數據庫。它的路線圖中已經包括對MapReduce引擎的內置支持。

不適用的場景例如如下：1）要求高度事務性的系統。

2）傳統的商業智能應用。

3）複雜的跨文檔（表）級聯查詢。

設計特徵

MongoDB 的設計目標是高性能、可擴展、易部署、易使用。存儲數據很方便。其主要功能特性例如如下。

（1）面向集合存儲，easy存儲對象類型的數據。在MongoDB 中數據被分組存儲在集合中，集合相似RDBMS 中的表，一個集合中可以存儲無限多的文檔。

（2）模式自由，採用無模式結構存儲。在MongoDB 中集合中存儲的數據是無模式的文檔，採用無模式存儲數據是集合差異於RDBMS 中的表的一個重要特徵。

（3）支持全然索引，可以在隨意屬性上創建索引，包括內部對象。

MongoDB的索引和RDBMS 的索引基本同樣。可以在指定屬性、內部對象上建立索引以提升查詢的速度。

除此以外，MongoDB 還提供建立基於地理空間的索引的能力。

（4）支持查詢。MongoDB 支持豐富的查詢操做，MongoDB 差點兒支持SQL中的大部分查詢。

（5）強大的聚合工具。

MongoDB 除了提供豐富的查詢功能外。還提供強大的聚合工具，如count、group 等，支持使用MapReduce 完畢複雜的聚合任務。

（6）支持複製和數據恢復。

MongoDB 支持主從複製機制，可以實現數據備份、故障恢復、讀擴展等功能。而基於副本集的複製機制提供了本身主動故障恢復的功能。確保了集羣數據不會丟失。

（7）使用高效的二進制數據存儲，包含大型對象（如視頻）。使用二進制格式存儲，可以保存不論什麼類型的數據對象。

（8）本身主動處理分片，以支持雲計算層次的擴展。MongoDB 支持集羣本身主動切分數據。對數據進行分片可以使集羣存儲不少其它的數據，實現更大的負載。也能保證存儲的負載均衡。

（9）支持Perl、PHP、Java、C#、JavaScript、Ruby、C 和C++語言的驅動程序。MongoDB 提供了當前所有主流開發語言的數據庫驅動包，開發者使用不論什麼一種主流開發語言都可以輕鬆編程。實現訪問MongoDB 數據庫。

（10）文件存儲格式爲BSON（JSON 的一種擴展）。

BSON 是對二進制格式的JSON 的簡稱，BSON 支持文檔和數組的嵌套。

（11）可以經過網絡訪問。

可以經過網絡遠程訪問MongoDB 數據庫。

(3)亞馬遜自主研發的數據庫：DynamoDB

DynamoDB是亞馬遜自主研發的NoSQL型數據庫,Amazon DynamoDB 是一項高速靈活的 NoSQL 數據庫服務，適合所有需要一致性且延遲低於 10 毫秒的隨意規模的應用程序。它是全然託管的雲數據庫，支持文檔和鍵值存儲模型。

其靈活的數據模型和可靠的性能令其成爲移動、Web、遊戲、廣告技術、物聯網和衆多其它應用的不二之選。

 

Amazon DynamoDB 優點

 

高速穩定的性能

Amazon DynamoDB 旨在爲所有應用程序提供高速穩定、規模彈性的性能。服務端平均延遲一般不超過十毫秒。

隨着您的數據卷增多。應用程序性能要求添加，Amazon DynamoDB 使用本身主動分區和 SSD 技術來知足您的吞吐量需求。以隨意規模提供低延遲。

高度可擴展

建立表時，僅僅需指定所需的請求容量就能夠。假設您的應用吞吐量需求發生變化，僅僅需使用 AWS 管理控制檯或 Amazon DynamoDB API 調用更新表的請求容量就能夠。雖然 Amazon DynamoDB 在後臺管理所有的擴展工做，您仍然可以在擴展進行過程當中達成您的優先吞吐量等級。

 

 

靈活

Amazon DynamoDB 支持文檔和鍵值數據結構，您可以靈活地設計最適合您的應用程序的最佳架構。 

 

精細訪問控制

Amazon DynamoDB 與 AWS Identity and Access Management (IAM) 集成，對組織內的用戶實現精細的訪問控制。

您可以爲每名用戶分配惟一的安全證書，控制每名用戶對服務和資源的訪問。

 

全然託管

Amazon DynamoDB 是全然託管的雲 NoSQL 數據庫服務。您僅僅需建立數據庫表並設置吞吐量，其他事情都交由該服務來代勞。您無需再操心數據庫管理任務。好比硬件或軟件配置、建立設置和配置、軟件更新、操做可靠的分佈式數據庫集羣，或者隨着擴展需要在多個實例間對數據進行分區等問題，您僅僅需盡享 Amazon DynamoDB 服務之大成。

（4）FaceBook圖形數據庫TAO

在Facebook上，人們已經造成了一個複雜的社會關係網絡，怎樣去存儲、擴展和展現這個網絡是Facebookproject師的一大難題。

早在幾年前。Facebook的project師就意識到：關係型數據庫的老方法。正在逐步減小基礎設施和代碼的效率。2009年。他們開始設計一種新的數據庫體系結構，也就是分佈式數據庫TAO（The Associations and Objects）。6月25日，Facebook在官方博客上發佈了支持其基礎設施細節。

Facebook的軟件project師Mark Marchukov在博客中表示他們之因此建立TAO的緣由之中的一個在於同一時候使用MySQL和Memcached讀取數據太複雜了。產品project師要工做在兩種全然不一樣的數據模型之間：大規模的MySQLserver用關係表存儲持久數據，相似數量的緩存數據server用來存儲SQL查詢到的鍵值對。即使是封裝在數據訪問庫中最多見的操做，也需要產品project師對系統內部有充分的瞭解，才幹高效地使用memcache-MySQL組合。

TAO的圖型架構在信息組織方面相似於Facebook的圖搜索工具。它將世界看做由節點（對象，即人、地點和事物）和邊（關聯，即他們之間的關係）組成的圖。

隨着數據量的增大，保持數據的關係模式變得再也不重要，TAO及其相應的API應運而生。

Marchukov以爲TAO最大的突破在於實現了圖解模型，Facebook的主要工做負載在於讀取數據。TAO證實了圖數據模型很是適合這類查詢操做較多的站點。實際上。相似Neo4j的圖形數據庫一直備受關注，因爲它能有效表示人際關係。 

Marchukov 在博客中提到，TAO不只大規模實現了圖數據結構，也使用MySQL實現硬盤上的持久存儲，同一時候要保證數據在各個數據中心的終於一致性。用戶才幹獲取「新奇事」。

TAO服務執行在大量的server集羣上，這些分佈在不一樣地理位置的集羣構成一個樹形網絡。有另外的集羣用來持久存儲對象和對象關聯，RAM和閃存實現緩存。這樣的分層結構在單獨進行不一樣類型的集羣擴展時更方便，也能有效利用server硬件。

（5）Google Spanner簡單介紹

Spanner 是Google的全球級的分佈式數據庫 (Globally-Distributed Database) 。

Spanner的擴展性達到了使人咋舌的全球級。可以擴展到數百萬的機器，數已百計的數據中心，上萬億的行。

更給力的是，除了誇張的擴展性以外。他還能 同一時候經過同步複製和多版本號來知足外部一致性，可用性也是很是好的。衝破CAP的枷鎖，在三者之間完美平衡。

Spanner是個可擴展，多版本號。全球分佈式還支持同步複製的數據庫。

他是Google的第一個可以全球擴展並且支持外部一致的事務。Spanner能 作到這些，離不開一個用GPS和原子鐘實現的時間API。這個API能將數據中心之間的時間同步精確到10ms之內。所以有幾個給力的功能：無鎖讀事務， 原子schema改動，讀歷史數據無block。

 

如下主要是Spanner的背景，設計和併發控制。

Spanner背景

要搞清楚Spanner原理，先得了解Spanner在Google的定位。

從上圖可以看到。Spanner位於F1和GFS之間。承上啓下。因此先提一提F1和GFS。

F1

和衆多互聯網公司同樣。在早期Google大量使用了Mysql。

Mysql是單機的，可以用Master-Slave來容錯。分區來擴展。

但是需 要大量的手工運維工做。有很是多的限制。所以Google開發了一個可容錯可擴展的RDBMS——F1。和通常的分佈式數據庫不一樣。F1相應RDMS應有的 功能，絕不妥協。起初F1是基於Mysql的，只是會逐漸遷移到Spanner。

F1有例如如下特色：

·        7×24高可用。

哪怕某一個數據中心中止運轉，仍然可用。

·        可以同一時候提供強一致性和弱一致。

·        可擴展

·        支持SQL

·        事務提交延遲50-100ms。讀延遲5-10ms，高吞吐

衆所周知Google BigTable是重要的NoSql產品，提供很是好的擴展性，開源世界有HBase與之相應。爲何Google還需要F1。而不是都使用 BigTable呢？因爲BigTable提供的終於一致性。一些需要事務級別的應用沒法使用。同一時候BigTable仍是NoSql，而大量的應用場景需 要有關係模型。就像現在大量的互聯網企業都使用Mysql而不肯意使用HBase，所以Google纔有這個可擴展數據庫的F1。

而Spanner就是 F1的相當重要的底層存儲技術。

Colossus（GFS II）

Colossus也是一個不得不提起的技術。他是第二代GFS。相應開源世界的新HDFS。

GFS是著名的分佈式文件系統。

初代GFS是爲批處理設計的。對於大文件很是友好。吞吐量很是大，但是延遲較高。因此使用他的系統不得不正確GFS作各類優化。才幹得到良好的性能。那爲何 Google沒有考慮到這些問題，設計出更完美的GFS ?因爲那個時候是2001年。Hadoop出生是在2007年。假設Hadoop是世界率先水平的話。GFS比世界率先水平還率先了6年。

相同的 Spanner出生大概是2009年。現在咱們看到了論文，預計Spanner在Google已經很是無缺，同一時候Google內部已經有更先進的替代技術在 醞釀了。

筆者預測，最先在2015年纔會出現Spanner和F1的山寨開源產品。

Colossus是第二代GFS。Colossus是Google重要的基礎設施，因爲他可以知足主流應用對FS的要求。

Colossus的重要改進有：

·      優雅Master容錯處理 (再也不有2s的中止服務時間)

·        Chunk大小僅僅有1MB (對小文件很是友好)

·        Master可以存儲不少其它的Metadata(當Chunk從64MB變爲1MB後，Metadata會擴大64倍。但是Google也攻克了)

Colossus可以本身主動分區Metadata。使用Reed-Solomon算法來複制，可以將原先的3份減少到1.5份，提升寫的性能，減小延遲。client來複制數據。詳細細節筆者也猜不出。

 

與BigTable， Megastore對照

Spanner主要致力於跨數據中心的數據複製上，同一時候也能提供數據庫功能。在Google相似的系統有BigTable和Megastore。和這二者相比，Spanner又有什麼優點呢。

BigTable在Google獲得了普遍的使用，但是他不能提供較爲複雜的Schema，還有在跨數據中心環境下的強一致性。

Megastore 有類RDBMS的數據模型。同一時候也支持同步複製。但是他的吞吐量太差，不能適應應用要求。Spanner再也不是相似BigTable的版本號化 key-value存儲，而是一個「暫時多版本號」的數據庫。

何爲「暫時多版本號」，數據是存儲在一個版本號化的關係表裏面，存儲的時間數據會依據其提交的時間 打上時間戳，應用可以訪問到較老的版本號，另外老的版本號也會被垃圾回收掉。

Google官方以爲 Spanner是下一代BigTable。也是Megastore的繼任者。

 

Google Spanner設計

功能

從高層看Spanner是經過Paxos狀態機將分區好的數據分佈在全球的。數據複製全球化的。用戶可以指定數據複製的份數和存儲的地點。 Spanner可以在集羣或者數據發生變化的時候將數據遷移到合適的地點，作負載均衡。用戶可以指定將數據分佈在多個數據中心，只是不少其它的數據中心將形成 不少其它的延遲。

用戶需要在可靠性和延遲之間作權衡，通常來講複製1。2個數據中心足以保證可靠性。

做爲一個全球化分佈式系統，Spanner提供一些有趣的特性。

·        應用可以細粒度的指定數據分佈的位置。精確的指定數據離用戶有多遠，可以有效的控制讀延遲(讀延遲取決於近期的拷貝)。指定數據拷貝之間有多遠，可以控制 寫的延遲(寫延遲取決於最遠的拷貝)。還要數據的複製份數，可以控制數據的可靠性和讀性能。(多寫幾份，可以抵禦更大的事故)

·        Spanner還有兩個通常分佈式數據庫不具有的特性：讀寫的外部一致性。基於時間戳的全局的讀一致。這兩個特性可以讓Spanner支持一致的備份，一致的MapReduce，還有原子的Schema改動。

這寫特性都得益有Spanner有一個全球時間同步機制。可以在數據提交的時候給出一個時間戳。因爲時間是系列化的，因此纔有外部一致性。

這個很是easy理解，假設有兩個提交，一個在T1,一個在T2。那有更晚的時間戳那個提交是正確的。

這個全球時間同步機制是用一個具備GPS和原子鐘的TrueTime API提供了。這個TrueTime API可以將不一樣數據中心的時間誤差縮短在10ms內。這個API可以提供一個精確的時間。同一時候給出偏差範圍。

Google已經有了一個TrueTime API的實現。筆者認爲這個TrueTimeAPI 很是有意義。假設能單獨開源這部分的話，很是多數據庫如MongoDB都可以從中受益。

體系結構

Spanner由於是全球化的，因此有兩個其它分佈式數據庫沒有的概念。

·        Universe。一個Spanner部署實例稱之爲一個Universe。

眼下全世界有3個。一個開發，一個測試。一個線上。因爲一個Universe就能覆蓋全球，不需要多個。

·        Zones. 每個Zone至關於一個數據中心，一個Zone內部物理上必須在一塊兒。而一個數據中心可能有多個Zone。

可以在執行時加入移除Zone。

一個Zone可以理解爲一個BigTable部署實例。

 

如圖所看到的。一個Spanner有上面一些組件。

實際的組件確定不止這些。比方TrueTime API Server。

假設只知道這些知識。來構建Spanner是遠遠不夠的。

但Google都略去了。那筆者就簡要介紹一下。

·        Universemaster: 監控這個universe裏zone級別的狀態信息

·        Placement driver：提供跨區數據遷移時管理功能

·        Zonemaster：至關於BigTable的Master。管理Spanserver上的數據。

·        Location proxy：存儲數據的Location信息。client要先訪問他才知道數據在那個Spanserver上。

·        Spanserver：至關於BigTable的ThunkServer。用於存儲數據。

可以看出來這裏每個組件都很是有料。但是Google的論文裏僅僅具體介紹了Spanserver的設計，筆者也僅僅能介紹到這裏。如下具體闡述Spanserver的設計。

 

Spanserver

本章具體介紹Spanserver的設計實現。

Spanserver的設計和BigTable很的類似。

參照下圖

從下往上看。

每個數據中心會執行一套Colossus (GFS II) 。每個機器有100-1000個tablet。Tablet概念上將至關於數據庫一張表裏的一些行。物理上是數據文件。打個例如，一張1000行的表。有 10個tablet，第1-100行是一個tablet，第101-200是一個tablet。

但和BigTable不一樣的是BigTable裏面的 tablet存儲的是Key-Value都是string，Spanner存儲的Key多了一個時間戳：

(Key: string, timestamp: int64) ->string。

所以spanner天生就支持多版本號。tablet在文件系統中是一個B-tree-like的文件和一個write-ahead日誌。

每個Tablet上會有一個Paxos狀態機。Paxos是一個分佈式一致性協議。Table的元數據和log都存儲在上面。

Paxos會選出一個 replica作leader。這個leader的壽命默認是10s,10s後重選。Leader就至關於複製數據的master，其它replica的 數據都是從他那裏複製的。讀請求可以走隨意的replica。但是寫請求僅僅有去leader。這些replica統稱爲一個paxos group。

每個leader replica的spanserver上會實現一個lock table還管理併發。

Lock table記錄了兩階段提交需要的鎖信息。但是不管是在Spanner仍是在BigTable上。但遇到衝突的時候長時間事務會將性能很是差。

因此有一些操 做，如事務讀可以走lock table，其它的操做可以繞開lock table。

每個leader replica的spanserver上另外一個transaction manager。假設事務在一個paxos group裏面，可以繞過transaction manager。但是一旦事務跨多個paxos group，就需要transaction manager來協調。當中一個Transactionmanager被選爲leader，其它的是slave聽他指揮。這樣可以保證事務。

 

Directories and Placement

之因此Spanner比BigTable有更強的擴展性。在於Spanner另外一層抽象的概念directory, directory是一些key-value的集合。一個directory裏面的key有同樣的前綴。更穩當的叫法是bucketing。 Directory是應用控制數據位置的最小單元。可以經過慎重的選擇Key的前綴來控制。據此筆者可以猜出，在設計初期，Spanner是做爲F1的存 儲系統而設立，甚至還設計有相似directory的層次結構。這種層次有很是多優勢，但是實現太複雜被摒棄了。

Directory做爲數據放置的最小單元。可以在paxos group裏面移來移去。

Spanner移動一個directory通常出於例如如下幾個緣由：

·        一個paxos group的負載太大，需要切分

·        將數據移動到access更近的地方

·        將經常同一時候訪問的directory放到一個paxos group裏面

Directory可以在不影響client的前提下，在後臺移動。移動一個50MB的directory大概需要的幾秒鐘。

那麼directory和tablet又是什麼關係呢。可以理解爲Directory是一個抽象的概念，管理數據的單元；而tablet是物理的東 西。數據文件。

由於一個Paxos group可能會有多個directory，因此spanner的tablet實現和BigTable的tablet實現有些不一樣。BigTable的 tablet是單個順序文件。Google有個項目，名爲Level DB。是BigTable的底層，可以看到事實上現細節。而Spanner的tablet可以理解是一些基於行的分區的容器。

這樣就可以將一些經常同一時候訪問 的directory放在一個tablet裏面，而不用太在乎順序關係。

在paxos group之間移動directory是後臺任務。

這個操做還被用來移動replicas。移動操做設計的時候不是事務的，因爲這樣會形成大量的讀寫 block。操做的時候是先將實際數據移動到指定位置，而後再用一個原子的操做更新元數據，完畢整個移動過程。

Directory仍是記錄地理位置的最小單元。

數據的地理位置是由應用決定的，配置的時候需要指定複製數目和類型，還有地理的位置。比方(上海。 複製2份。南京複製1分) 。

這樣應用就可以依據用戶指定終端用戶實際狀況決定的數據存儲位置。比方中國隊的數據在亞洲有3份拷貝, 日本隊的數據全球都有拷貝。

前面對directory仍是被簡化過的。還有很是多沒法詳述。

 

數據模型

Spanner的數據模型來自於Google內部的實踐。在設計之初。Spanner就決心有下面的特性：

·        支持相似關係數據庫的schema

·        Query語句

·        支持廣義上的事務

爲什麼會這樣決定呢？在Google內部另外一個Megastore，雖然要忍受性能不夠的折磨，但是在Google有300多個應用在用它，因爲 Megastore支持一個相似關係數據庫的schema，而且支持同步複製 (BigTable僅僅支持終於一致的複製) 。使用Megastore的應用有大名鼎鼎的Gmail, Picasa, Calendar, Android Market和AppEngine。 而必須對Query語句的支持，來自於廣受歡迎的Dremel，筆者不久前寫了篇文章來介紹他。 最後對事務的支持是比不可少了，BigTable在Google內部被抱怨的最多的就是其僅僅能支持行事務。再大粒度的事務就無能爲力了。Spanner的 開發人員以爲，過分使用事務形成的性能降低的惡果。應該由應用的開發人員承擔。

應用開發人員在使用事務的時候，必須考慮到性能問題。而數據庫必須提供事務機制。 而不是因爲性能問題，就乾脆不提供事務支持。

數據模型是創建在directory和key-value模型的抽象之上的。一個應用可以在一個universe中創建一個或多個 database。在每個database中創建隨意的table。Table看起來就像關係型數據庫的表。

有行，有列。還有版本號。Query語句看起來 是多了一些擴展的SQL語句。

Spanner的數據模型也不是純正的關係模型，每一行都必須有一列或多列組件。

看起來仍是Key-value。

主鍵組成Key,其它的列是Value。但這種設計相應用也是很是有裨益的。應用可以經過主鍵來定位到某一行。

上圖是一個樣例。對於一個典型的相冊應用，需要存儲其用戶和相冊。可以用上面的兩個SQL來建立表。Spanner的表是層次化的，最頂層的表是 directory table。

其它的表建立的時候。可以用interleave in parent來什麼層次關係。這種結構，在實現的時候，Spanner可以將嵌套的數據放在一塊兒，這樣在分區的時候性能會提高很是多。不然Spanner 沒法獲知最重要的表之間的關係。

 

TrueTime

TrueTime API 是一個頗有創意的東西，可以同步全球的時間。上表就是TrueTime API。

TT.now()可以得到一個絕對時間TTinterval。這個值和UnixTime是一樣的。同一時候還可以獲得一個偏差e。 TT.after(t)和TT.before(t)是基於TT.now()實現的。

那這個TrueTime API實現靠的是GFS和原子鐘。之因此要用兩種技術來處理，是因爲致使這兩個技術的失敗的緣由是不一樣的。GPS會有一個天線。電波干擾會致使其失靈。原子鐘很是穩定。當GPS失靈的時候。原子鐘仍然能保證在至關長的時間內，不會出現誤差。

實際部署的時候。每個數據中心需要部署一些Master機器，其它機器上需要有一個slave進程來從Master同步。有的Master用 GPS，有的Master用原子鐘。這些Master物理上分佈的比較遠，怕出現物理上的干擾。比方假設放在一個機架上，機架被人碰倒了。就全宕了。另外 原子鐘不是並非常貴。Master本身還會不斷比對，新的時間信息還會和Master自身時鐘的比對，會排除掉誤差比較大的，並得到一個保守的結果。

終於 GPS master提供時間準確度很是高，偏差接近於0。

每個Slave後臺進程會每個30秒從若干個Master更新本身的時鐘。爲了減小偏差，使用Marzullo算法。

每個slave還會計算出本身的偏差。這裏的偏差包含的通訊的延遲，機器的負載。

假設不能訪問Master，偏差就會越走越大。知道又一次可以訪問。

 

Google Spanner併發控制

Spanner使用TrueTime來控制併發。實現外部一致性。

支持下面幾種事務。

·        讀寫事務

·        僅僅讀事務

·        快照讀，client提供時間戳

·        快照讀。client提供時間範圍

好比一個讀寫事務發生在時間t，那麼在全世界不論什麼一個地方，指定t快照讀都可以讀到寫入的值。

上表是Spanner現在支持的事務。

單獨的寫操做都被實現爲讀寫事務 ； 單獨的非快照被實現爲僅僅讀事務。事務總有失敗的時候，假設失敗。對於這兩種操做會本身重試。無需應用本身實現重試循環。

時間戳的設計大大提升了僅僅讀事務的性能。事務開始的時候，要聲明這個事務裏沒有寫操做。僅僅讀事務可不是一個簡單的沒有寫操做的讀寫事務。

它會用一個 系統時間戳去讀。因此對於同一時候的其它的寫操做是沒有Block的。而且僅僅讀事務可以在隨意一臺已經更新過的replica上面讀。

對於快照讀操做，可以讀取曾經的數據。需要client指定一個時間戳或者一個時間範圍。

Spanner會找到一個已經充分更新好的replica上讀取。

另外一個有趣的特性的是，對於僅僅讀事務，假設運行到一半，該replica出現了錯誤。

client沒有必要在本地緩存剛剛讀過的時間，因爲是依據時間戳讀取的。

僅僅要再用剛剛的時間戳讀取，就可以得到同樣的結果。

 

讀寫事務

正如BigTable同樣，Spanner的事務是會將所有的寫操做先緩存起來。在Commit的時候一次提交。這種話，就讀不出在同一個事務中寫的數據了。只是這沒有關係。因爲Spanner的數據都是有版本號的。

在讀寫事務中使用wound-wait算法來避免死鎖。當client發起一個讀寫事務的時候，首先是讀操做，他先找到相關數據的leader replica。而後加上讀鎖。讀取近期的數據。在client事務存活的時候會不斷的向leader發心跳，防止超時。當client完畢了所有的讀操做。並且緩存 了所有的寫操做，就開始了兩階段提交。client閒置一個coordinator group，並給每一個leader發送coordinator的id和緩存的寫數據。

leader首先會上一個寫鎖。他要找一個比現有事務晚的時間戳。

經過Paxos記錄。每一個相關的都要給coordinator發送他本身準備的那個時間戳。

Coordinatorleader一開始也會上個寫鎖。當你們發送時間戳給他以後，他就選擇一個提交時間戳。這個提交的時間戳，必須比剛剛的所有時間戳晚，而且還要比TT.now()+偏差時間 還有晚。這個Coordinator將這個信息記錄到Paxos。

在讓replica寫入數據生效以前，coordinator還有再等一會。需要等兩倍時間偏差。這段時間也恰好讓Paxos來同步。因爲等待之 後。在隨意機器上發起的下一個事務的開始時間，都比方不會比這個事務的結束時間早了。

而後coordinator將提交時間戳發送給client還有其它的 replica。他們記錄日誌，寫入生效，釋放鎖。

 

僅僅讀事務

對於僅僅讀事務，Spanner首先要指定一個讀事務時間戳。還需要了解在這個讀操做中，需要訪問的所有的讀的Key。Spanner可以本身主動肯定Key的範圍。

假設Key的範圍在一個Paxos group內。client可以發起一個僅僅讀請求給group leader。leader選一個時間戳，這個時間戳要比上一個事務的結束時間要大。

而後讀取對應的數據。這個事務可以知足外部一致性。讀出的結果是最後 一次寫的結果，並且不會有不一致的數據。

假設Key的範圍在多個Paxos group內。就相對複雜一些。當中一個比較複雜的樣例是。可以遍歷所有的group leaders，尋找近期的事務發生的時間。並讀取。client僅僅要時間戳在TT.now().latest以後就可以知足要求了。 

 

參考文獻：

1、《挑戰傳統關係型數據庫：FaceBook圖形數據庫TAO揭祕》 Jordan Novet

2、《雲時代的分佈式數據庫：阿里分佈式數據庫服務DRDS》 沈詢

3、《大數據與雲計算》李永紅

4、《基於雲計算的數據庫分析》 謝紅 

5、《全球級的分佈式數據庫Google Spanner原理》