Google Spanner (中文版)
舒適提示：本論文由廈門大學計算機系林子雨翻譯自英文論文，轉載請註明出處，僅用於學習交流，請勿用於商業用途。前端
[本文翻譯的原始出處：廈門大學計算機係數據庫實驗室網站林子雨老師的雲數據庫技術資料專區http://dblab.xmu.edu.cn/topic/research/documentation/cloud_database/]算法
[林子雨翻譯的與Goolge Spanner緊密相關的學術文章推薦] Google Bigtable（中文版）數據庫
[Google2012] James C. Corbett, Jeffrey Dean, Michael Epstein, etc. Spanner: Google’s Globally-Distributed Database.OSDI’2012.編程
Spanner: Google’s Globally-Distributed Database緩存
James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes, Christopher Frost, JJ Furman,Sanjay Ghemawat, Andrey Gubarev, Christopher Heiser, Peter Hochschild, Wilson Hsieh, Sebastian Kanthak, Eugene Kogan, Hongyi Li, Alexander Lloyd, Sergey Melnik, David Mwaura, David Nagle, Sean Quinlan, Rajesh Rao, Lindsay Rolig, Yasushi Saito, Michal Szymaniak, Christopher Taylor, Ruth Wang, Dale Woodford服務器
Google Inc.網絡
本文翻譯：廈門大學計算機系 林子雨（http://www.cs.xmu.edu.cn/linziyu） 翻譯時間：2012年9月17日-21日數據結構
[請到本網頁的底部的「附件」中下載：Google Spanner的英文版原文和中文版的PDF文件]架構
Google Spanner (中文版)
摘要：Spanner是谷歌公司研發的、可擴展的、多版本、全球分佈式、同步複製數據庫。它是第一個把數據分佈 在全球範圍內的系統，而且支持外部一致性的分佈式事務。本文描述了Spanner的架構、特性、不一樣設計決策的背後機理和一個新的時間API，這個API 能夠暴露時鐘的不肯定性。這個API及其實現，對於支持外部一致性和許多強大特性而言，是很是重要的，這些強大特性包括：非阻塞的讀、不採用鎖機制的只讀 事務、原子模式變動。併發
中文關鍵詞：谷歌，分佈式數據庫
英文關鍵詞: Google, Spanner, Bigtable, Distributed Database
全文目錄結構
1. 介紹
2. 實現
2.1 Spanserver軟件棧
2.2 目錄和放置
2.3 數據模型
3. TrueTime
4. 併發控制
4.1 時間戳管理
4.2 細節
5. 實驗分析
5.1 微測試基準
5.2 可用性
5.3 TrueTime
5.4 F1
6. 相關工做
7. 將來的工做
8. 總結
致謝
參考文獻
1 介紹
Spanner是一個可擴展的、全球分佈式的數據庫，是在谷歌公司設計、開發和部署的。在最高抽象層面，Spanner就是一個數據庫，把數據分片 存儲在許多Paxos[21]狀態機上，這些機器位於遍及全球的數據中心內。複製技術能夠用來服務於全球可用性和地理局部性。客戶端會自動在副本之間進行 失敗恢復。隨着數據的變化和服務器的變化，Spanner會自動把數據進行從新分片，從而有效應對負載變化和處理失敗。Spanner被設計成能夠擴展到 幾百萬個機器節點，跨越成百上千個數據中心，具有幾萬億數據庫行的規模。
應用能夠藉助於Spanner來實現高可用性，經過在一個洲的內部和跨越不一樣的洲之間複製數據，保證即便面對大範圍的天然災害時數據依然可用。咱們最初的 客戶是F1[35]，一個谷歌廣告後臺的從新編程實現。F1使用了跨越美國的5個副本。絕大多數其餘應用極可能會在屬於同一個地理範圍內的3-5個數據中 心內放置數據副本，採用相對獨立的失敗模式。也就是說，許多應用都會首先選擇低延遲，而不是高可用性，只要系統可以從1-2個數據中心失敗中恢復過來。
Spanner的主要工做，就是管理跨越多個數據中心的數據副本，可是，在咱們的分佈式系統體系架構之上設計和實現重要的數據庫特性方面，咱們也花 費了大量的時間。儘管有許多項目能夠很好地使用BigTable[9]，咱們也不斷收到來自客戶的抱怨，客戶反映BigTable沒法應用到一些特定類型 的應用上面，好比具有複雜可變的模式，或者對於在大範圍內分佈的多個副本數據具備較高的一致性要求。其餘研究人員也提出了相似的抱怨[37]。谷歌的許多 應用已經選擇使用Megastore[5]，主要是由於它的半關係數據模型和對同步複製的支持，儘管Megastore具有較差的寫操做吞吐量。因爲上述 多個方面的因素，Spanner已經從一個相似BigTable的單一版本的鍵值存儲，演化成爲一個具備時間屬性的多版本的數據庫。數據被存儲到模式化 的、半關係的表中，數據被版本化，每一個版本都會自動以提交時間做爲時間戳，舊版本的數據會更容易被垃圾回收。應用能夠讀取舊版本的數據。Spanner支 持通用的事務，提供了基於SQL的查詢語言。
做爲一個全球分佈式數據庫，Spanner提供了幾個有趣的特性：第一，在數據的副本配置方面，應用能夠在一個很細的粒度上進行動態控制。應用能夠 詳細規定，哪些數據中心包含哪些數據，數據距離用戶有多遠（控制用戶讀取數據的延遲），不一樣數據副本之間距離有多遠（控制寫操做的延遲），以及須要維護多 少個副本（控制可用性和讀操做性能）。數據也能夠被動態和透明地在數據中心之間進行移動，從而平衡不一樣數據中心內資源的使用。第二，Spanner有兩個 重要的特性，很難在一個分佈式數據庫上實現，即Spanner提供了讀和寫操做的外部一致性，以及在一個時間戳下面的跨越數據庫的全球一致性的讀操做。這 些特性使得Spanner能夠支持一致的備份、一致的MapReduce執行[12]和原子模式變動，全部都是在全球範圍內實現，即便存在正在處理中的事 務也能夠。
之因此能夠支持這些特性，是由於Spanner能夠爲事務分配全球範圍內有意義的提交時間戳，即便事務多是分佈式的。這些時間戳反映了事務序列化 的順序。除此之外，這些序列化的順序知足了外部一致性的要求：若是一個事務T1在另外一個事務T2開始以前就已經提交了，那麼，T1的時間戳就要比T2的時 間戳小。Spanner是第一個能夠在全球範圍內提供這種保證的系統。
實現這種特性的關鍵技術就是一個新的TrueTime API及其實現。這個API能夠直接暴露時鐘不肯定性，Spanner時間戳的保證就是取決於這個API實現的界限。若是這個不肯定性很 大，Spanner就下降速度來等待這個大的不肯定性結束。谷歌的簇管理器軟件提供了一個TrueTime API的實現。這種實現能夠保持較小的不肯定性（一般小於10ms），主要是藉助於現代時鐘參考值（好比GPS和原子鐘）。
第2部分描述了Spanner實現的結構、特性集和工程方面的決策；第3部分介紹咱們的新的TrueTime API，而且描述了它的實現；第4部分描述了Spanner如何使用TrueTime來實現外部一致性的分佈式事務、不用鎖機制的只讀事務和原子模式更 新。第5部分提供了測試Spanner性能和TrueTime行爲的測試基準，並討論了F1的經驗。第六、7和8部分討論了相關工做，並給出總結。
2 實現
本部份內容描述了Spanner的結構和背後的實現機理，而後描述了目錄抽象，它被用來管理副本和局部性，並介紹了數據的轉移單位。最後，將討論我 們的數據模型，從而說明，爲何Spanner看起來更加像一個關係數據庫，而不是一個鍵值數據庫；還會討論應用如何能夠控制數據的局部性。
一個Spanner部署稱爲一個universe。假設Spanner在全球範圍內管理數據，那麼，將會只有可數的、運行中的universe。咱們當前正在運行一個測試用的universe，一個部署/線上用的universe和一個只用於線上應用的universe。
Spanner被組織成許多個zone的集合，每一個zone都大概像一個BigTable服務器的部署。zone是管理部署的基本單元。zone的 集合也是數據能夠被複制到的位置的集合。當新的數據中心加入服務，或者老的數據中心被關閉時，zone能夠被加入到一個運行的系統中，或者從中移除。 zone也是物理隔離的單元，在一個數據中心中，可能有一個或者多個zone，例如，屬於不一樣應用的數據可能必須被分區存儲到同一個數據中心的不一樣服務器 集合中。
圖1顯示了在一個Spanner的universe中的服務器。一個zone包括一個zonemaster，和一百至幾千個spanserver。 Zonemaster把數據分配給spanserver，spanserver把數據提供給客戶端。客戶端使用每一個zone上面的location proxy來定位能夠爲本身提供數據的spanserver。Universe master和placement driver，當前都只有一個。Universe master主要是一個控制檯，它顯示了關於zone的各類狀態信息，能夠用於相互之間的調試。Placement driver會週期性地與spanserver進行交互，來發現那些須要被轉移的數據，或者是爲了知足新的副本約束條件，或者是爲了進行負載均衡。
2.1 Spanserver軟件棧
本部份內容主要關注spanserver實現，來解釋複製和分佈式事務是如何被架構到咱們的基於BigTable的實現之上的。圖2顯示了軟件棧。 在底部，每一個spanserver負載管理100-1000個稱爲tablet的數據結構的實例。一個tablet就相似於BigTable中的 tablet，也實現了下面的映射：
(key:string, timestamp:int64)->string
與BigTable不一樣的是，Spanner會把時間戳分配給數據，這種很是重要的方式，使得Spanner更像一個多版本數據庫，而不是一個鍵值 存儲。一個tablet的狀態是存儲在相似於B-樹的文件集合和寫前(write-ahead)的日誌中，全部這些都會被保存到一個分佈式的文件系統中， 這個分佈式文件系統被稱爲Colossus，它繼承自Google File System。
爲了支持複製，每一個spanserver會在每一個tablet上面實現一個單個的Paxos狀態的機器。一個以前實現的Spanner能夠支持在每 個tablet上面實現多個Paxos狀態機，它能夠容許更加靈活的複製配置，可是，這種設計過於複雜，被咱們捨棄了。每一個狀態機器都會在相應的 tablet中保存本身的元數據和日誌。咱們的Paxos實現支持採用基於時間的領導者租約的長壽命的領導者，時間一般在0到10秒之間。當前的 Spanner實現中，會對每一個Paxos寫操做進行兩次記錄：一次是寫入到tablet日誌中，一次是寫入到Paxos日誌中。這種作法只是權宜之計， 咱們之後會進行完善。咱們在Paxos實現上採用了管道化的方式，從而能夠在存在廣域網延遲時改進Spanner的吞吐量，可是，Paxos會把寫操做按 照順序的方式執行。
Paxos狀態機是用來實現一系列被一致性複製的映射。每一個副本的鍵值映射狀態，都會被保存到相應的tablet中。寫操做必須在領導者上初始化 Paxos協議，讀操做能夠直接從底層的任何副本的tablet中訪問狀態信息，只要這個副本足夠新。副本的集合被稱爲一個Paxos group。
對於每一個是領導者的副本而言，每一個spanserver會實現一個鎖表來實現併發控制。這個鎖表包含了兩階段鎖機制的狀態：它把鍵的值域映射到鎖狀 態上面。注意，採用一個長壽命的Paxos領導者，對於有效管理鎖表而言是很是關鍵的。在BigTable和Spanner中，咱們都專門爲長事務作了設 計，好比，對於報表操做，可能要持續幾分鐘，當存在衝突時，採用樂觀併發控制機制會表現出不好的性能。對於那些須要同步的操做，好比事務型的讀操做，須要 得到鎖表中的鎖，而其餘類型的操做則能夠不理會鎖表。
對於每一個扮演領導者角色的副本，每一個spanserver也會實施一個事務管理器來支持分佈式事務。這個事務管理器被用來實現一個 participant leader，該組內的其餘副本則是做爲participant slaves。若是一個事務只包含一個Paxos組（對於許多事務而言都是如此），它就能夠繞過事務管理器，由於鎖表和Paxos兩者一塊兒能夠保證事務 性。若是一個事務包含了多於一個Paxos組，那些組的領導者之間會彼此協調合做完成兩階段提交。其中一個參與者組，會被選爲協調者，該組的 participant leader被稱爲coordinator leader，該組的participant slaves被稱爲coordinator slaves。每一個事務管理器的狀態，會被保存到底層的Paxos組。
2.2 目錄和放置
在一系列鍵值映射的上層，Spanner實現支持一個被稱爲「目錄」的桶抽象，也就是包含公共前綴的連續鍵的集合。（選擇「目錄」做爲名稱，主要是 因爲歷史沿襲的考慮，實際上更好的名稱應該是「桶」）。咱們會在第2.3節解釋前綴的源頭。對目錄的支持，可讓應用經過選擇合適的鍵來控制數據的局部 性。
一個目錄是數據放置的基本單元。屬於一個目錄的全部數據，都具備相同的副本配置。當數據在不一樣的Paxos組之間進行移動時，會一個目錄一個目錄地 轉移，如圖3所示。Spanner可能會移動一個目錄從而減輕一個Paxos組的負擔，也可能會把那些被頻繁地一塊兒訪問的目錄都放置到同一個組中，或者會 把一個目錄轉移到距離訪問者更近的地方。當客戶端操做正在進行時，也能夠進行目錄的轉移。咱們能夠預期在幾秒內轉移50MB的目錄。
一個Paxos組能夠包含多個目錄，這意味着一個Spanner tablet是不一樣於一個BigTable tablet的。一個Spanner tablet沒有必要是一個行空間內按照詞典順序連續的分區，相反，它能夠是行空間內的多個分區。咱們作出這個決定，是由於這樣作可讓多個被頻繁一塊兒訪 問的目錄被整合到一塊兒。
Movedir是一個後臺任務，用來在不一樣的Paxos組之間轉移目錄[14]。Movedir也用來爲Paxos組增長和刪除副本[25]，由於 Spanner目前還不支持在一個Paxos內部進行配置的變動。Movedir並非做爲一個事務來實現，這樣能夠避免在一個塊數據轉移過程當中阻塞正在 進行的讀操做和寫操做。相反，Movedir會註冊一個事實(fact)，代表它要轉移數據，而後在後臺運行轉移數據。當它幾乎快要轉移完指定數量的數據 時，就會啓動一個事務來自動轉移那部分數據，而且爲兩個Paxos組更新元數據。
一個目錄也是一個應用能夠指定的地理複製屬性（即放置策略）的最小單元。咱們的放置規範語言的設計，把管理複製的配置這個任務單獨分離出來。管理員 須要控制兩個維度：副本的數量和類型，以及這些副本的地理放置屬性。他們在這兩個維度裏面建立了一個命名選項的菜單。經過爲每一個數據庫或單獨的目錄增長這 些命名選項的組合，一個應用就能夠控制數據的複製。例如，一個應用可能會在本身的目錄裏存儲每一個終端用戶的數據，這就有可能使得用戶A的數據在歐洲有三個 副本，用戶B的數據在北美有5個副本。
爲了表達的清晰性，咱們已經作了儘可能簡化。事實上，當一個目錄變得太大時，Spanner會把它分片存儲。每一個分片可能會被保存到不一樣的Paxos組上（所以就意味着來自不一樣的服務器）。Movedir在不一樣組之間轉移的是分片，而不是轉移整個目錄。
2.3 數據模型
Spanner會把下面的數據特性集合暴露給應用：基於模式化的半關係表的數據模型，查詢語言和通用事務。支持這些特性的動機，是受到許多因素驅動 的。須要支持模式化的半關係表是由Megastore[5]的普及來支持的。在谷歌內部至少有300個應用使用Megastore（儘管它具備相對低的性 能），由於它的數據模型要比BigTable簡單，更易於管理，而且支持在跨數據中心層面進行同步複製。BigTable只能夠支持跨數據中心的最終事務 一致性。使用Megastore的著名的谷歌應用是Gmail,Picasa,Calendar,Android Market, AppEngine。在Spanner中須要支持SQL類型的查詢語言，也很顯然是很是必要的，由於Dremel[28]做爲交互式分析工具已經很是普 及。最後，在BigTable中跨行事務的缺少來致使了用戶頻繁的抱怨；Percolator[32]的開發就是用來部分解決這個問題的。一些做者都在抱 怨，通用的兩階段提交的代價過於昂貴，由於它會帶來可用性問題和性能問題[9][10][19]。咱們認爲，最好讓應用程序開發人員來處理因爲過分使用事 務引發的性能問題，而不是老是圍繞着「缺乏事務」進行編程。在Paxos上運行兩階段提交弱化了可用性問題。
應用的數據模型是架構在被目錄桶裝的鍵值映射層之上。一個應用會在一個universe中建立一個或者多個數據庫。每一個數據庫能夠包含無限數量的模 式化的表。每一個表都和關係數據庫表相似，具有行、列和版本值。咱們不會詳細介紹Spanner的查詢語言，它看起來很像SQL，只是作了一些擴展。
Spanner的數據模型不是純粹關係型的，它的行必須有名稱。更準確地說，每一個表都須要有包含一個或多個主鍵列的排序集合。這種需求，讓 Spanner看起來仍然有點像鍵值存儲：主鍵造成了一個行的名稱，每一個表都定義了從主鍵列到非主鍵列的映射。當一個行存在時，必需要求已經給行的一些鍵 定義了一些值（即便是NULL）。採用這種結構是頗有用的，由於這可讓應用經過選擇鍵來控制數據的局部性。
圖4包含了一個Spanner模式的實例，它是以每一個用戶和每一個相冊爲基礎存儲圖片元數據。這個模式語言和Megastore的相似，同時增長了額 外的要求，即每一個Spanner數據庫必須被客戶端分割成一個或多個表的層次結構（hierarchy）。客戶端應用會使用INTERLEAVE IN語句在數據庫模式中聲明這個層次結構。這個層次結構上面的表，是一個目錄表。目錄表中的每行都具備鍵K，和子孫表中的全部以K開始（以字典順序排序） 的行一塊兒，構成了一個目錄。ON DELETE CASCADE意味着，若是刪除目錄中的一個行，也會級聯刪除全部相關的子孫行。這個圖也解釋了這個實例數據庫的交織層次（interleaved layout），例如Albums(2,1)表明了來自Albums表的、對應於user_id=2和album_id=1的行。這種表的交織層次造成目 錄，是很是重要的，由於它容許客戶端來描述存在於多個表之間的位置關係，這對於一個分片的分佈式數據庫的性能而言是很重要的。沒有它的話，Spanner 就沒法知道最重要的位置關係。
3 TrueTime
本部份內容描述TrueTime API，並大概給出它的實現方法。咱們把大量細節內容放在另外一篇論文中，咱們的目標是展現這種API的力量。表1列出了API的方法。TrueTime會 顯式地把時間表達成TTinterval，這是一個時間區間，具備有界限的時間不肯定性（不像其餘的標準時間接口，沒有爲客戶端提供「不肯定性」這種概 念）。TTinterval區間的端點是TTstamp類型。TT.now()方法會 返回一個TTinterval，它能夠保證包含TT.now()方法在調用時的絕對時間。這個時間和具有閏秒塗抹（leap-second smearing）的UNIX時間同樣。把即時偏差邊界定義爲ε,平均偏差邊界爲（林子雨注：「ε上邊一個橫槓」，表示平均值）。TT.after()和 TT.before()方法是針對TT.now()的便捷的包裝器。
表示一個事件e的絕對時間，能夠利用函數tabs(e)。若是用更加形式化的術語，TrueTime能夠保證，對於一個調用tt=TT.now()，有tt.earliest≤tabs(enow)≤tt.latest，其中，是enow是調用的事件。
在底層，TrueTime使用的時間是GPS和原子鐘。TrueTime使用兩種類型的時間，是由於它們有不一樣的失敗模式。GPS參考時間的弱點是天線和 接收器失效、局部電磁干擾和相關失敗（好比設計上的缺陷致使沒法正確處理閏秒和電子欺騙），以及GPS系統運行中斷。原子鐘也會失效，不過失效的方式和 GPS無關，不一樣原子鐘之間的失效也沒有彼此關聯。因爲存在頻率偏差，在通過很長的時間之後，原子鐘都會產生明顯偏差。
TrueTime是由每一個數據中心上面的許多time master機器和每臺機器上的一個timeslave daemon來共同實現的。大多數master都有具有專用天線的GPS接收器，這些master在物理上是相互隔離的，這樣能夠減小天線失效、電磁干擾 和電子欺騙的影響。剩餘的master（咱們稱爲Armageddon master）則配備了原子鐘。一個原子鐘並非很昂貴：一個Armageddon master的花費和一個GPS master的花費是同一個數量級的。全部master的時間參考值都會進行彼此校對。每一個master也會交叉檢查時間參考值和本地時間的比值，若是二 者差異太大，就會把本身驅逐出去。在同步期間，Armageddon master會表現出一個逐漸增長的時間不肯定性，這是由保守應用的最差時鐘漂移引發的。GPS master表現出的時間不肯定性幾乎接近於0。
每一個daemon會從許多master[29]中收集投票，得到時間參考值，從而減小偏差。被選中的master中，有些master是GPS master，是從附近的數據中心得到的，剩餘的GPS master是從遠處的數據中心得到的；還有一些是Armageddon master。Daemon會使用一個Marzullo算法[27]的變種，來探測和拒絕欺騙，而且把本地時鐘同步到非撒謊master的時間參考值。爲 了免受較差的本地時鐘的影響，咱們會根據組件規範和運行環境肯定一個界限，若是機器的本地時鐘偏差頻繁超出這個界限，這個機器就會被驅逐出去。
在同步期間，一個daemon會表現出逐漸增長的時間不肯定性。ε是從保守應用的最差時鐘漂移中獲得的。ε也取決於time master的不肯定性，以及與time master之間的通信延遲。在咱們的線上應用環境中，ε一般是一個關於時間的鋸齒形函數。在每一個投票間隔中，ε會在1到7ms之間變化。所以，在大多數 狀況下，ε的平均值是4ms。Daemon的投票間隔，在當前是30秒，當前使用的時鐘漂移比率是200微秒/秒，兩者一塊兒意味着0到6ms的鋸齒形邊 界。剩餘的1ms主要來自到time master的通信延遲。在失敗的時候，超過這個鋸齒形邊界也是有可能的。例如，偶爾的time master不肯定性，可能會引發整個數據中心範圍內的ε值的增長。相似的，過載的機器或者網絡鏈接，都會致使ε值偶爾地局部增大。
4. 併發控制
本部份內容描述TrueTime如何能夠用來保證併發控制的正確性，以及這些屬性如何用來實現一些關鍵特性，好比外部一 致性的事務、無鎖機制的只讀事務、針對歷史數據的非阻塞讀。這些特性能夠保證，在時間戳爲t的時刻的數據庫讀操做，必定只能看到在t時刻以前已經提交的事 務。
進一步說，把Spanner客戶端的寫操做和Paxos看到的寫操做這兩者進行區分，是很是重要的，咱們把Paxos看到的寫操做稱爲Paxos寫操做。例如，兩階段提交會爲準備提交階段生成一個Paxos寫操做，這時不會有相應的客戶端寫操做。
4.1 時間戳管理
表2列出了Spanner支持的操做的類型。Spanner能夠支持讀寫事務、只讀事務（預先聲明的快照隔離事務）和快照讀。獨立寫操做，會被當成 讀寫事務來執行。非快照獨立讀操做，會被當成只讀事務來執行。兩者都是在內部進行retry，客戶端不用進行這種retry loop。
一個只讀事務具有快照隔離的性能優點[6]。一個只讀事務必須事先被聲明不會包含任何寫操做，它並非一個簡單的不包含寫操做的讀寫事務。在一個只讀事務 中的讀操做，在執行時會採用一個系統選擇的時間戳，不包含鎖機制，所以，後面到達的寫操做不會被阻塞。在一個只讀事務中的讀操做，能夠到任何足夠新的副本 上去執行（見第4.1.3節）。
一個快照讀操做，是針對歷史數據的讀取，執行過程當中，不須要鎖機制。一個客戶端能夠爲快照讀肯定一個時間戳，或者提供一個時間範圍讓Spanner來自動選擇時間戳。無論是哪一種狀況，快照讀操做均可以在任何具備足夠新的副本上執行。
對於只讀事務和快照讀而言，一旦已經選定一個時間戳，那麼，提交就是不可避免的，除非在那個時間點的數據已經被垃圾回收了。所以，客戶端沒必要在retry loop中緩存結果。當一個服務器失效的時候，客戶端就可使用一樣的時間戳和當前的讀位置，在另一個服務器上繼續執行讀操做。
4.2 細節
林子雨注：上面是Google Spanner（中文版）的核心內容，第4節「併發控制」的剩餘內容，沒有在網頁中給出，而是放在PDF文件中（請到本網頁的底部「附件」中下載PDF文件），由於，第4節「併發控制」的剩餘內容，公式太多，沒法放入網頁。並且，根據本人的閱讀，上述給出的內容已經能夠幫助讀者基本瞭解Google Spanner的概貌，剩餘的內容是一些瑣碎的細節，我的感受讀起來比較晦澀，若是不是深刻研究須要，能夠不用繼續閱讀第4節「併發控制」的剩餘內容。
5. 實驗分析
咱們對Spanner性能進行了測試，包括複製、事務和可用性。而後，咱們提供了一些關於TrueTime的實驗數據，而且提供了咱們的第一個用例——F1。
5.1 微測試基準
表3給出了一個用於Spanner的微測試基準(microbenchmark)。這些測試是在分時機器上實現的：每一個spanserver採用4GB內 存和四核CPU（AMD Barcelona 2200MHz）。客戶端運行在單獨的機器上。每一個zone都包含一個spanserver。客戶端和zone都放在一個數據中心集合內，它們之間的網絡 距離不會超過1ms。（這種佈局是很普通的，許多數據並不須要把數據分散存儲到全球各地）。測試數據庫具備50個Paxos組和2500個目錄。操做都是 獨立的4KB大小的讀和寫。All reads were served out of memory after a compaction，從而使得咱們只須要衡量Spanner調用棧的開銷。此外，還會進行一輪讀操做，來預熱任何位置的緩存。
對於延遲實驗而言，客戶端會發起足夠少許的操做，從而避免在服務器中發生排隊。從1個副本的實驗中，提交等待大約是5ms，Paxos延遲大約是9ms。 隨着副本數量的增長，延遲大約保持不變，只具備不多的標準差，由於在一個組的副本內，Paxos會並行執行。隨着副本數量的增長，得到指定投票數量的延 遲，對一個slave副本的慢速度不會很敏感。
對於吞吐量的實驗而言，客戶端發起足夠數量的操做，從而使得CPU處理能力達到飽和。快照讀操做能夠在任何足夠新的副本上進行，所以，快照讀的吞吐量會隨 着副本的數量增長而線性增長。單個讀的只讀事務，只會在領導者上執行，由於，時間戳分配必須發生在領導者上。只讀事務吞吐量會隨着副本數量的增長而增長， 由於有效的spanserver的數量會增長：在這個實驗的設置中，spanserver的數量和副本的數量相同，領導者會被隨機分配到不一樣的zone。 寫操做的吞吐量也會從這種實驗設置中得到收益（副本從3變到5時寫操做吞吐量增長了，就可以說明這點），可是，隨着副本數量的增長，每一個寫操做執行時須要 完成的工做量也會線性增長，這就會抵消前面的收益。
表4顯示了兩階段提交能夠擴展到合理數量的參與者：它是對一系列實驗的總結，這些實驗運行在3個zone上，每一個zone具備25個 spanserver。擴展到50個參與者，不管在平均值仍是第99個百分位方面，都是合理的。在100個參與者的情形下，延遲開始明顯增長。
5.2 可用性
圖5顯示了在多個數據中心運行Spanner時的可用性方面的收益。它顯示了三個吞吐量實驗的結果，而且存在數據中心失敗的情形，全部三個實驗結果都被重 疊放置到一個時間軸上。測試用的universe包含5個zone Zi，每一個zone都擁有25個spanserver。測試數據庫被分片成1250個Paxos組，100個客戶端不斷地發送非快照讀操做，累積速率是每 秒50K個讀操做。全部領導者都會被顯式地放置到Z1。每一個測試進行5秒鐘之後，一個zone中的全部服務器都會被「殺死」：non-leader殺掉 Z2，leader-hard殺掉Z1，leader-soft殺掉Z1，可是，它會首先通知全部服務器它們將要交出領導權。
殺掉Z2對於讀操做吞吐量沒有影響。殺掉Z1，給領導者一些時間來把領導權交給另外一個zone時，會產生一個小的影響：吞吐量會降低，不是很明顯，大概下 降3-4%。另外一方面，沒有預警就殺掉Z1有一個明顯的影響：完成率幾乎降低到0。隨着領導者被從新選擇，系統的吞吐量會增長到大約每秒100K個讀操 做，主要是因爲咱們的實驗設置：系統中有額外的能力，當找不到領導者時操做會排隊。由此致使的結果是，系統的吞吐量會增長直到到達系統恆定的速率。
咱們能夠看看把Paxos領導者租約設置爲10s的效果。當咱們殺掉這個zone，對於這個組的領導者租約的過時時間，會均勻地分佈到接下來的10秒鐘 內。來自一個死亡的領導者的每一個租約一旦過時，就會選擇一個新的領導者。大約在殺死時間過去10秒鐘之後，全部的組都會有領導者，吞吐量就恢復了。短的租 約時間會下降服務器死亡對於可用性的影響，可是，須要更多的更新租約的網絡通信開銷。咱們正在設計和實現一種機制，它能夠在領導者失效的時候，讓 slave釋放Paxos領導者租約。
5.3 TrueTime
關於TrueTime，必須回答兩個問題：ε是否就是時鐘不肯定性的邊界？ε會變得多糟糕？對於第一個問題，最嚴峻的問題就是，若是一個局部的時鐘 漂移大於200us/sec，那就會破壞TrueTime的假設。咱們的機器統計數據顯示，壞的CPU的出現機率要比壞的時鐘出現機率大6倍。也就是說， 與更加嚴峻的硬件問題相比，時鐘問題是不多見的。由此，咱們也相信，TrueTime的實現和Spanner其餘軟件組件同樣，具備很好的可靠性，值得信 任。
圖6顯示了TrueTime數據，是從幾千個spanserver中收集的，這些spanserver 跨越了多個數據中心，距離2200千米以上。圖中描述了ε的第90個、99個和99.9個百分位的狀況，是在對timemaster進行投票後當即對 timeslave daemon進行樣本抽樣的。這些抽樣數據沒有考慮因爲時鐘不肯定性帶來的ε值的鋸齒，所以測量的是timemaster不肯定性（一般是0）再加上通信 延遲。
圖6中的數據顯示了，在決定ε的基本值方面的上述兩個問題，一般都不會是個問題。可是，可能會存在明顯的拖尾延遲問題，那會引發更高的ε值。圖中，3月 30日拖尾延遲的下降，是由於網絡的改進，減小了瞬間網絡鏈接的擁堵。在4月13日ε的值增長了，持續了大約1個小時，主要是由於例行維護時關閉了兩個 time master。咱們會繼續調研而且消除引發TrueTime突變的因素。
5.4 F1
Spanner在2011年早期開始進行在線負載測試，它是做爲谷歌廣告後臺F1[35]的從新實現的一部分。這個後臺最開始是基於MySQL數據庫，在 許多方面都採用手工數據分區。未經壓縮的數據能夠達到幾十TB，雖然這對於許多NoSQL實例而言數據量是很小的，可是，對於採用數據分區的MySQL而 言，數據量是很是大的。MySQL的數據分片機制，會把每一個客戶和全部相關的數據分配給一個固定的分區。這種佈局方式，能夠支持針對單個客戶的索引構建和 複雜查詢處理，可是，須要瞭解一些商業知識來設計分區。隨着客戶數量的增加，對數據進行從新分區，代價是很大的。最近一次的從新分區，花費了兩年的時間， 爲了下降風險，在多個團隊之間進行了大量的合做和測試。這種操做太複雜了，沒法經常執行，由此致使的結果是，團隊必須限制MySQL數據庫的增加，方法 是，把一些數據存儲在外部的Bigtable中，這就會犧牲事務和查詢全部數據的能力。
F1團隊選擇使用Spanner有幾個方面的緣由。首先，Spanner不須要手工分區。其次，Spanner提供了同步複製和自動失敗恢復。在採用 MySQL的master-slave複製方法時，很難進行失敗恢復，會有數據丟失和當機的風險。再次，F1須要強壯的事務語義，這使得使用其餘 NoSQL系統是不實際的。應用語義須要跨越任意數據的事務和一致性讀。F1團隊也須要在他們的數據上構建二級索引（由於Spanner沒有提供對二級索 引的自動支持），也有能力使用Spanner事務來實現他們本身的一致性全球索引。
全部應用寫操做，如今都是默認從F1發送到Spanner。而不是發送到基於MySQL的應用棧。F1在美國的西岸有兩個副本，在東岸有三個副本。這種副 本位置的選擇，是爲了不發生天然災害時出現服務中止問題，也是出於前端應用的位置的考慮。實際上，Spanner的失敗自動恢復，幾乎是不可見的。在過 去的幾個月中，儘管有不在計劃內的機羣失效，可是，F1團隊最須要作的工做仍然是更新他們的數據庫模式，來告訴Spanner在哪裏放置Paxos領導 者，從而使得它們儘可能靠近應用前端。
Spanner時間戳語義，使得它對於F1而言，能夠高效地維護從數據庫狀態計算獲得的、放在內存中的數據結構。F1會爲全部變動都維護一個邏輯歷史日 志，它會做爲每一個事務的一部分寫入到Spanner。F1會獲得某個時間戳下的數據的完整快照，來初始化它的數據結構，而後根據數據的增量變化來更新這個 數據結構。
表5顯示了F1中每一個目錄的分片數量的分佈狀況。每一個目錄一般對應於F1上的應用棧中的一個用戶。絕大多數目錄（同時意味着絕大多數用戶）都只會包含一個 分片，這就意味着，對於這些用戶數據的讀和寫操做只會發生在一個服務器上。多於100個分片的目錄，是那些包含F1二級索引的表：對這些表的多個分片進行 寫操做，是極其不尋常的。F1團隊也只是在以事務的方式進行未經優化的批量數據加載時，纔會碰到這種情形。
表6顯示了從F1服務器來測量的Spanner操做的延遲。在東海岸數據中心的副本，在選擇Paxos領導者方面會得到更高的優先級。表6中的數據 是從這些數據中心的F1服務器上測量獲得的。寫操做延遲分佈上存在較大的標準差，是因爲鎖衝突引發的肥尾效應（fat tail）。在讀操做延遲分佈上存在更大的標準差，部分是由於Paxos領導者跨越了兩個數據中心，只有其中的一個是採用了固態盤的機器。此外，測試內容 還包括系統中的每一個針對兩個數據中心的讀操做：字節讀操做的平均值和標準差分別是1.6KB和119KB。
6. 相關工做
Megastore[5]和DynamoDB[3]已經提供了跨越多個數據中心的一致性複製。DynamoDB提供了鍵值存儲接口，只能在一個 region內部進行復制。Spanner和Megastore同樣，都提供了半關係數據模型，甚至採用了相似的模式語言。Megastore沒法得到高 性能。Megastore是架構在Bigtable之上，這帶來了很高的通信代價。Megastore也不支持長壽命的領導者，多個副本可能會發起寫操 做。來自不一樣副本的寫操做，在Paxos協議下必定會發生衝突，即便他們不會發生邏輯衝突：會嚴重影響吞吐量，在一個Paxos組內每秒鐘只能執行幾個寫 操做。Spanner提供了更高的性能，通用的事務和外部一致性。
Pavlo等人[31]對數據庫和MapReduce[12]的性能進行了比較。他們指出了幾個努力的方向，能夠在分佈式鍵值存儲之上充分利用數據庫的功 能[1][4][7][41]，兩者能夠實現充分的融合。咱們比較贊同這個結論，而且認爲集成多個層是具備優點的：把複製和併發控制集成起來，能夠減小 Spanner中的提交等待代價。
在一個採用了複製的存儲上面實現事務，能夠至少追述到Gifford的論文[16]。Scatter[17]是一個最近的基於DHT的鍵值存儲，能夠在一 致性複製上面實現事務。Spanner則要比Scatter在更高的層次上提供接口。Gray和Lamport[18]描述了一個基於Paxos的非阻塞 的提交協議，他們的協議會比兩階段提交協議帶來更多的代價，而兩階段提交協議在大範圍分佈式的組中的代價會進一步惡化。Walter[36]提供了一個快 照隔離的變種，可是沒法跨越數據中心。相反，咱們的只讀事務提供了一個更加天然的語義，由於，咱們對於全部的操做都支持外部語義。
最近，在減小或者消除鎖開銷方面已經有大量的研究工做。Calvin[40]消除了併發控制：它會從新分配時間戳，而後以時間戳的順序執行事務。 HStore[39]和Granola[11]都支持本身的事務類型劃分方法，有些事務類型能夠避免鎖機制。可是，這些系統都沒法提供外部一致性。 Spanner經過提供快照隔離，解決了衝突問題。
VoltDB[42]是一個分片的內存數據庫，能夠支持在大範圍區域內進行主從複製，支持災難恢復，可是沒有提供通用的複製配置方法。它是一個被稱爲 NewSQL的實例，這是實現可擴展的SQL[38]的強大的市場推進力。許多商業化的數據庫均可以支持歷史數據讀取，好比Marklogic[26]和 Oracle’ Total Recall[30]。Lomet和Li[24]對於這種時間數據庫描述了一種實現策略。
Faresite給出了與一個受信任的時鐘參考值相關的、時鐘不肯定性的邊界[13]（要比TrueTime更加寬鬆）：Farsite中的服務器租約的 方式，和Spanner中維護Paxos租約的方式相同。在以前的工做中[2][23]，寬鬆同步時鐘已經被用來進行併發控制。咱們已經展現了 TrueTime能夠從Paxos狀態機集合中推導出全球時間。
7. 將來的工做
在過去一年的大部分時間裏，咱們都是F1團隊一塊兒工做，把谷歌的廣告後臺從MySQL遷移到Spanner。咱們正在積極改進它的監控和支撐工具，同時在 優化性能。此外，咱們已經開展了大量工做來改進備份恢復系統的功能和性能。咱們當前正在實現Spanner模式語言，自動維護二級索引和自動基於負載的分 區。在將來，咱們會調研更多的特性。以最優化的方式並行執行讀操做，是咱們追求的有價值的策略，可是，初級階段的實驗代表，實現這個目標比較艱難。此外， 咱們計劃最終能夠支持直接變動Paxos配置[22][34]。
咱們但願許多應用均可以跨越數據中心進行復制，而且這些數據中心彼此靠近。TrueTime ε可能會明顯影響性能。把ε值下降到1ms之內，並不存在不可克服的障礙。Time-master-query間隔能夠繼續減小，Time- master-query延遲應該隨着網絡的改進而減小，或者經過採用分時技術來避免延遲。
最後，還有許多有待改進的方面。儘管Spanner在節點數量上是可擴展的，可是與節點相關的數據結構在複雜的SQL查詢上的性能相對較差，由於，它們是 被設計成服務於簡單的鍵值訪問的。來自數據庫文獻的算法和數據結構，能夠極大改進單個節點的性能。另外，根據客戶端負載的變化，在數據中心之間自動轉移數 據，已經成爲咱們的一個目標，可是，爲了有效實現這個目標，咱們必須具有在數據中心之間自動、協調地轉移客戶端應用進程的能力。轉移進程會帶來更加困難的 問題——如何在數據中心之間管理和分配資源。
8. 總結
總的來講，Spanner對來自兩個研究羣體的概念進行告終合和擴充：一個是數據庫研究羣體，包括熟悉易用的半關係接口，事務和基於SQL的查詢語言；另 一個是系統研究羣體，包括可擴展性，自動分區，容錯，一致性複製，外部一致性和大範圍分佈。自從Spanner概念成形，咱們花費了5年以上的時間來完成 當前版本的設計和實現。花費這麼長的時間，一部分緣由在於咱們慢慢意識到，Spanner不該該僅僅解決全球複製的命名空間問題，並且也應該關注 Bigtable中所丟失的數據庫特性。
咱們的設計中一個亮點特性就是TrueTime。咱們已經代表，在時間API中明確給出時鐘不肯定性，能夠以更增強壯的時間語義來構建分佈式系統。此外， 由於底層的系統在時鐘不肯定性上採用更加嚴格的邊界，實現更強壯的時間語義的代價就會減小。做爲一個研究羣體，咱們在設計分佈式算法時，再也不依賴於弱同步 的時鐘和較弱的時間API。
致謝
許多人幫助改進了這篇論文：Jon Howell，Atul Adya, Fay Chang, Frank Dabek, Sean Dorward, Bob Gruber, David Held, Nick Kline, Alex Thomson, and Joel Wein. 咱們的管理層對於咱們的工做和論文發表都很是支持：Aristotle Balogh, Bill Coughran, Urs H¨olzle, Doron Meyer, Cos Nicolaou, Kathy Polizzi, Sridhar Ramaswany, and Shivakumar Venkataraman.
咱們的工做是在Bigtable和Megastore團隊的工做基礎之上開展的。F1團隊，尤爲是Jeff Shute
，和咱們一塊兒工做，開發了數據模型，跟蹤性能和糾正漏洞。Platforms團隊，尤爲是Luiz Barroso和Bob Felderman，幫助咱們一塊兒實現了TrueTime。最後，許多谷歌員工都曾經在咱們的團隊工做過，包括Ken Ashcraft, Paul Cychosz, Krzysztof Ostrowski, Amir Voskoboynik, Matthew Weaver, Theo Vassilakis, and Eric Veach; or have joined our team recently: Nathan Bales, Adam Beberg, Vadim Borisov, Ken Chen, Brian Cooper, Cian Cullinan, Robert-Jan Huijsman, Milind Joshi, Andrey Khorlin, Dawid Kuroczko, Laramie Leavitt, Eric Li, Mike Mammarella, Sunil Mushran, Simon Nielsen, Ovidiu Platon, Ananth Shrinivas, Vadim Suvorov, and Marcel van der Holst.
參考文獻
[1] Azza Abouzeid et al. 「HadoopDB: an architectural hybrid of MapReduce and DBMS technologies for analytical workloads」. Proc. of VLDB. 2009, pp. 922–933.
[2] A. Adya et al. 「Efficient optimistic concurrency control using loosely synchronized clocks」. Proc. of SIGMOD. 1995, pp. 23–34.
[3] Amazon. Amazon DynamoDB. 2012.
[4] Michael Armbrust et al. 「PIQL: Success-Tolerant Query Processing in the Cloud」. Proc. of VLDB. 2011, pp. 181–192.
[5] Jason Baker et al. 「Megastore: Providing Scalable, Highly Available Storage for Interactive Services」. Proc. of CIDR. 2011, pp. 223–234.
[6] Hal Berenson et al. 「A critique of ANSI SQL isolation levels」. Proc. of SIGMOD. 1995, pp. 1–10.
[7] Matthias Brantner et al. 「Building a database on S3」. Proc. of SIGMOD. 2008, pp. 251–264.
[8] A. Chan and R. Gray. 「Implementing Distributed Read-Only Transactions」. IEEE TOSE SE-11.2 (Feb. 1985), pp. 205–212.
[9] Fay Chang et al. 「Bigtable: A Distributed Storage System for Structured Data」. ACM TOCS 26.2 (June 2008), 4:1–4:26.
[10] Brian F. Cooper et al. 「PNUTS: Yahoo!’s hosted data serving platform」. Proc. of VLDB. 2008, pp. 1277–1288.
[11] James Cowling and Barbara Liskov. 「Granola: Low-Overhead Distributed Transaction Coordination」. Proc. of USENIX ATC. 2012, pp. 223–236.
[12] Jeffrey Dean and Sanjay Ghemawat. 「MapReduce: a flexible data processing tool」. CACM 53.1 (Jan. 2010), pp. 72–77.
[13] John Douceur and Jon Howell. Scalable Byzantine-Fault-Quantifying Clock Synchronization. Tech. rep. MSR-TR-2003-67. MS Research, 2003.
[14] John R. Douceur and Jon Howell. 「Distributed directory service in the Farsite file system」. Proc. of OSDI. 2006, pp. 321–334.
[15] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. 「The Google file system」. Proc. of SOSP. Dec. 2003, pp. 29–43.
[16] David K. Gifford. Information Storage in a Decentralized Computer System. Tech. rep. CSL-81-8. PhD dissertation. Xerox PARC, July 1982.
[17] Lisa Glendenning et al. 「Scalable consistency in Scatter」. Proc. of SOSP. 2011.
[18] Jim Gray and Leslie Lamport. 「Consensus on transaction commit」. ACM TODS 31.1 (Mar. 2006), pp. 133–160.
[19] Pat Helland. 「Life beyond Distributed Transactions: an Apostate’s Opinion」. Proc. of CIDR. 2007, pp. 132–141.
[20] Maurice P. Herlihy and Jeannette M. Wing. 「Linearizability: a correctness condition for concurrent objects」. ACM TOPLAS 12.3 (July 1990), pp. 463–492.
[21] Leslie Lamport. 「The part-time parliament」. ACM TOCS 16.2 (May 1998), pp. 133–169.
[22] Leslie Lamport, Dahlia Malkhi, and Lidong Zhou. 「Reconfiguring a state machine」. SIGACT News 41.1 (Mar. 2010), pp. 63–73.
[23] Barbara Liskov. 「Practical uses of synchronized clocks in distributed systems」. Distrib. Comput. 6.4 (July 1993), pp. 211–219.
[24] David B. Lomet and Feifei Li. 「Improving Transaction-Time DBMS Performance and Functionality」. Proc. of ICDE (2009), pp. 581–591.
[25] Jacob R. Lorch et al. 「The SMART way to migrate replicated stateful services」. Proc. of EuroSys. 2006, pp. 103–115.
[26] MarkLogic. MarkLogic 5 Product Documentation. 2012.
[27] Keith Marzullo and Susan Owicki. 「Maintaining the time in a distributed system」. Proc. of PODC. 1983, pp. 295–305.
[28] Sergey Melnik et al. 「Dremel: Interactive Analysis of Web-Scale Datasets」. Proc. of VLDB. 2010, pp. 330–339.
[29] D.L. Mills. Time synchronization in DCNET hosts. Internet Project Report IEN–173. COMSAT Laboratories, Feb. 1981.
[30] Oracle. Oracle Total Recall. 2012.
[31] Andrew Pavlo et al. 「A comparison of approaches to large-scale data analysis」. Proc. of SIGMOD. 2009, pp. 165–178.
[32] Daniel Peng and Frank Dabek. 「Large-scale incremental processing using distributed transactions and notifications」. Proc. of OSDI. 2010, pp. 1–15.
[33] Daniel J. Rosenkrantz, Richard E. Stearns, and Philip M. Lewis II. 「System level concurrency control for distributed database systems」. ACM TODS 3.2 (June 1978), pp. 178–198.
[34] Alexander Shraer et al. 「Dynamic Reconfiguration of Primary/Backup Clusters」. Proc. of SENIX ATC. 2012, pp. 425–438.
[35] Jeff Shute et al. 「F1—The Fault-Tolerant Distributed RDBMS Supporting Google’s Ad Business」. Proc. of SIGMOD. May 2012, pp. 777–778.
[36] Yair Sovran et al. 「Transactional storage for geo-replicated systems」. Proc. of SOSP. 2011, pp. 385–400.
[37] Michael Stonebraker. Why Enterprises Are Uninterested in NoSQL. 2010.
[38] Michael Stonebraker. Six SQL Urban Myths. 2010.
[39] Michael Stonebraker et al. 「The end of an architectural era: (it’s time for a complete rewrite)」. Proc. of VLDB. 2007, pp. 1150–1160.
[40] Alexander Thomson et al. 「Calvin: Fast Distributed Transactions for Partitioned Database Systems」. Proc. of SIGMOD.2012, pp. 1–12.
[41] Ashish Thusoo et al. 「Hive — A Petabyte Scale Data Warehouse Using Hadoop」. Proc. of ICDE. 2010, pp. 996–1005.
[42] VoltDB. VoltDB Resources. 2012.
（廈門大學計算機係數據庫實驗室教師 林子雨 翻譯 2012年9月17日-21日）
[請到本網頁的底部的「附件」中下載：Google Spanner的英文版原文和中文版的PDF文件]
[林子雨翻譯的與Goolge Spanner緊密相關的學術文章推薦] Google Bigtable（中文版）