概要

Cloud Spannerの知見を漁ったのでメモ。走り書きなのでカテゴライズしていない。

メモ

計画メンテナンスやスキーマ変更のためのダウンタイムなし、最大99.999%の可用性を保証
- Cloud SQLはダウンタイムありの計画のメンテナンス
Cloud Spannerのアーキテクチャ構成
- クライアント
  - R/Wするコードが実行されているサーバーやコンテナ
  - クライアントライブラリを使うとgRPCやREST APIで通信できる
- ノード
  - R/W処理を実行するコンピュートリソース
  - ノードにはローカルストレージ（ディスク）はアタッチされていない
  - データは分散ファイルシステム（インターナルネーム Colossus）に保存される
    - ColossusはGoogle File Systemの後継のクラスタレベルのファイルシステム
      - Googleが運用する色々なサービスで使われているストレージ基盤らしい
- Split
  - Cloud Spannerにおけるデータの単位
  - 特定のノードから管理される
  - 容量の上限は4GBで、超えると新しいSplitが生成され、データが分割される
レプリケーション
- 読み書きレプリカ
- 読み取り専用レプリカ
- ウィットネスレプリカ
  - データベースの完全なコピーを持たない、投票にだけ参加するレプリカ
READしかしない箇所はRead-Only Transactionの利用を推奨。読み込みしかできないがロックを取らないため他のトランザクションをブロックすることがない。Read-Only Transactionの中身はリトライされても大丈夫なように冪等を保つ
hotspotが生じていても1Node分の性能は出る。なので開発・試験環境で1Nodeで実行しているとhotspotに気づきにくい。負荷検証時は注意
Nodeの増減だけではなくSplitが生成されることでデータが分散し、性能が出る
- Splitはload-based split（write/readによる負荷上昇）、size-based split（データ量が増加）によって生成される
- warmupしておきたいときなどは留意しておく
インデックスも通常のテーブルと同じくテーブルに格納される
- インデックスもインターリーブすることができる
インデックス生成はノード数やデータ量によって時間がかかるため注意（テーブル作成時が一番作成効率が良い）
キーの特定の値にデータが集中することが想定される場合は、最初からインデックスを作成しないほうが良いかもしれない（ホットスポットが発生する可能性がある）
既にレコード数が多い既存テーブルにインデックスを追加する場合は、1日に追加するインデックスの数を気をつける（ドキュメント曰く3つくらいが良いらしい）
- インデックスを追加しすぎるとSpannerのシステム負荷が高まってパフォーマンスが低下する可能性がある
STORING句を使うとインデックスに追加の列を格納することができる
- 参照が多い場合に特に有効。書き込みが多いと書き込みコストが高くなるため注意
FORCE_INDEXと使うか、カバリングインデックスを使うかはクエリの実行計画を参照したほうが良さそう
インデックス列の並び順は、不要なディスクシークを避けるために、取得したい順とするのが無難
インターリーブは最大6段まで可能
インターリーブされている子テーブルのインターリーブは外すことができない
mutationの数え方
- トランザクションに含まれるColumn*rowの数
  - Mutations per commit (including indexes) : 20000
- mutationの上限を意識するときは注意
- Google Cloud Spanner Deep Diveを参照

所感

設計を間違うとspannerのスケーラビリティを活かせず十分なパフォーマンスが出ない。計画メンテやスキーマ変更にダウンタイムなしは運用上の大きなメリット。 Splitの気持ちになってデータの分散を意識しないと運用時最大限のパフォーマンスを発揮できない。日本語の記事ばかり漁ってたので海外の記事ももっと見ておいたほうが良いかも。

Spannerの知見メモ

概要

メモ

所感

参考