《從分布式到云端服務：Google Spanner 成長之路》要點：
本文介紹了從分布式到云端服務：Google Spanner 成長之路，希望對您有用。如果有疑問，可以聯(lián)系我們。

摘要：距離 Google 開始開發(fā) Spanner 已經 10 年,5 年前 Google 發(fā)表了論文,在 Google 云平臺上增加開放 Spanner 服務,意義不僅僅是服務于 AdWords 和 Google Play,而是希望在云端更有所為.在這 5 年時間里,正是由于其他廠商無法復制 Google 的想法,即不能解決大規(guī)模集群下高可用性、水平擴展能力、數據強一致性等.本文從 Spanner 技術著手,逐漸引出最近的特大消息：Google 開放 Spanner 云端能力(測試版).

Spanner 技術概括

簡介

Spanner 是 Google 的可擴展、多版本支持、全球分布式的同步備份數據庫,領軍人物是 Eric Brewer,他是 CAP 理論的創(chuàng)造者、超級大牛.Spanner 是第一個支持全球規(guī)模的分布式數據庫.當數據量或者服務器數量發(fā)生變化時,Spanner 在機器之間自動共享數據,并且 Spanner 在機器之間自動遷移數據(甚至在數據中心之間),用于負載均衡和響應失敗.Spanner 被設計為可以在數百萬臺機器之上橫向擴展,覆蓋數百個數據中心、上億條數據.

五年前發(fā)表的論文《在 Google 云平臺上增加開放 Spanner 服務》,描述了 Spanner 數據庫的內部結構是怎么樣的、包含哪些屬性、各種設計決策的基本原理,也暴露了一種新的不確定性時鐘時間 API.這些 API 和他們的實現對于支持外部一致性和幾個重量級的特征來說極其重要,這些特征包括非阻塞式多版本讀(nonblocking reads in the past)、無鎖只讀交易(lock-free read-only transactions)、原子模型變化(atomic schema changes),這些特征貫穿 Spanner 內部設計.

Spanner 是一個在遍布全球范圍的數據中心內部穿過多套 Paxos 狀態(tài)機器共享數據的數據庫.復制被用于全局可用性和地理位置；客戶在副本之間自動切換.當數據量或者服務器數量發(fā)生變化時,Spanner 在機器之間自動共享數據,并且 Spanner 在機器之間自動遷移數據(甚至在數據中心之間),用以負載均衡和響應失敗.Spanner 被設計為在幾百萬臺機器之上橫向擴展,這些擴展穿過了數百個數據中心和萬億行數據.

應用程序可以使用 Spanner 實現高可用性,甚至面對大面積的自然災害,通過地區(qū)內部、甚至跨洲的備份數據策略.Spanner 最早的客戶是 F1,它是一個 Google 廣告系統(tǒng)的后臺程序.F1 在美國境內一共有 5 個副本.大多數應用程序在選擇分布式數據庫的時候,首選要求是低延時,然后才是高可用性,只要能夠挺過 1-2 次數據中心故障就可以了.

Spanner 是從類似于 Bigtable 這樣的鍵值對(Key-Value)存儲演變過來的一種時態(tài)多版本數據庫.數據被存儲在半關系型數據模型里,數據通過版本管理,每一個版本自動創(chuàng)建提交時間作為時間戳,老版本的數據服從垃圾回收機制管理.

和 NoSQL 數據庫不同,Spanner 屬于 NewSQL 數據庫.

與其他數據庫對比

我們針對 Spanner、關系型數據庫、NoSQL 數據庫所能提供的功能進行對比,如圖所示.

?Spanner Schema 設計

Spanner 不需要每張表必須有一個主鍵列.由于 Bigtable 持續(xù)被投訴,所以 Google 在設計 Spanner 時把分布式交易集中化,因為過多的交易容易造成性能瓶頸出現.

在 Spanner 的模式定義語言里,你可以在表之間使用 INTERIAVE IN 申明表之間的層次關系.在層次關系的最頂層表示一張 Directory 表,其他的下級表示按照字典形式命名排序的.ON DELETE CASCADE 被用于當 Directory 表里的一行數據被刪除時,相應地一并刪除子表里的對應數據.創(chuàng)建 Spanner 數據表如圖所示.

讀 / 寫方式

Spanner 提供三種類型的操作：讀 / 寫交易、讀交易和快照讀操作.

單一的寫操作是通過一個讀 / 寫交易執(zhí)行的,然而一個單一的讀操作,不是一個快照讀,是通過一個讀交易執(zhí)行的.

一個寫操作執(zhí)行了一個讀 / 寫交易,在提交交易之前都是緩存在客戶端.一個交易里面的讀操作,不會被寫操作的結果所影響.讀 / 寫交易當中的讀操作使用了 Wound-Wait 方式避免死鎖.客戶端從協(xié)調節(jié)點獲取讀鎖,然后讀取最新的數據.

?全球分布式設計

Spanner 最初的出現就是因為 Google 內部使用的 Bigtable 無法確保跨地區(qū)的數據中心強一致性.Spanner 的整體集合被稱為 Universe.一個 Universe 又由幾個 Zone 組成.一個 Zone 意味著一個單元,這個單元可以物理上獨立運行.一個數據中心可能超過 1 個 Zone.如果你想要在不同的服務組內存儲數據,你需要在一個數據中心內部建立兩個或者以上的 Zone.

上面這張圖顯示了在一個 Universe 里面配置的服務器,一個 Zone 由一個 Zonemaster 和幾千個 Spanserver 組成.Zonemaster 為 Spanserver 分配數據.同時,Spanserver 實際存儲和處理數據.Location Proxy 通過客戶端調用,顯示目標數據被存儲在哪個 Spanserver.Universemaster 提供了所有 Zone 的狀態(tài)或者調試信息,并且 Placement Driver 實際上執(zhí)行 Zone 之間的數據傳輸,決定是否數據被移除了(由于備份策略改變或者通過與 Spanserver 之間的定期通信進行負載均衡).

每一個 spanserver?大約有 10 到 1000 個被叫做 Tablet 的數據結構.Tablet 可以存儲多個映射,字符串 (key:string, timestamp:int64) 形式.Spanner 里的 Tablet 和 BigTable 里的 Tablet 的差別是,Spanner 存儲一個數據的同時帶了時間戳.這意味著 Spanner 不僅僅是一個簡單的鍵值對存儲,而是帶有多版本特性的數據庫.

Table 的狀態(tài)存儲在 Colossus Distributed File System,基于二叉樹文件形式和 write-ahead log(WAL).

Spanner 使用 Paxos 狀態(tài)機支持 spanservers 之間的數據備份.

一個 spanserver 有交易管理者,用于支持分布式事務.交易管理者在單一 Paxos 組內不會參與交易執(zhí)行,但是當多個 Paxos 組之間進行交易時它會參與進去,參與人之一會被選舉為協(xié)調組長,基于 phase-2 commit 協(xié)議執(zhí)行協(xié)調.

目錄是一組連續(xù)的鍵,這些鍵使用相同的前綴(你可以想象成一個桶).Directory 是一個數據分配的基本單元.Directory 里面的所有數據有定義好的備份設置,并且 Paxos 組之間的數據傳輸也是指定的.

一個應用程序可以在一個 universe 內部創(chuàng)建 1 個或多個數據庫,一個數據庫有多張表(沒有上限).一張表有行和列,比關系型數據庫表多的是有版本信息.在 Spanner 的模式定義語言里,你可以在表之間使用 INTERLEAVE IN 申明層次(hierachical)關系.在層次關系的最頂層表示一張 directory 表.根據 directory 表里定義的鍵,字表命名是根據字典排序的.ON DELETE CASCADE 被用于當 directory 表的一行數據被刪除時,相應地一起刪除子表里面的數據.

?F1

Spanner 的最早的客戶是 F1,它是一個 Google 廣告系統(tǒng)的后臺程序.F1 在美國境內一共有 5 個副本.許多其他的應用程序最有可能的是在一個地理區(qū)間內在 3 到 5 個數據中心中間復制數據,但是它們具有相對獨立的失效模式(failure mode).也就是說,大多數應用程序會首選較低延遲,然后才是高可用性,只要能夠挺過 1 到 2 次的數據中心故障.

Google F1 SQL 數據庫管理系統(tǒng)構建在 Spanner 之上,用于替換 Google 的 MySQL 定制版本.Spanner 使用 Paxos 算法作為操作的一部分,用于在數百個數據中心之間共享數據.

技術總結

Spanner 提供了類似于關系型數據庫的功能支持和操作方式,每張表都有主鍵、可以管理和刪除級聯(lián)表的數據.Spanner 支持 ACID 和 SQL 語句.由于 Spanner 會把上億條數據存放在全球很多數據中心里,所以當你讀取數據時,Spanner 把讀取請求發(fā)到物理上最接近你的數據中心,當你寫入數據時,你會存儲到多個數據中心.如果數據中心整體停止服務,你也可以從副本數據中心環(huán)境讀取數據.

Spanner 并不開源,但是有開源實現 CockroachDB,源碼請訪問 https://github.com/cockroachdb/cockroach.

發(fā)布 Cloud Spanner 測試版本

2017 年 2 月 14 日(情人節(jié)),Google 宣布 Cloud Spanner 發(fā)布測試版本.這是一個基于云端的全球分布式關系數據庫服務,支持包括 ACID 交易、SQL 語義,支持水平擴展和高可用性.當我們構建一個基于云端的應用程序時,數據庫管理員和開發(fā)人員都需要去選擇使用關系型數據庫或者 NoSQL 數據庫,關系型數據確保交易持久性,NoSQL 數據庫提供了簡單、水平擴展和數據分布式.Cloud Spanner 打破了這種非此即彼的選擇方案,提供了集兩個關鍵能力與一體的,完全管理的服務.

Cloud Spanner 與 Google 頗有淵源,早在 2012 年的一份文件中 Google 就記錄了 Cloud Spanner,并且已在內部使用多年.目前谷歌的云數據庫服務陣營包括 Google Bigtable(谷歌 2015 年發(fā)布的一個全面管理、高性能、可擴展的 NoSQL 數據庫服務)、Google Container Engine(谷歌為解決企業(yè)管理大量容器技術編排的繁瑣工作而推出的容器管理服務) 等.

Google 產品經理 Deepti Srivastava 曾在一篇博文中寫道：

Cloud Spanner 通過在熟悉的關系數據庫環(huán)境中支持標準工具和語言,簡化了應用程序開發(fā).它是傳統(tǒng)關系數據庫支持運行的工作負載的理想選擇,如庫存管理,金融交易和控制系統(tǒng)以及其它系統(tǒng).

Cloud Spanner 同 GCP、Cloud SQL、Cloud Datastore、Cloud Bigtable 一起,豐富了我們數據庫服務的能力.

作為一個可控的服務,Cloud Spanner 給 DBA 提供了下列重要福利：

1. 讓 DBA 把寶貴的精力專注于業(yè)務邏輯上,而不是用于處理各種軟件或硬件問題；
2. 使得 DBA 不用執(zhí)行復雜的分片或者集群操作,就可以實現對 RDBMS 解決方案的擴展；
3. DBA 不用把關系數據庫遷移到 NoSQL 數據中,也能獲得數據的水平擴展能力；
4. DBA 無需復雜的數據備份或失效援備機制,即可維護數據的高可用性,以及具備對數據的災備恢復能力；
5. 將安全性與數據層加密,身份驗證,接入管理,日志審核等功能進行整合.

Cloud Spanner 并沒有違反 CAP 定理.這些年,我們已經讓 Spanner 打贏了 Google 內部很多場戰(zhàn)斗,數百個不同的應用程序,PB 級別的數據在全球的數據中心間轉移.在 Google,Spanner 支持每秒數以百萬計次的查詢,運行的應用程序包括 AdWords 和 Google Play.

有了 Cloud Spanner,你可以對數據庫的規(guī)模按照需求來擴展和縮小,然后你只需要按照使用規(guī)模來付費即可.Spanner Cloud 的特色之一就是提供了一個簡潔的收費模式,可通過計算節(jié)點使用的小時數,實際存儲消耗(而不是預估存儲消耗)以及外部網絡接入等指標來計算費用.

Cloud Spanner 力圖保持應用開發(fā)的簡潔性,支持開發(fā)者們熟知的關系數據庫環(huán)境、工具和語言.因此它對那些通過傳統(tǒng)關系數據庫來的驅動的應用作業(yè)(如裝備管理,金融事務,控制系統(tǒng),以及那些規(guī)模快速增長的系統(tǒng))是非常理想的.Cloud Spanner 同時還數據線了分布式事務,Scheme 和 DDL 聲明,SQL 查詢和 JDBC 驅動等功能,并且支持多種主流語言,如 Java,Go,Python,Node.js 等.

Google Cloud Platform 也將繼續(xù)完善 Google Cloud SQL 服務以及 Google Cloud Datastore.與此同時,AWS 和 Microsoft 也并未放慢在云領域的腳步.AWS 提供與 MySQL 兼容的 Aurora 關系數據庫以及關系數據庫服務 (RDS),而 Microsoft Azure 在虛擬機 (VM) 上提供 Azure SQL 數據庫以及 SQL Server.

全文總結

簡而言之,距離 Google 開始開發(fā) Spanner 已經 10 年,5 年前 Google 發(fā)表了論文,在 Google 云平臺上增加開放 Spanner 服務,意義不僅僅是服務于 AdWords 和 Google Play,而是希望在云端更有所為.在這 5 年時間里,正是由于其他廠商無法復制 Google 的想法,即不能解決大規(guī)模集群下高可用性、水平擴展能力、數據強一致性等.Cloud Spanner 在做到兼顧優(yōu)勢的同時,并沒有違反 CAP 理論.這也就是為什么 Spanner 在云端開放服務的消息成為了一個沖擊性的新聞,讓我們拭目以待 Google 的極客精神.

相關技術名詞解釋

NewSQL：這是一種完全不同的數據庫架構.NoSQL 的一個優(yōu)點是橫向擴展能力,缺點是沒有提供強一致性,它們不可以被使用在強一致性環(huán)境下.NewSQL 和 NoSQL 一樣具有很強的擴展能力,同時也提供了和 RDBMS 一樣的單個節(jié)點上的 ACID.NewSQL 術語最早在 2011 年由 Matthew Aslett 創(chuàng)造.HBase 也提供了有限形式的事務(單行事務).然而,這種有限交易不能完全吻合業(yè)務需求.HBase 也是一種 NewSQL.

wound-wait：Spanner 論文中提到了使用“wound-wait”策略防范死鎖.這是一種基于剝奪的方法,當進程 Pi 請求的資源正在被進程 Pj 占有時,只有當進程 Pi 的時間戳比進程 Pj 的時間戳大時,即 Pi 比 Pj 年輕時,Pi 才能等待.否則 Pj 被 Roll Back,即死亡.只要被 Roll Back 的進程重新啟動,使用原有的時間戳,這兩種方案就能避免死鎖和餓死現象.由于時間戳總是增加的,被 Roll Back 的進程最終將具有最小的時間戳.

CAP 定理：指的是在一個分布式系統(tǒng)中,一致性、可用性、分區(qū)容錯性,三者不可得兼.CAP 理論是在分布式存儲系統(tǒng)中,最多只能實現上面的兩點.而由于當前的網絡硬件肯定會出現延遲丟包等問題,所以分區(qū)容忍性是必須實現的.

ACID：在可靠的數據庫管理系統(tǒng)中,事務所應該具有的四個特性,即原子性、一致性、隔離性、持久性.原子性是指事務是一個不可再分割的工作單位,事務中的操作要么都發(fā)生,要么都不發(fā)生.一致性是指在事務開始之前和事務結束以后,數據庫的完整性約束沒有被破壞.這是說數據庫事務不能破壞關系數據的完整性以及業(yè)務邏輯上的一致性.多個事務并發(fā)訪問時,事務之間是隔離的,一個事務不應該影響其它事務運行效果.持久性,意味著在事務完成以后,該事務所對數據庫所作的更改便持久的保存在數據庫之中,并不會被回滾.

文章來自微信公眾號：高效開發(fā)運維

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4153.html