1 of 43

Cloud Spanner FAQ

@pchatsu

1

2 of 43

What’s Cloud Spanner ?

Google Cloud PlatformのRDB製品

SQL
強整合性
高可用性
スケーラブル
フルマネージド

2

3 of 43

Goal

今日のGoal

技術選定の際にCloud Spannerを選択肢として検討できる

3

4 of 43

Contents

アーキテクチャ
得意なこと
現在地とロードマップ

4

FAQを通して、これらのトピックを理解していきましょう

5 of 43

Cloud SpannerはRDBですか？

5

6 of 43

Cloud SpannerはRDBですか？

6

RDBの顔

SQL
トランザクション
強整合性

KVSの顔

アーキテクチャ
水平スケールが容易
外部キー制約が使えない

RDBの皮をかぶったKVS

7 of 43

Cloud SpannerはRDBですか？

7

RDBの顔

SQL
トランザクション
強整合性

KVSの顔

アーキテクチャ
水平スケールが容易
外部キー制約が使えない

RDBの皮をかぶったKVS

8 of 43

Cloud SpannerはRDBですか？

8

Entry Point

Node

コンピューティング層

ストレージ層

Split

1 - 100

101 - 200

201 - 250

※Colossus 分散ファイルシステム上にある

251 - 300

301 - 400

401 - 500

501 - 600

601 - 700

701 - 800

9 of 43

Cloud SpannerはRDBですか？

9

Entry Point

Node

コンピューティング層

ストレージ層

Split

1 - 100

101 - 200

201 - 250

※Colossus 分散ファイルシステム上にある

251 - 300

301 - 400

401 - 500

501 - 600

601 - 700

701 - 800

レコードをsplit単位で管理している
読み書き処理の実行を行う
スケールアウトの単位になっている

10 of 43

Cloud SpannerはRDBですか？

10

Entry Point

Node

コンピューティング層

ストレージ層

Split

1 - 100

101 - 200

201 - 250

※Colossus 分散ファイルシステム上にある

251 - 300

301 - 400

401 - 500

501 - 600

601 - 700

701 - 800

テーブルのレコードが分割されて格納されている
PKのレンジで分割される
分割は自動的で行われる
負荷状況に対応して再分割される
１つのNodeに紐づく

11 of 43

Cloud SpannerはRDBですか？

Splitの具体例

11

company_id (PK)	name	tel
1	hoge	001-0000
2	fuga	002-0000
3	piyo	003-0000
...

101	foo	101-0000
102	bar	102-0000
103	baz	103-0000
...

company_id: 1 ~ 100 のSplit

company_id: 101 ~ 200 のSplit

12 of 43

Cloud SpannerはRDBですか？

12

Entry Point

Node

コンピューティング層

ストレージ層

Split

1 - 100

101 - 200

201 - 250

251 - 300

301 - 400

401 - 500

501 - 600

601 - 700

701 - 800

Split

1 - 50

51 - 100

101 - 200

テーブルごとに分割の範囲は異なる

13 of 43

Cloud SpannerはRDBですか？

Tips

なぜそういうアーキテクチャになっているのかについては、Googleのデータベース製品の歴史をたどると理解しやすい
GCP Databaseの世代交代 by @sinmetalさん

13

14 of 43

GCP Databaseの系譜 (sinmetalの主観)

14

Bigtable

Datastore

Spanner

Realtime DB

Firestore

2006年

論文公開

2011年

リリース

2013年

論文公開

2017年

リリース

引用

https://gcpug.jp

15 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

15

16 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

基本的には使えます！

抑えておきたい独自仕様

インターリーブ
DML(INSERT, UPDATE, DELETE)は使えない
シーケンシャルなPKは避ける
セカンダリインデックスもテーブル

16

17 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

インターリーブ

テーブルに親子関係を定義できる

17

18 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

18

company_id (PK)	name	tel	employee_id (PK)	name
1	hoge	001-0000
1			1	Taro
1			2	Jiro
2	fuga	002-0000
2			3	Saburo
3	piyo	003-0000
...

company_id (PK)	employee_id (PK)	name
1	1	Taro
1	2	Jiro
2	3	Saburo

company_id (PK)	name	tel
1	hoge	001-0000
2	fuga	002-0000
3	piyo	003-0000

Companyテーブル

Employeeテーブル

Splitでの物理的な配置

親子関係にあるレコードが同じSplitにあることが保証される

その結果、JOIN処理が安定して速くなる

19 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

DML（INSERT, UPDATE, DELETE）は現時点では使えない

更新系はクライアントSDKを使って実装

19

20 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

Google Cloud Next ‘18でのロードマップで年内リリースが発表！

DMLサポート
JDBCサポート

20

21 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

シーケンシャルなPKは使えない

ホットスポットが発生してしまう

21

Entry Point

Node

コンピューティング層

ストレージ層

Split

1 - 100

101 - 200

201 - 250

251 - 300

301 - 400

401 - 500

501 - 600

601 - 700

701 - 800

(1, “hoge”, “001-0000”)

(2, “fuga”, “002-0000”)

(3, piyo, “002-0000”)

…

とシーケンシャルなPKが連続で挿入された

このNodeだけに集中して負荷がかかる

= ホットスポット

22 of 43

PKの戦略

PKにしたい値から、分散する値を生成する

ハッシュ

Hash(1) -> Xjead = Xjead@1

逆順

ID + 小分類 + 中分類 + 大分類

Shard

crc32c(2018/06/10 18:36:37 …) % 10 = Modulo @2018/06/10 18:36:37 …

22

引用

https://gcpug.jp

23 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

セカンダリインデックスもテーブル

23

company_id (PK)	name	tel
1	hoge	001-0000
2	fuga	002-0000
3	piyo	003-0000

key	PK
fuga	2
hoge	1
piyo	3

ベーステーブル

nameカラムに貼ったセカンダリインデックス

インデックスを使った参照

keyから対象レコードのPKを特定
PKを使ってベーステーブルのレコードを参照

24 of 43

既存のDDL/SQLやテーブル設計のノウハウは使えますか？

とあるSQLをチューニングしていきましょう

デモ

24

25 of 43

Productionで使うDBの選択肢としてどうですか？

25

26 of 43

Productionで使うDBの選択肢としてどうですか？

観点を分けると

どういうサービスに向いていますか？
運用面のサポートはどうなっていますか？
新規/既存サービスでの選択肢としてどうですか？

26

27 of 43

どういうサービスに向いてますか？

27

28 of 43

どういうサービスに向いていますか？

大量データが蓄積されるサービス
特定のJOIN処理を大量にさばく必要があるサービス
全世界に展開し、強整合性を担保しないといけないサービス

28

29 of 43

どういうサービスに向いていますか？

大量データが蓄積されているサービス

テラバイトサイズ
サービス要求としてデータのパージできない
新しいデータにも古いデータにもアクセスが来る

29

30 of 43

どういうサービスに向いていますか？

特定のJOIN処理を大量にさばく必要があるサービス

例えば音楽データを扱うサービス

アーティストを軸にアルバム、曲などの情報を頻繁にJOINする処理が発生

30

31 of 43

どういうサービスに向いていますか？

全世界に展開し、強整合性を担保しないといけないサービス

例えばゲーム

31

32 of 43

ランニングコストは高いの？

32

33 of 43

ランニングコストは高いの？

ベースの費用は高いがスケールアウトに対してはリーズナブル

プロダクションでの最低ノードは3つ
30万円~/月

https://cloud.google.com/spanner/pricing

33

34 of 43

運用面のサポートはどうなっていますか？

34

35 of 43

運用面のサポートはどうなっていますか？

マネージできる項目

ノード数のみ
ノードを増やすと、計算リソース、ストレージがともに増える

35

36 of 43

運用面のサポートはどうなっていますか？

監視項目

CPU使用率
クエリのスループット

36

37 of 43

運用面のサポートはどうなっていますか？

Google Cloud Next ‘18でのロードマップで年内リリースが発表！

クエリスタッツ
スロークエリの検知

37

38 of 43

新規/既存サービスでの選択肢としてアリですか？

38

39 of 43

新規/既存サービスでの選択肢としてどうですか？

Cloud Spannerが得意なことが課題である、または課題になりそうな場合はアリ👍

参考: 得意なこと

大量データを扱える
特定のJOIN処理を大量にさばける
マルチリージョンで強整合性を担保できる

39

40 of 43

新規/既存サービスでの選択肢としてどうですか？

ユースケースは変わり得るためテーブル設計は慎重に

インターリーブは不可逆です！

40

company_id (PK)	name	tel	employee_id (PK)	name
1	hoge	001-0000
1			1	Taro
1			2	Jiro
2	fuga	002-0000
2			3	Saburo
3	piyo	003-0000
...

再掲）Splitでの物理的な配置

インターリーブを使った場合、

子レコードだけのレンジスキャンは遅い

41 of 43

新規/既存サービスでの選択肢としてどうですか？

開発コストはそれなりにかかる

必須項目

全てのユースケースを洗い出してSpanner用のテーブル再設計
取得系のSQLをSpanner用クエリに書き換え
更新系のSQLをSDKでの記述に書き換え

41

42 of 43

新規/既存サービスでの選択肢としてどうですか？

既存データの移行について

Google Cloud Dataflow
Cloud Next ‘18のセッション

42

43 of 43

まとめ

アーキテクチャ

RDB on KVS

得意なこと

大量データを扱える
特定のJOIN処理を大量にさばける
マルチリージョンで強整合性を担保できる

現在地とロードマップ

現状、開発周りは発展途上の段階
Productionで要求される機能を揃えつつある

43