Cloud Spanner是google Megastore系統的繼承者，Spanner表現出遠超前輩的能力。Spanner首次是在Google內部數據中心中出現，而在2017年才對外發布測試版并加入了SQL能力。如今已經在Google云平臺上架并擁有大量各個行業的用戶。Cloud Spanner數據庫是全球范圍分布式的關系型/事務數據庫，并且Google承諾Cloud Spanner擁有高吞吐量、低延遲和99.999%的高可用性。

接觸Cloud Spanner

第一次接觸到Google Cloud Spanner是因為客戶對于新技術的追求與嘗試，將我們基本完成的APIs從原先的Google Cloud Sql遷移到Cloud Spanner數據庫上。在做這個決定的時候，客戶考慮到當時公司用戶數量處于激增的階段，業務也在不斷進行更改，所以需要對表結構也進行更改來滿足業務的需求。于是便決定使用Google Cloud Spanner來保證數據的ACID（原子性、一致性、隔離性和持久性）的前提下仍然可以對數據庫進行水平拓展和分布式操作。

選擇Cloud Spanner

和主流的云服務關系數據庫相比，例如AWS的Aurora、GCP的Cloud SQL和Azure的SQLDB，這些數據庫并沒有實現在多節點上進行擴展的功能，只能在單個節點上進行垂直擴容（增加RAM或CPU數量）。

如果想要實現水平擴容，可以使用NoSQL數據庫，例如HBase、MongoDB、DynamoDB或BigTable。但是這些數據庫很難做到事務的特性，并且不能支持關系型數據庫所支持的功能，例如連表等。并且因為NoSQL的查詢語句和關系型數據庫的語句區別很大，會導致應用中大量的查詢語句和表結構需要重寫。

而Cloud Spanner區別于這些數據庫服務，是一種獨特的數據庫。它將事務，SQL查詢和關系結構與NoSQL數據庫的可伸縮性相結合。因此Cloud Spanner同時具備SQL和NoSQL數據庫結構的優點。在最初的時候，Cloud Spanner是被設計為NoSQL的鍵值對的方式存儲，但隨著其對關系模型的需求被添加后，Cloud Spanner逐漸打破了NoSQL和SQL數據庫之間的壁壘。

特性

作為分布式數據庫

每一個Spanner的實例都是在不同數量的節點上運行的，每一個節點都是由Google云平臺服務去自動管理的。因此，Cloud Spanner擁有很高的可擴展性，并且可根據請求負載和數據的大小進行自動分片（splits），為系統提供了更多的彈性空間。

作為關系型數據庫

Cloud Spanner支持關系型數據庫所有的功能，但Cloud Spanner不完全是關系型數據庫，盡管Spanner的數據模型與任何其他關系數據庫的數據模型基本相似，有預定義的數據元組，可以存儲在關系(表)中并進行查詢，但它缺乏約束。

Cloud Spanner擁有主鍵概念，并且必須為每個表定義主鍵，而且該主鍵是強制唯一性的。然而它沒有foreign key的概念，取而代之的是interleave。在關系型數據庫中，我們期望數據的強完整性，以確保能滿足預定義的約束。Cloud Spanner在該方面的能力有所限制。

事務支持（ACID）

Cloud Spanner在事務上提供了最嚴格的并發控制，實現全球事務對外強一致性。在外部一致性的保證下，即使Cloud Spanner的實例位于多個數據中心上運行，事務也能在高性能和高可用性的前提下按順序執行。Cloud Spanner能夠實現外部一致性得益于TrueTime的功能特性。TureTime是Google為所有Google服務提供的高可用分布式的時鐘。該時鐘為應用提供單調遞增的時間戳。Cloud Spanner 使用 TrueTime 的這一特性為事務分配時間戳。具體而言，每個事務都分配有一個時間戳，它為Cloud Spanner提供事務發生的時間。[1]

其他特性

Cloud Spanner還有很多其他的特性，包括單區域和多區域配置、多語言支持等[2]

數據結構

Cloud Spanner和傳統RDBMS的數據模型基本一致，都是由行、列和值組成，并且含有主鍵。Cloud Spanner中的數據是強類型，每個表需要定義一個架構，并且每一列的數據都需要制定數據類型[3]。

CREATE TABLE customers(    customer_id   INT64  NOT NULL,    first_name    STRING(16),    last_name     STRING(16))PRIMARY KEY (customer_id)

其中，主鍵（PRIMARY KEY）被定義在表架構外。

數據的分布是通過主鍵實現的，因此在選擇主鍵的時候需要盡量防止Cloud Spanner服務的熱點（Hotspots），時間戳或者自增的序列數字都會造成熱點問題出現，Cloud Spanner推薦使用隨機（用戶名等）的信息或者UUIDs作為主鍵。

交錯表（Interleaved tables）

在Cloud Spanner中，是沒有辦法去定義兩表之間外鍵（FOREIGN KEY）關系的。但是Cloud Spanner引入了一個類似的概念--交錯表。

CREATE TABLE accounts(    customer_id     INT64  NOT NULL,    account_id      INT64  NOT NULL,    created_at      TIMESTAMP NOT NULL)PRIMARY KEY (customer_id, account_id),INTERLEAVE IN PARENT customers ON DELETE CASCADE;

以上架構中表示為customers表創建accounts子表或“交錯”表。其中需要注意的事項：

customer_id是子表accounts的主鍵之一，也是父表的customers的主鍵。在accounts聲明為customers子表時，該主鍵是必須添加的，并且要保證命名、類型、限制等都必須一致。
當插入子表時需要確保父表有對應的行（即以相同父表主鍵開頭的行）。
刪除父表行需要滿足其中兩點之一：在子表中沒有對應的行。聲明ON DELETE CASCADE。
ON DELETE CASCADE 聲明表示，當父表中的某一行被刪除時，子表中對應的行也會被自動刪除。如果沒有該聲明，或聲明為ON DELETE NO ACTION，則必須先刪除子行，才能刪除父行。
交錯行首先按父表的行進行排序，然后在父表共享主鍵的基礎上，對子表進行再排序。
在對數據庫進行分片操作的時候，只要父表行以及子表行的大小在8GB以內，并且在子表行中沒有熱點，則每個父表以及子表的數據的存放區域關系會一同保留下來。

交錯表的主要目的是為了加快某些查詢操作，尤其是包含JOIN的操作。因為交錯表直接改變了數據在云上的布局方式，確保在執行JOIN操作的時候不會訪問集群的每個節點（Nodes）。

二級索引（Secondary indexes）

在Cloud Spanner中，主鍵會被自動設置為表的索引，Cloud Spanner也同時支持將其他非主鍵字段設置為二級索引。

CREATE UNIQUE INDEX customer_index_name ON customers(first_name);

其中UNIQUE INDEX關鍵字表示，該索引會強制該字段在插入時需要不重復。并且在極少情況下，Cloud Spanner可能會自動選擇讓查詢延遲增加的索引，此時可以使用FORCE_INDEX關鍵字提供指定索引進行查詢操作。

SELECT * FROM customers@{FORCE_INDEX=customer_index_name}

數據庫分片（split）

在表之間，Cloud Spanner支持最多7層的父子關系，也就是可以將7個邏輯獨立的表的行物理地存儲在一起。當相關表數據不斷增長，達到單個Cloud Spanner服務器的資源限制時，作為分布式數據庫的Cloud Spanner會將數據劃分為各個“split”區塊，每個分片都可以被獨立移動并分配給不同物理位置的多個服務器。

分片包含一系列連續的行，這些行的開始和結束鍵稱為“分片邊界”（split boundaries）。Cloud Spanner 會根據大小和/或負載自動添加和移除分片邊界，這樣做會改變數據庫中的分片數量。

基于負載進行分片

當數據庫中的一個表上的10行數據的讀取頻率高于表中所有其他的行，Cloud Spanner就會為這10行中的每一行添加分片邊界，以便于每一行是由不同的服務器處理，以此來避免這10行數據的讀寫操作只消耗單臺服務器的資源（避免熱點）。

表結構的更新

Cloud spanner支持對現有的數據庫架構執行以下更新操作：

新建表。新表格中的列可以為 NOT NULL。
刪除一個表，前提是該表內沒有交錯其他表，并且沒有二級索引。
將一個非主鍵列添加到任何表，新的非主鍵列不能為 NOT NULL。
將 NOT NULL 添加到非主鍵列，不包括 ARRAY 列。
從非主鍵列中移除 NOT NULL。
從任何表中刪除非主鍵列，前提是二級索引未在使用該列。
將 STRING 列更改為 BYTES 列，或將 BYTES 列更改為 STRING 列。
增加或減少 STRING 或 BYTES 類型的長度限制，前提是它不是由一個或多個子表繼承的主鍵列。
在值和主鍵列中啟用或停用提交時間戳。
添加或移除任何二級索引。[4]

未來的趨勢

基于Cloud Spanner獨特的結構，它能確保客戶在以較小的用戶群和業務量為起點時，不必過多擔心在未來數據量和業務量增長后需要對數據庫進行遷移或重新編寫的問題。Cloud Spanner在保證關系型數據庫管理系統的特性前提下，同時提供數據庫的超強延展性，并且可以在特定情況下對已存在的表的表結構進行結構更新。

因此，無論應用程序規模如何，Cloud Spanner都會是不錯的選擇，它能為應用提供包括事務支持、高可用性保證、只讀副本以及輕松可伸縮性。

在《Google Cloud Spanner經濟性分析》的文章中介紹到，Cloud Spanner的總花費比本地數據庫服務花費低78%，比其他云平臺數據庫服務價格低37%。這得益于Cloud Spanner不需要用戶為額外副本服務支出費用，就能確保數據庫的高可用性。并且因為Cloud Spanner支持用戶在不停機的情況下對數據庫進行水平或垂直的縮放（由Cloud Spanner自動管理數據切片和數據復制）或對表結構進行更新例如添加索引等操作。

同時說明Cloud Spanner在使用經濟上也提供了比自己維護的數據庫服務更低的成本。

參考

外部一致性：https://cloud.google.com/spanner/docs/true-time-external-consistency#external_consistency
Cloud Spanner所有特性：https://cloud.google.com/spanner#section-8
Cloud Spanner數據類型：https://cloud.google.com/spanner/docs/data-types
提交時間戳： https://cloud.google.com/spanner/docs/commit-timestamp

文/Thoughtworks 劉勁宇

更多精彩洞見，請關注公眾號Thoughtworks洞見