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

接觸Cloud Spanner

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

選擇Cloud Spanner

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

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

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

特性

作為分布式數(shù)據(jù)庫

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

作為關系型數(shù)據(jù)庫

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

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

事務支持（ACID）

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

其他特性

Cloud Spanner還有很多其他的特性，包括單區(qū)域和多區(qū)域配置、多語言支持等。

數(shù)據(jù)結(jié)構(gòu)

Cloud Spanner和傳統(tǒng)RDBMS的數(shù)據(jù)模型基本一致，都是由行、列和值組成，并且含有主鍵。Cloud Spanner中的數(shù)據(jù)是強類型，每個表需要定義一個架構(gòu)，并且每一列的數(shù)據(jù)都需要制定數(shù)據(jù)類型。

其中，主鍵（PRIMARY KEY）被定義在表架構(gòu)外。

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

交錯表（Interleaved tables）

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

以上架構(gòu)中表示為customers表創(chuàng)建accounts子表或“交錯”表。其中需要注意的事項：

(1) customer_id是子表accounts的主鍵之一，也是父表的customers的主鍵。在accounts聲明為customers子表時，該主鍵是必須添加的，并且要保證命名、類型、限制等都必須一致。?

(2) 當插入子表時需要確保父表有對應的行（即以相同父表主鍵開頭的行）。?

(3) 刪除父表行需要滿足其中兩點之一：?

• 在子表中沒有對應的行。?
• 聲明ON DELETE CASCADE。?

(4) ON DELETE CASCADE 聲明表示，當父表中的某一行被刪除時，子表中對應的行也會被自動刪除。如果沒有該聲明，或聲明為ON DELETE NO ACTION，則必須先刪除子行，才能刪除父行。?

(5) 交錯行首先按父表的行進行排序，然后在父表共享主鍵的基礎上，對子表進行再排序。?

(6) 在對數(shù)據(jù)庫進行分片操作的時候，只要父表行以及子表行的大小在8GB以內(nèi)，并且在子表行中沒有熱點，則每個父表以及子表的數(shù)據(jù)的存放區(qū)域關系會一同保留下來。?

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

二級索引（Secondary indexes）

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

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

數(shù)據(jù)庫分片（split）

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

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

基于負載進行分片

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

表結(jié)構(gòu)的更新

Cloud spanner支持對現(xiàn)有的數(shù)據(jù)庫架構(gòu)執(zhí)行以下更新操作：

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

未來的趨勢

基于Cloud Spanner獨特的結(jié)構(gòu)，它能確?？蛻粼谝暂^小的用戶群和業(yè)務量為起點時，不必過多擔心在未來數(shù)據(jù)量和業(yè)務量增長后需要對數(shù)據(jù)庫進行遷移或重新編寫的問題。Cloud Spanner在保證關系型數(shù)據(jù)庫管理系統(tǒng)的特性前提下，同時提供數(shù)據(jù)庫的超強延展性，并且可以在特定情況下對已存在的表的表結(jié)構(gòu)進行結(jié)構(gòu)更新。

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

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

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