Google Cloud Professional Data Engineer試験では、データベースサービスの特性を正しく理解しているかが問われます。特にSpanner、Bigtable、Firestoreはそれぞれ整合性やトランザクションの仕組みが異なり、CAP定理の観点から切り分けないと混乱します。私自身も学習中に「結果整合性って本当に整合性と言えるのか？」「Spannerはなぜグローバルで強整合性を実現できるのか？」と疑問を持ちました。本記事では、試験中に迷わないために3サービスの整合性とトランザクション特性を整理します。

なぜ整合性で混乱するのか

  • 「結果整合性」という表現が曖昧で直感に反する
  • サービスごとの整合性レベルを丸暗記しがちだが、背景を理解していないと試験で応用が効かない
  • 強整合性を保証するSpannerと、AP寄りのサービスをどう区別するかが問われやすい

Spannerの特徴

グローバル分散と強整合性

SpannerはTrueTime APIを利用することで、リージョンをまたいだ強整合性を実現します。従来はCAP定理的に不可能と思われていた「可用性と分散と強整合性」を両立させているのが特徴です。

トランザクション

Spannerは分散環境でもフルACIDトランザクションをサポートします。試験では「グローバルスケール」「強整合性」「SQLサポート」が出題キーワードならSpannerが正解です。

一次情報：
https://cloud.google.com/spanner/docs/overview

Bigtableの特徴

高スループット・低レイテンシ

BigtableはNoSQLワイドカラムデータベースで、膨大なスループットを処理できます。単一クラスタ構成では行単位の強整合を提供しますが、マルチクラスタ複製を利用する場合は、デフォルトで結果整合性（eventual consistency）になります。試験問題に「高可用性のため複数クラスタに複製」と書かれていれば、この整合性の揺らぎを考慮する必要があります。

トランザクション

Bigtableは行レベルの原子性を提供するのみで、ACIDトランザクションはありません。試験では「時系列データ」「IoT」「分析前の大量データ格納」といったシナリオで登場します。

一次情報：
https://cloud.google.com/bigtable/docs/overview

Firestoreの特徴

ドキュメント指向と柔軟なスキーマ

Firestoreはドキュメント/コレクションモデルを採用し、モバイルやWebアプリ向けに最適化されています。

整合性とトランザクション

Firestoreは基本的に強整合な読み取り(Strong reads)を提供し、単一ドキュメントだけでなく複数ドキュメントにまたがるトランザクションもサポートします。ただし、リージョンをまたいだグローバル強整合性はSpannerほど強固ではありません。

一次情報：
https://cloud.google.com/firestore/docs/overview

試験での判断基準

  • グローバル分散・強整合・SQL・フルACID → Spanner
  • 超大規模スループット・行単位整合・分析前のデータ保持 → Bigtable
  • アプリ向けドキュメントDB・柔軟スキーマ・軽量トランザクション → Firestore

CAP定理と結果整合性の位置づけ

  • Spanner：強整合性を実現するために、可用性やレイテンシを犠牲にしつつTrueTimeで整合性を保証
  • Bigtable：可用性と分散スケーラビリティを優先し、整合性は単一行に限定
  • Firestore：強整合性を提供するが、スケール要件やリージョン間の制約でSpannerほどではない

実務と試験での違い

実務では「どの程度の整合性が必要か」を要件とコストで判断しますが、試験では「サービスの設計思想を理解しているか」が問われます。問題文に出てくるキーワードを正しく読み取り、3サービスの整合性特性にマッピングすることが重要です。

まとめ

Spanner、Bigtable、FirestoreはすべてGoogle Cloudの主要データベースですが、整合性とトランザクション特性が大きく異なります。試験では「強整合・グローバル・SQLならSpanner」「スループット重視・行単位整合ならBigtable」「アプリ向け・柔軟スキーマならFirestore」と整理すれば混乱しません。読了後は各サービスの公式ドキュメントを確認し、CAP定理の観点から再度比較してみると理解が定着します。