【実務・中級編】 RDBMSとの比較 – Cloud Spanner

RDBMSの限界を超えろ：Cloud Spannerがもたらす「スケーラビリティの聖杯」

RDBMSを使い続けてきたエンジニアが、ある日突然「データ量がテラバイトを超え、秒間数万の書き込みが同時に発生する」という壁にぶつかる。その時、多くの現場で行われるのが「MySQLのシャーディング」という名の茨の道だ。

アプリケーションレイヤーでキーを分離し、クロスシャードクエリに頭を抱え、整合性の崩壊に怯える。そんな悪夢から解放されたいか？それなら、Cloud Spannerを理解する必要がある。

これは単なる「分散データベース」ではない。物理法則と格闘したGoogleが到達した、分散システムにおける「整合性とスケーラビリティの両立」という難問への回答だ。

—

1. 従来のRDBMSがぶつかる「物理的限界」

MySQLやPostgreSQLは、基本的に「1台のノード（あるいは垂直統合されたレプリケーション構成）」で完結することを前提に設計されている。

垂直スケールの天井: CPU、メモリ、ディスクI/Oの限界が必ず来る。
シャーディングの代償: データを分割した瞬間、RDBMSの最大の武器である「ACIDトランザクション」が壊れる。アプリ側で分散トランザクションを管理する地獄が始まる。
運用コストの肥大化: リードレプリカのラグ、フェイルオーバーの自動化、メンテナンス時のロック。これら全てが、エンジニアの貴重な時間を奪う。

—

2. Spannerの真実：TrueTimeが変えたゲームのルール

なぜSpannerは、世界規模で整合性を保ちながらスケールできるのか？その核心は TrueTime API にある。

従来のデータベースは「今、この瞬間に何が起きているか」をノード間で同期するために、膨大なメッセージのやり取り（Paxosプロトコル）を必要とし、それがボトルネックになっていた。

Spannerは、GPSと原子時計を用いて「時刻の不確実性（誤差）」をハードウェアレベルで定義している。「確実にこの時間以降である」ということを物理的に保証できるため、ノード間での過度な通信を抑えつつ、厳密な外部整合性（External Consistency）を実現している。

結論: 「Spannerは、分散されていることをアプリケーションに意識させない」という設計思想が、設計の難易度を劇的に下げるのだ。

—

3. 実務で「Spannerを殺さない」ための設計パターン

Spannerは強力だが、MySQLの延長線上で設計してはいけない。以下の3点は、設計レビューで私が必ずチェックするポイントだ。

① インターリーブ（Interleaving）で物理配置を最適化せよ

Spannerは階層構造を持てる。親テーブルと子テーブルを「インターリーブ」させれば、ディスク上で物理的に隣接して格納される。

— 親テーブル
CREATE TABLE Users (
UserId INT64 NOT NULL,
Name STRING(MAX)
) PRIMARY KEY (UserId);

— 子テーブルをインターリーブさせて物理的に密結合させる
— 結合クエリが爆速になる
CREATE TABLE UserStats (
UserId INT64 NOT NULL,
StatKey STRING(MAX),
Value INT64
) PRIMARY KEY (UserId, StatKey),
INTERLEAVE IN PARENT Users ON DELETE CASCADE;

② 「ホットスポット」を回避する主キー戦略

RDBMSでよくやる「連番（AUTO_INCREMENT）」をSpannerで使うのは自殺行為だ。全書き込みが単一の分割（スプリット）に集中し、スケーリングの恩恵が一切受けられない。

対策: `UUID v4` を使うか、キーの先頭にハッシュ値を付与して書き込みを分散させること。

③ トランザクションの「範囲」を最小化せよ

Spannerのトランザクションは分散環境で行われる。1つのトランザクションで何千行も更新しようとすれば、ロックの競合でパフォーマンスは急落する。「1トランザクションで更新するのは数〜数十行」を鉄則とせよ。

—

4. パフォーマンスの注意点：読み取りの極意

Spannerの真価は、読み取りの柔軟性にある。

Staleness（鮮度）の活用: リアルタイムの最新データが不要なレポート処理などは、`read_timestamp` を指定して「過去のデータ」を読み取れ。これだけで、更新系トランザクションに一切の負荷をかけずに高速なスキャンが可能になる。

5秒前のスナップショットを読み取る（非ブロック読み取り）
with spanner_client.snapshot(exact_staleness=timedelta(seconds=5)) as snapshot:
# 競合のない読み取りが可能。パフォーマンスへの影響は皆無だ。
results = snapshot.execute_sql(“SELECT FROM LargeTable”)

—

最後に：チーフアーキテクトからの助言

Spannerは「魔法の杖」ではない。誤ったスキーマ設計をすれば、MySQLよりも遅く、高額なシステムが出来上がるだけだ。

だが、「整合性を担保したまま、ボタン一つでノードを増やせる」という安心感は、ビジネスのフェーズが上がった際に何物にも代えがたい資産となる。

設計時には必ず「このデータアクセスは分散しても効率的か？」を自問自答せよ。その問いに対する答えがYesなら、Spannerは君たちの最強の武器になるはずだ。

次は、実際のインデックス設計とクエリ実行計画の読み解きについて深掘りしよう。エンジニアの腕の見せ所は、そこからだ。