【GCP】データベース関連サービスの選定

Google Cloudのデータベース関連のサービスの特徴と選定方法を解説します。

以下のような読者を想定しています。

• GCPでインフラ構築することが決まった！データベースは何を使おう、、、
• GCPの資格の勉強中！データベースのサービスが多すぎる、、、

最初に選定方法から始め、ボトムアップ的な流れで説明していきます。

サービス選定フロー

【STEP 1】キャッシュ・超低レイテンシが必要？

• はい（セッション管理・API キャッシュ・リアルタイムランキング） →

Memorystore 

• いいえ → STEP 2 へ

【STEP 2】目的は何？

• データ分析・BI がしたい → BigQuery 
• アプリケーションのバックエンド DB が欲しい → STEP 3 へ
• IoT・時系列・ストリーミングデータの処理 → Bigtable

【STEP 3】SQL を使う？

• いいえ（柔軟なスキーマで OK） → Firestore
• はい（SQL を使いたい） → STEP 4 へ

【STEP 4】規模・要件はどのくらい？

• 小〜中規模、コスト重視 → Cloud SQL
• 高トラフィック・高パフォーマンスが必要 → AlloyDB 
• グローバル展開・99.999%の可用性が必要 → Cloud Spanner 

比較表

*参考

• RDB（リレーショナルデータベース）：テーブル形式でデータを管理。SQL が使える
• NoSQL：柔軟なスキーマで大量・多様なデータを扱う
• DWH（データウェアハウス）：大規模なデータ分析・集計に特化
• インメモリ：メモリ上でデータを管理し、超高速アクセスを実現

各サービス解説

Cloud SQL

カテゴリ：RDB（リレーショナルデータベース） ｜ 難易度：★☆☆☆☆

MySQL・PostgreSQL・SQL Server に対応したフルマネージドの RDB サービスです。オンプレミスのデータベースと操作感がほぼ同じなので、既存の知識をそのまま活かせます。バックアップや高可用性構成も Google Cloud 側が自動で管理するため、インフラ運用の負担が大幅に軽減されます。小〜中規模の Web アプリケーションや業務システムの定番選択肢です。

• 向いている用途：個人開発・社内ツール・中規模 Web サービス
• 向いていない用途：グローバル展開・ペタバイト規模のデータ

AlloyDB

カテゴリ：RDB（リレーショナルデータベース） ｜ 難易度：★★☆☆☆

2022 年に Google が発表した PostgreSQL 互換のフルマネージド RDB です。Cloud SQL と同様に PostgreSQL の構文が使えますが、Google が独自開発した「カラム型エンジン」と機械学習による最適化により、標準 PostgreSQL より分析クエリが最大 100 倍高速とされています。高いパフォーマンスと可用性が求められるエンタープライズ向けアプリケーションに適しています。

• 向いている用途：高トラフィックな Web サービス・分析も行うトランザクション DB
• 向いていない用途：コスト最優先の小規模プロジェクト

Cloud Spanner

カテゴリ：RDB（リレーショナルデータベース） ｜ 難易度：★★★☆☆

Google が内部で検索エンジンや Gmail のバックエンドに使用している分散型 RDB です。最大 99.999%の可用性 SLA を誇り、複数リージョンにまたがって強整合性を保ちながらスケールできます。SQL が使えながら NoSQL のような水平スケーリングを実現した、業界でも珍しいサービスです。グローバル展開するアプリやミッションクリティカルなシステムに向いています。

• 向いている用途：グローバルサービス・金融・ゲームのランキングシステム
• 向いていない用途：小〜中規模（コストが高め）

Firestore（旧：Datastore）

カテゴリ：NoSQL（ドキュメント型） ｜ 難易度：★★☆☆☆

JSON ライクなドキュメント形式でデータを管理する NoSQL サービスです。Firebase SDK と統合されており、モバイルアプリや Web アプリからリアルタイムにデータを読み書きするユースケースで非常に強力です。スキーマレスなので、頻繁に仕様が変わるプロダクト開発初期にも向いています。

• 向いている用途：モバイルアプリ・リアルタイムチャット・スタートアップの初期開発
• 向いていない用途：複雑な JOIN が必要なクエリ・大規模集計処理

【コラム】Datastore と Firestore の関係

Cloud Datastore は、Firestore の前身にあたる NoSQL サービスです。Google App Engine のデータストアとして長年使われてきましたが、2019 年に Firestoreがネイティブモードで正式提供されたことで、事実上の後継サービスとなりました。現在の Firestore には 2 つの動作モードがあります。

• Native モード：新しい Firestore の機能をフル活用。リアルタイムリスナーやFirebase SDK との統合が強力。新規プロジェクトはこちらを推奨。
• Datastore モード：旧 Cloud Datastore との後方互換性を保ったモード。既存のDatastore アプリをそのまま移行できる。リアルタイムリスナーは非対応。旧来の Datastore を使っているシステムは Firestore（Datastore モード）として継続利用でき、将来的に Native モードへ移行することも可能です。これから Google Cloudで NoSQL を始めるなら、迷わず Firestore（Native モード）を選びましょう。

⑤ Memorystore

カテゴリ：インメモリ ｜ 難易度：★★☆☆☆

ValKey・Redis・Memcached に対応したフルマネージドのインメモリデータベースサービスです。データをメモリ上に保持することでミリ秒未満の超低レイテンシを実現し、セッション管理や API レスポンスのキャッシュ、リアルタイムランキングなどの用途に使われます。

• 向いている用途：キャッシュ・セッション管理・リアルタイムランキング・Pub/Sub
• 向いていない用途：永続的なデータの一次保存先（メモリ上のためサーバー再起動でデータ消失のリスクあり）

【コラム】Redis・Valkey・Memcached — どのエンジンを選ぶ？

Memorystore は複数のエンジンをサポートしていますが、2024 年に Redis のライセンスが変更されたことで状況が変わりました。Redis 社がバージョン 7.4 以降をオープンソースから商用ライセンスへ切り替えたため、Google を含むクラウドベンダーは Redis7.4 以降を採用しにくくなりました。この動きを受け、Linux Foundation と AWS・Google などが主導して Redis 7.2 からフォークした OSS プロジェクトが「Valkey」です。2025 年 4 月に Memorystore for Valkeyが GA となり、同等のコストで Redis Cluster より最大 2 倍の QPS を実現するなど、現在は Valkey への移行が推奨されています。3 つのエンジンの使い分けは次の通りです。

• Valkey：新規プロジェクトの第一選択肢。OSS ライセンス（BSD-3）・高パフォーマンス・Redis との互換性あり。
• Redis（〜7.2）：既存の Redis アプリをそのまま移行したい場合。将来的にはValkey への移行を検討。
• Memcached：シンプルなキャッシュ用途のみ。データ構造が不要なら最軽量な選択肢だが、Valkey への移行も推奨されている。

Bigtable

カテゴリ：NoSQL（ワイドカラム型） ｜ 難易度：★★★★☆

Google 検索・広告・YouTube など、10 億人規模のユーザーを支える Google 内製技術がベースの NoSQL サービスです。ペタバイト級の大量データを低レイテンシで読み書きするのが得意で、IoT センサーデータや時系列データ、ストリーミングデータ処理に特化しています。運用には専門知識が必要で、個人開発や小規模プロジェクトには向きません。

• 向いている用途：IoT・広告配信・時系列データ・大規模ログ処理
• 向いていない用途：小規模・トランザクション処理・複雑なクエリ

BigQuery

カテゴリ：DWH（データウェアハウス） ｜ 難易度：★★☆☆☆

サーバーレスのデータウェアハウスで、ペタバイト級のデータに対しても SQL で数秒〜数分の高速クエリを実行できます。インデックス設計やチューニングが不要で、データを読み込めばすぐに分析できる「魔法のような」ツールです。Looker Studio との連携でダッシュボード作成も簡単です。データ分析・BI が目的なら、まず BigQuery を検討するのが定石です。

• 向いている用途：データ分析・BI・機械学習の特徴量エンジニアリング
• 向いていない用途：トランザクション処理・リアルタイムな書き込みが多いアプリ

番外編：Cloud Storage（オブジェクトストレージ）

カテゴリ：オブジェクトストレージ ｜ 難易度：★☆☆☆☆

Cloud Storage は GCP のオブジェクトストレージサービスです。データベースサービスではありませんが、データベースと組み合わせて使うことが多いため、ここで紹介します。画像・動画・PDF・ログファイルといった「ファイルそのもの」を保管・配信するのが得意です。一言で言うと、データベースが「検索・操作できる台帳」なのに対し、Cloud Storage は「ファイルをそのまま置く棚」です。

Cloud Storage を使うべき主なパターン

① ユーザーがアップロードするファイルの保管

プロフィール画像・商品写真・添付ファイルなど。ファイル本体を Cloud Storage に置き、その URL を DB に保存するのが定番パターンです。

② 静的 Web コンテンツの配信

HTML・CSS・JavaScript・画像などを Cloud Storage に置いて CDN 経由で配信します。サーバーを立てずに済むためコストが低く、スケールも自動です。

③ ログ・バックアップの長期保存

アクセスログや DB バックアップを保管します。アクセス頻度に応じて 4 つのストレージクラスを使い分けることでコストを最適化できます。

• Standard：頻繁にアクセスするデータ
• Nearline：月 1 回程度のアクセス
• Coldline：四半期に 1 回程度
• Archive：年 1 回以下の長期保存

④ BigQuery のデータソース

CSV や Parquet、JSON ファイルを Cloud Storage に置いておき、BigQuery から直接クエリを実行できます。データパイプラインの中継地点としてよく使われます。

⑤ 機械学習の学習データ・モデル保管

大量の画像データセットや学習済みモデルファイルの保管場所として使われます。VertexAI などの GCP サービスとの連携もスムーズです。