『GCPのストレージ・データベースはオブジェクトストレージ・アプリケーションDB・DWHの3分類で選ぶ』では、GCPの保存系サービスを「ファイル・オブジェクトの置き場」「アプリケーションDB（OLTP）」「分析基盤（OLAP / DWH）」の3つに分類しました。本記事はその中のアプリケーションDBを深掘りします。
GCPでアプリケーションのデータベースを選ぼうとすると、Cloud SQL、Spanner、Firestore、Bigtableという4つの候補が並びます。どれも「アプリが1件単位でデータを読み書きするDB」という点では同じ土俵にいますが、データモデルもスケールの仕組みも得意分野も別物です。名前と用途を1対1で暗記していると、似た要件を並べられたときに区別がつきません。
この記事では、この4つをデータモデルとスケール方式の2軸で整理し、要件のどのキーワードが出たらどのサービスを選ぶかをまとめます。もう1つの分類である分析基盤との違いは『【GCP】BigQueryとCloud SQLの違いと使い分け』で扱っています。
データモデルとスケール方式の2軸で位置付ける
4サービスは、データモデルとスケール方式の2軸で整理すると位置関係がつかめます。
| 垂直スケール中心 | 水平スケール | |
|---|---|---|
| リレーショナル | Cloud SQL | Spanner |
| NoSQL | — | Firestore（ドキュメント）/ Bigtable（ワイドカラム） |
縦のデータモデルは、リレーショナル（スキーマ固定でSQL・JOINが使える）か、NoSQL（ドキュメント型・ワイドカラム型）かの違いです。横のスケール方式は、インスタンスを大きくして性能を上げる垂直スケール中心か、ノードを増やして分散する水平スケールかの違いです。
この表から、選定の流れが見えてきます。
- リレーショナルが必要で、1インスタンスで収まる規模ならCloud SQL
- リレーショナルのまま水平スケールが必要ならSpanner
- NoSQLでよいなら、ドキュメント型のFirestoreかワイドカラム型のBigtableかをデータの形で選ぶ
そもそもRDBとNoSQLの構造的な違い（RDBがスケールアウトしにくい理由）は『応答速度×スケール方式によるデータベース分類: RDBがスケールアウトしない理由とNoSQLの3つの妥協』で、NoSQLのデータモデル4分類は『NoSQLの4分類を整理する: KVS・ワイドカラム・ドキュメント・グラフの本質的な違い』で扱っています。本記事はGCPサービスの使い分けに絞ります。
4サービスの比較表
| 観点 | Cloud SQL | Spanner | Firestore | Bigtable |
|---|---|---|---|---|
| データモデル | リレーショナル | リレーショナル | ドキュメント | ワイドカラム |
| エンジン/互換 | MySQL / PostgreSQL / SQL Server | GoogleSQL / PostgreSQL互換インターフェース | 独自（モバイル/WebのSDKが充実） | HBase API互換 |
| スケール | 垂直中心＋リードレプリカ | 水平（ノード追加） | 自動（サーバーレス） | 水平（ノード追加） |
| ロケーション | リージョナル（HA構成で2ゾーン） | リージョナル〜マルチリージョン | リージョナル〜マルチリージョン | ゾーン単位のクラスタ（レプリケーションで複数化） |
| トランザクション | あり（RDBそのもの） | あり（分散でも強整合） | あり | 単一行の原子性のみ |
| 得意 | 一般的なWebアプリ、既存RDB移行 | グローバル分散、書き込みも水平スケール | モバイル/Web、リアルタイム同期 | 時系列・IoT、巨大データの低レイテンシ読み書き |
| 不向き | 書き込みの水平スケール | 小規模システム（コスト過剰） | 複雑なJOIN・集計 | 小規模データ、多様なクエリパターン |
以降、各サービスを「向いている要件」と「向かない要件」で見ていきます。
Cloud SQLは一般的なWebアプリと既存RDB移行の第一候補
Cloud SQLは、マネージドなMySQL / PostgreSQL / SQL Serverです。RDBそのものなので、SQL・JOIN・トランザクションなど既存のRDBの知識と資産がそのまま使えます。
アプリケーションDBの選定では、Cloud SQLを基準にして、足りない要件があるときだけ他を検討するのが実用的な考え方です。
- 向いている要件
- 一般的なWebアプリケーションのバックエンドDB
- 既存のMySQL / PostgreSQL / SQL Serverからの移行（アプリ改修を最小にしたい）
- リレーショナルなデータとトランザクションが必要で、規模は1リージョンに収まる
- 向かない要件
- 書き込みが1インスタンスの垂直スケールで収まらない
- 複数リージョンにまたがる強整合な書き込みが必要
スケールの手段は、インスタンスのスペックを上げる垂直スケールと、読み取りを分散するリードレプリカです。書き込みそのものは水平スケールしません。ここがSpannerとの境界です。
可用性を高めるHA構成（2ゾーンのプライマリ＋スタンバイ）とレプリカの詳細は『Cloud SQL HAとcross-region replicaの違い: DBのzone冗長とregion冗長』で扱っています。
Spannerはリレーショナルのまま水平スケールする
Spannerは、リレーショナルモデルと強整合性を保ったまま水平スケールとグローバル分散を実現するDBです。「RDBはスケールアウトしない」という一般則に対する、GCPの回答にあたるサービスです。
- 向いている要件
- 書き込みも含めて水平スケールしたい（リードレプリカでは足りない）
- グローバル分散（複数リージョンにデータを置き、どこからでも強整合で読み書きする）
- リレーショナルモデルとトランザクションは手放せない
- 向かない要件
- Cloud SQLの規模で収まる（Spannerは最小構成でも相応のコストがかかり、小規模には過剰です）
- リレーショナルである必要がそもそもない（NoSQLで足りるならそちらが安い）
Cloud SQLとの境界は「垂直スケールとリードレプリカで足りるか」です。「グローバルなユーザーに単一のDBを提供したい」「リージョン障害でも書き込みを継続したい」「トランザクションを維持したまま水平スケールしたい」という要件が並んだら、Spannerの出番です。
Spannerのマルチリージョン構成が何を担保するかは『GCPのmulti-regionデータサービス: Firestore・Spanner・Cloud Storage・BigQueryの違い』で扱っています。
Firestoreはモバイル/Web向けのドキュメントDB
Firestoreは、サーバーレスなドキュメントDBです。JSONライクなドキュメントの集まりとしてデータを持ち、スキーマを事前に固定しません。
他の3つと毛色が違うのは、クライアント（モバイル/Webアプリ）から直接使われることを想定した機能が中心にあることです。
- 向いている要件
- モバイルアプリ / Webアプリのバックエンド
- リアルタイム同期（データ変更をクライアントに即時反映する）
- オフライン対応（モバイルSDKがローカルキャッシュと再同期を担う）
- スキーマが柔軟に変わる、サーバーレスで運用の手間を減らしたい
- 向かない要件
- 複雑なJOINや集計クエリが必要（ドキュメントDBの苦手分野です）
- 既存RDBの移行先（データモデルが違いすぎます）
- 時系列データの大量書き込み（後述のBigtableの領域です）
ドキュメントDBというデータモデル自体の特徴は『NoSQLの4分類を整理する: KVS・ワイドカラム・ドキュメント・グラフの本質的な違い』で扱っています。
Bigtableは巨大データの低レイテンシ読み書きに特化
Bigtableは、ワイドカラム型のNoSQLです。HBase API互換で、行キーを設計してその行キーで引く、という使い方に特化しています。
- 向いている要件
- 時系列データ・IoT・センサーデータの大量書き込み
- テラバイト級以上の巨大データに対する低レイテンシの読み書き
- アクセスパターンが行キー中心に定まっている（「このデバイスの直近データ」など）
- 向かない要件
- データが小さい（Bigtableの設計が生きるのは大規模データであり、小規模には過剰です）
- SQLで多様なクエリを投げたい、セカンダリインデックスやJOINに頼りたい
- 複数行にまたがるトランザクションが必要（原子性は単一行のみです）
Firestoreとの使い分けは「誰が使うDBか」で考えると分かりやすいです。Firestoreはモバイル/Webアプリのユーザーデータを扱う汎用ドキュメントDB、Bigtableはバックエンドの大規模データ基盤です。「リアルタイム同期」ならFirestore、「時系列・IoT・巨大スループット」ならBigtableです。
またBigtableは分析基盤ではありません。蓄積データをSQLで自由に集計したいならBigQueryの領域で、実際「書き込みと参照はBigtable、分析はBigQuery」という併用構成も使われます。
Memorystoreは代替ではなく手前に置くキャッシュ
Memorystoreは、マネージドなRedis / Memcachedです。DB選定の文脈で登場しますが、上の4つの代替ではなく、手前に置いて併用するキャッシュ層です。
- インメモリなので高速ですが、データを失わない保証を前提にしない層です
- 読み取りが多いデータのキャッシュ、セッション管理、ランキングのような一時データに使います
- 「DBの負荷を下げたい」「読み取りレイテンシを下げたい」が要件のとき、DBを乗り換える前にキャッシュの追加を検討します
「セッション管理」「キャッシュ」「ミリ秒を争う読み取り」というキーワードが出たら、DB本体を乗り換えるのではなく、Memorystoreの追加を検討する場面です。
要件キーワードから引くDB選定の早見表
| 要件キーワード | 選ぶもの |
|---|---|
| 一般的なWebアプリのDB、既存RDBの移行 | Cloud SQL |
| 読み取り負荷の分散 | Cloud SQL＋リードレプリカ |
| ゾーン障害への耐性 | Cloud SQL HA構成 |
| 書き込みも水平スケール、グローバル分散、それでも強整合 | Spanner |
| モバイル/Web、リアルタイム同期、オフライン対応 | Firestore |
| 時系列・IoT、巨大データの低レイテンシ読み書き | Bigtable |
| キャッシュ、セッション管理 | Memorystore（DBと併用） |
| 蓄積データの集計・分析 | BigQuery（本記事の対象外、分析基盤） |
まとめ
Cloud SQL・Spanner・Firestore・Bigtableは、データモデル（リレーショナルかNoSQLか）とスケール方式（垂直か水平か）の2軸で位置付けると区別できます。
- 基準はCloud SQL。一般的なWebアプリと既存RDB移行はここで足ります
- リレーショナルのまま水平スケール・グローバル分散が必要になったときだけSpanner
- モバイル/Webのリアルタイム同期ならFirestore、時系列・IoTの巨大データならBigtable
- Memorystoreは代替ではなく、どのDBにも併用できるキャッシュ層