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

接觸Cloud Spanner

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

選擇Cloud Spanner

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

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

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

特性

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

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

作為關(guān)系型數(shù)據(jù)庫(kù)

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

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

事務(wù)支持（ACID）

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

其他特性

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

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

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

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

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

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

交錯(cuò)表（Interleaved tables）

在Cloud Spanner中，是沒(méi)有辦法去定義兩表之間外鍵（FOREIGN KEY）關(guān)系的。但是Cloud Spanner引入了一個(gè)類似的概念--交錯(cuò)表。

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;

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

• customer_id是子表accounts的主鍵之一，也是父表的customers的主鍵。在accounts聲明為customers子表時(shí)，該主鍵是必須添加的，并且要保證命名、類型、限制等都必須一致。
• 當(dāng)插入子表時(shí)需要確保父表有對(duì)應(yīng)的行（即以相同父表主鍵開頭的行）。
• 刪除父表行需要滿足其中兩點(diǎn)之一：在子表中沒(méi)有對(duì)應(yīng)的行。聲明ON DELETE CASCADE。
• ON DELETE CASCADE 聲明表示，當(dāng)父表中的某一行被刪除時(shí)，子表中對(duì)應(yīng)的行也會(huì)被自動(dòng)刪除。如果沒(méi)有該聲明，或聲明為ON DELETE NO ACTION，則必須先刪除子行，才能刪除父行。
• 交錯(cuò)行首先按父表的行進(jìn)行排序，然后在父表共享主鍵的基礎(chǔ)上，對(duì)子表進(jìn)行再排序。
• 在對(duì)數(shù)據(jù)庫(kù)進(jìn)行分片操作的時(shí)候，只要父表行以及子表行的大小在8GB以內(nèi)，并且在子表行中沒(méi)有熱點(diǎn)，則每個(gè)父表以及子表的數(shù)據(jù)的存放區(qū)域關(guān)系會(huì)一同保留下來(lái)。

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

二級(jí)索引（Secondary indexes）

在Cloud Spanner中，主鍵會(huì)被自動(dòng)設(shè)置為表的索引，Cloud Spanner也同時(shí)支持將其他非主鍵字段設(shè)置為二級(jí)索引。

CREATE UNIQUE INDEX customer_index_name ON customers(first_name);

其中UNIQUE INDEX關(guān)鍵字表示，該索引會(huì)強(qiáng)制該字段在插入時(shí)需要不重復(fù)。并且在極少情況下，Cloud Spanner可能會(huì)自動(dòng)選擇讓查詢延遲增加的索引，此時(shí)可以使用FORCE_INDEX關(guān)鍵字提供指定索引進(jìn)行查詢操作。

SELECT * FROM customers@{FORCE_INDEX=customer_index_name}

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

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

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

基于負(fù)載進(jìn)行分片

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

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

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

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

未來(lái)的趨勢(shì)

基于Cloud Spanner獨(dú)特的結(jié)構(gòu)，它能確保客戶在以較小的用戶群和業(yè)務(wù)量為起點(diǎn)時(shí)，不必過(guò)多擔(dān)心在未來(lái)數(shù)據(jù)量和業(yè)務(wù)量增長(zhǎng)后需要對(duì)數(shù)據(jù)庫(kù)進(jìn)行遷移或重新編寫的問(wèn)題。Cloud Spanner在保證關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)的特性前提下，同時(shí)提供數(shù)據(jù)庫(kù)的超強(qiáng)延展性，并且可以在特定情況下對(duì)已存在的表的表結(jié)構(gòu)進(jìn)行結(jié)構(gòu)更新。

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

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

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

參考

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

文/Thoughtworks 劉勁宇

更多精彩洞見，請(qǐng)關(guān)注公眾號(hào)Thoughtworks洞見