Cloud Service
データベース
Google Cloud のDBの選び方。リレーショナルか、NoSQLか、キャッシュか、分析(DWH)か。要件から逆引きで即断できる早見表。
基礎
最終更新: 2026-06-04
要件から逆引き
| 要件 | 選ぶもの |
|---|---|
| 一般的なリレーショナルDB(SQL/JOIN) | Cloud SQL |
| 高性能・PostgreSQL互換で分析も速い | AlloyDB for PostgreSQL |
| グローバルで強整合・無限水平スケール | Cloud Spanner |
| サーバーレスNoSQL・モバイル/Web同期 | Firestore |
| 超低遅延・大量書き込みのワイドカラム | Cloud Bigtable |
| 読み取りを高速化するキャッシュ | Memorystore (Redis/Memcached) |
| TB〜PB級の集計・分析(DWH) | BigQuery |
リレーショナルの3択（Cloud SQL / AlloyDB / Spanner）
| 観点 | Cloud SQL | AlloyDB | Cloud Spanner |
|---|---|---|---|
| エンジン | MySQL/PostgreSQL/SQL Server | PostgreSQL互換 | 独自(GoogleSQL/PG方言) |
| スケール | 縦＋リードレプリカ | 縦＋リードプール・列指向で高速 | 水平・ほぼ無限・自動 |
| 可用性 | リージョン内HA(同期スタンバイ) | リージョン内HA・自動フェイルオーバ | マルチリージョン・99.999% |
| 強整合 | 単一インスタンス内 | 単一プライマリ | グローバルに強整合(TrueTime) |
| 向き | 既存資産/汎用RDB | 高負荷RDB＋HTAP | グローバル・無停止スケール |
まず Cloud SQL、足りなければ上位へ
汎用のRDBはまず Cloud SQL で十分か考えるのが基本。書き込み/読み取り性能や分析クエリが頭打ちなら PostgreSQL互換の AlloyDB へ。地理分散で強整合・無停止の水平スケールが要るなら Cloud Spanner を選びます（その分コストと設計難度は上がる）。
NoSQL の2択（Firestore / Bigtable）
| 観点 | Firestore | Cloud Bigtable |
|---|---|---|
| データモデル | ドキュメント(コレクション) | ワイドカラム(キー×列ファミリ) |
| 得意 | モバイル/Web・リアルタイム同期 | 時系列・IoT・大量書き込み |
| クエリ | インデックス付きクエリ・SDK同期 | 行キー範囲スキャン中心(JOINなし) |
| スケール | サーバーレス・自動 | ノード追加で線形(数ms遅延) |
| 課金 | 読み書き/保存の従量 | ノード時間＋ストレージ |
Firestore と Bigtable の境界
- アプリのバックエンド・オフライン同期・中小規模 → Firestore
- 数百万 QPS・PB級・行キー設計でスキャンする時系列/解析 → Bigtable Bigtable は 行キー設計がすべて。アクセスパターンを先に決め、ホットスポットを避ける設計が前提です。
キャッシュ・分析
| やりたいこと | 使うもの | AWS対応 |
|---|---|---|
| DBの前段でキャッシュ・低遅延読み取り | Memorystore for Redis | ElastiCache (Redis) |
| セッション/カウンタ等の単純キャッシュ | Memorystore for Memcached | ElastiCache (Memcached) |
| TB〜PB級を集計・BI・SQL分析 | BigQuery (サーバーレスDWH) | Redshift |
BigQuery は OLTP ではない
BigQuery は列指向のサーバーレスDWHで、大量データの集計・分析(OLAP) 向け。1行ずつの更新や低遅延トランザクション(OLTP)には不向きなので、業務トランザクションは Cloud SQL / Spanner、分析は BigQuery と役割を分けるのが基本です。
迷ったら
- JOINや複雑なSQLが要る汎用RDB → Cloud SQL（高負荷ならAlloyDB）
- グローバルで強整合・水平スケール → Cloud Spanner
- モバイル/WebのサーバーレスNoSQL → Firestore
- 時系列・IoT・超大量書き込み → Cloud Bigtable
- DBの前にキャッシュして高速化/負荷軽減 → Memorystore
- TB級を集計・BI → BigQuery
アンチパターン / ひっかけ
- リージョン内HAは可用性、リードレプリカは読み取りスケール（Cloud SQL）。混同しない
- グローバル強整合を Cloud SQL/Firestore に求めない。それは Spanner の役割
- Firestore/Bigtable はアクセスパターン駆動設計。後付けの複雑なJOIN/集計は不向き
- 接続情報をハードコードせず、Secret Manager と IAM で権限を渡す
Google Cloud Service
データベースを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
cheatsheets
比較で見る軸
クラウド: Google Cloud / カテゴリ: cheatsheets / 難易度: basic
導入後に効く点
導入後の運用手順、権限、監視、更新方法まで含めて評価します。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
数字・仕様の読み方
- クラウド
- Google Cloud
- カテゴリ
- cheatsheets
- 難易度
- basic
- 関連資格
- —
- 設計柱
- —
判断チェックリスト
- 自社の用途が「cheatsheets」に近いか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。
次に確認する観点
cheatsheets