Cloud Spanner
https://gyazo.com/a7a3e39d8d340c7d8dc5b5f10a630cbe
full managed, global scale relational DB
WhitePaper
特徴
RDB
水平スケールが得意
ストレージに限界はない
強い一貫性
料金は割高(?)
asia-northeast1-aで3ノードのインスタンスを立てるとだいたい30万/月かかる (2020/7/22時点)
インスタンスの構成
リージョナル
可用性 99.99%
CPU使用率65%に収める必要がある
マルチリージョナル
可用性 99.999%
CPU使用率45%に収める必要がある
1node(1000pu) 以下の場合 100pu 単位で指定可能
100pu で立てるだけなら 1万/月 くらい
この場合も regional SLA 99.99, multi-regional 99.999% 対象
設計
Primary Key, Table 設計
auto increment を使わない
primary key をもとに保存されるノードが決まるため、連番にしてしまうとホットスポットができる interleave
JOINするとき、複数のSplitからデータを取得するとネットワークを解すためパフォーマンスに影響がある
関連データ(親子関係のテーブル、index)を同じSplitに格納できる 機能
テーブルのpkに指定しているものが対象にするテーブルと同じSplitにテーブル/indexを配置することで高速化
spannerではindexもテーブルと同じくsplitに分散されるので、interleaveの指定が必要なことが多い
Session Pool 設定
冪等性
リトライすることが前提の設計になっている
Goにおいては ReadWriteTransactionの中がリトライされる index
FORCE_INDEX を使うことでindexを利用できる
Spannerにおいてはindexもテーブルと同様分散配置される
interleaveが重要
元
indexに指定されているカラム以外を取得したい場合、STORINGを使ってindexと同じ場所にデータを配置することで高速化出来る
pagination
OFFSETを使うとスキャンしてから捨てる
cursor pagination (直前のクエリの最後の値をwhereにいれる)
join
indexがあるときはたいていAPPLY_JOINを使う
内部構造
ノード
2TB/node
splitが割り当てられる (増減時には再配置)
格納されたデータはsplitとよばれるデータのまとまりに区切られる
1つのsplitが大きくなるor負荷が高くなると分割される
分断が発生した時、一貫性や可用性を犠牲にする必要がある
周辺ツール
ref