前沿

2012~2013年Google 相繼發表了Spanner和F1兩套系統的論文，讓業界第一次看到了關系模型和NoSQL的擴展性在一個大規模生產系統上融合的可能性。Spanner 通過使用硬件設備(GPS時鐘+原子鐘)巧妙地解決時鐘同步的問題，而在分布式系統里，時鐘正是最讓人頭痛的問題。Spanner的強大之處在于即使兩個數據中心隔得非常遠，也能保證通過TrueTime API獲取的時間誤差在一個很小的范圍內(10ms)，并且不需要通訊。Spanner的底層仍然基于分布式文件系統，不過論文里也說是可以未來優化的點。

Google的內部的數據庫存儲業務，大多是3~5副本，重要的數據需要7副本，且這些副本遍布全球各大洲的數據中心，由于普遍使用了Paxos，延遲是可以縮短到一個可以接受的范圍(寫入延遲100ms以上)，另外由Paxos帶來的Auto-Failover能力，更是讓整個集群即使數據中心癱瘓，業務層都是透明無感知的。F1是構建在Spanner之上，對外提供了SQL接口，F1是一個分布式MPP SQL層，其本身并不存儲數據，而是將客戶端的SQL翻譯成對KV的操作，調用Spanner來完成請求。嚴格來說，是Spanner和F1一起開創了NewSQL風格。

簡介

Cloud Spanner 是一項完全托管式用于關鍵任務的關系型數據庫服務，可提供全球范圍的事務一致性、自動同步復制功能以實現高可用性。它是第一個把數據分布在全球范圍內的系統，并且支持外部一致性的分布式事務。Spanner的擴展性達到了令人咋舌的全球級，可以擴展到數百萬的機器，數已百計的數據中心，上萬億的行。除了夸張的擴展性之外，他還能同時通過同步復制和多版本來滿足外部一致性，可用性也是很好的。沖破CAP的枷鎖，在三者之間完美平衡。它是BigTable的繼任者。谷歌稱Spanner不是一個純粹的關系型系統，因為每個表必須有主鍵，以及對兩種 SQL 方言的支持：Google 標準 SQL(ANSI 2011 及擴展程序)和 PostgreSQL。

優勢

• 享受關系語義和 SQL 的所有優勢，并且規模不受限制。
• 以任何規模起步，可隨需求增長無限擴容。
• 享受零計劃停機時間和在線架構變更帶來的高可用性。
• 可跨區域和洲實現具有強一致性的高性能事務。
• 專注于創新，通過自動分片等功能消除人工作業。

特性

• 可靈活擴縮的關系型數據庫：從架構、SQL 查詢到 ACID 事務，關系型數據庫應有的一切功能都具備，久經考驗，且隨時可以在全球范圍內擴容。
• 99.999% 的可用性：Cloud Spanner 可為多區域實例提供業界領先的 99.999% 可用性;與 99.99% 的可用性相比，停機時間是其十分之一。它還可跨單區域和多區域配置提供透明的同步復制功能。
• 自動分片：Cloud Spanner 可根據請求負載和數據大小自動分片，從而提升性能。因此，您不必太擔心如何對數據庫進行擴容，從而可以專注于擴展業務。
• 全代管式：無論數據庫規模如何，每個階段均可實現輕松部署。內置自動同步復制和維護功能。
• 事務強一致性：專為實現行業領先的外部一致性而構建，同時不會影響可擴縮性或可用性。
• 單區域和多區域配置：無論用戶位于哪里，由 Spanner 提供支持的應用都可以在全球范圍內讀取和寫入最新的強一致性數據。此外，運行多區域實例時，您的數據庫可以防范單區域故障，并提供業界領先的 99.999% 可用性。
• 使用 BigQuery 執行聯合查詢：在 BigQuery 中實時查詢 Spanner 數據，而無需移動或復制數據，消除運營數據與分析之間的差異，打造統一的數據生命周期。
• 基于 Google Cloud 網絡構建：Cloud Spanner 基于 Google 的專用網絡構建，該網絡提供低延遲、安全性和可靠性，可為全球用戶提供服務。

場景

Spanner 是一種分布式的、全球可擴展的 SQL 數據庫服務，該服務將計算與存儲分離，使其可在存儲之外單獨擴縮處理資源。 Spanner 這種分布式擴縮特性使其成為不可預測的工作負載(如在線游戲)的理想解決方案。

事務

Spanner 系統中的分布式事務通過兩階段提交協議2PC實現。2PC是一類特殊的一致性協議，假設一個分布式事務涉及了多個數據節點，2PC可以保證在這些節點上的操作要么全部提交，要么全部失敗，從而保證了整個分布式事務的原子性ACID里的A。協議中包含兩個角色：協調者coordinator和參與者participant/cohort。協調者是分布式事務的發起者，而參與者是參與了事務的數據節點。在協議最基本的形式中，系統中有一個協調者和多個參與者。Cloud Spanner 中的事務是一組讀寫操作，它們跨數據庫中的列、行和表，在單個邏輯時間點以原子方式執行。

Cloud Spanner 支持以下事務模式：

• 鎖定讀寫：這種事務類型是唯一支持將數據寫入 Cloud Spanner 的事務類型。這些事務依賴于悲觀鎖定和(如有必要)兩階段提交。鎖定讀寫事務可能會中止，需要應用重試。
• 只讀：這種事務類型可保證多次讀取之間的一致性，但禁止寫入。只讀事務可以配置為在過去的時間戳處讀取。只讀事務不需要提交，也不會鎖定。
• 分區 DML：此事務類型將數據操縱語言 (DML) 語句作為分區 DML 執行。分區 DML 專為批量更新和刪除(尤其是定期清理和回填)而設計。

模型

一個 Cloud Spanner 數據庫可以包含一個或多個表。這些表與關系型數據庫表類似，它們也是由行、列和值構成的，并且包含主鍵。Cloud Spanner 中的數據是強類型的：必須為每個數據庫定義一個架構，并且該架構必須指定每個表中每一列的數據類型。允許的數據類型包括標量和數組類型，也可以在表上定義一個或多個二級索引。

父子表

可以通過兩種方式在 Cloud Spanner 中定義父子關系，表交錯和外鍵。Cloud Spanner 的表交錯是許多父子關系的理想選擇，其中子表的主鍵包含父表的主鍵列。子行及其父行共用位置可以顯著提高性能，外鍵是一種較通用的父子解決方案，并解決了其他用例。外鍵不限于主鍵列，而表可以具有多個外鍵關系，二者在某些關系中可以作為父鍵，而在其他關系中可以作為子鍵。但是，外鍵關系不隱含表在存儲層中的共用位置關系。

主鍵

每個表都必須有一個主鍵，并且該主鍵可以由該表的零列或多列組成，如果將某個表聲明為另一個表的子表，則父表的主鍵列必須是子表主鍵的前綴，Cloud Spanner 會按主鍵值得排序順序存儲行，并在父行之間插入共享相同主鍵前綴的子行，這意味著，如果父表的主鍵由 N 列組成，則其每個子表的主鍵也必須由相同的 N 列組成，順序相同，并且以相同的列開始。這種沿著主鍵維度在父行之間插入子行的行為稱為交錯，而子表也稱為交錯表。

分片

表之間定義最多七層的父子關系層次結構，意味著可以將七個邏輯上獨立的表的行存儲在一起。如果表中的數據量比較少，那么您的數據庫或許可以由單個 Cloud Spanner 服務器處理。然而，當相關表不斷增長，開始達到單個服務器的資源限制時。Cloud Spanner 會將數據劃分為稱作“分片”的區塊，各個分片可以彼此獨立移動并被分配給不同物理位置的多個服務器。分片包含一系列連續的行。這一范圍的開始和結束鍵稱為“分片邊界”。Cloud Spanner 會根據大小和/或負載自動添加和移除分片邊界，這樣做會改變數據庫中的分片數量。

復制

Cloud Spanner 復制的優勢包括以下幾點：

• 數據可用性：對于希望讀取數據的客戶端而言，擁有更多數據副本可以使數據更具可用性。另外，即使某些副本不可用，Cloud Spanner 仍然可以支持寫入操作，因為在提交寫入時僅需大部分投票副本即可。
• 地理局部性：能夠使用 Cloud Spanner 將數據存放到不同的區域和大洲，這意味著數據可以在地理上更接近需要它的用戶和服務，因此訪問速度也更快。
• 單一數據庫體驗：得益于同步復制和全局高度一致性，無論規模如何，Cloud Spanner 均可提供一致的表現以及單一數據庫體驗。
• 更輕松的應用開發：Cloud Spanner 的 ACID 事務具有全局高度一致性，這意味著開發者無需在應用中添加額外的邏輯來處理最終一致性，因此應用開發和后續維護變得更加輕松快捷。

總結

Spanner是第一個可以在全球范圍內提供這種保證的系統，符合 ACID 標準的數據庫，可自動進行副本、分片和事務處理，因此可以快速擴容以滿足任何使用模式的要求，Cloud Spanner 基于 Google 的專用網絡構建，在數十億用戶都在使用的 Google 服務中已久經考驗。它可實現高達 99.999% 的可用性，在計劃內維護和架構變更期間可以做到零停機。IT 管理員和數據庫管理員往往忙于執行數據庫運維工作?，F在，借助 Cloud Spanner，只需點擊幾下鼠標即可創建或擴縮可在全球范圍內復制的數據庫，并降低數據庫維護費用。