🆚 1. Cloud SQL Enterprise vs Enterprise Plus
| 観点 | Enterprise | Enterprise Plus |
|---|
| 最大 vCPU | 96 | 128 |
| 最大 RAM | 624 GB | 864 GB |
| Data Cache (NVMe) | なし | あり |
| Near-Zero Downtime メンテナンス | なし | あり (10秒以下) |
| ローカル SSD | なし | あり |
| 価格 | 標準 | 約 1.5-2 倍 |
判断軸
・「高性能を最大限引き出したい」「ニアゼロダウンタイムが必要」 → Enterprise Plus
・「コスト効率重視」「シングルインスタンス開発」 → Enterprise
🚀 2. AlloyDB vs Cloud SQL for PostgreSQL
Cloud SQL for PostgreSQL を選ぶ理由
- 標準的な OLTP ワークロード
- コスト効率重視
- シンプルな構成で運用したい
- MySQL / SQL Server も同じ管理画面で運用
AlloyDB を選ぶ理由
- PostgreSQL を 4倍速で動かしたい
- HTAP (OLTP + 分析) を同じ DB で
- AI/ML、ベクトル検索 (pgvector + ScaNN)
- Index Advisor で自動チューニング
- Read Pool で読み取りスケール
🌐 3. Spanner: いつ使う、いつ使わない
Spanner を選ぶ絶対条件
以下の 3 つすべてを満たすときだけ Spanner。
- グローバル分散（複数リージョンで読み書き）
- 強整合性 (ACID)
- 無制限の水平スケール（数十TB〜PB級）
Spanner ではないシナリオ
・単一リージョンの中小 OLTP → Cloud SQL / AlloyDB
・分析専用 → BigQuery
・MongoDB アプリ → Firestore
・コスト最重視で性能はそこそこ → Cloud SQL
📡 4. Bigtable のスキーマ設計が 100% を決める
行キー設計の原則
NG パターン:
行キー = sensor1_2026-05-29-12:00:00
sensor1_2026-05-29-12:00:01
→ 同一センサーの書き込みがホットスポット化
OK パターン:
行キー = 2026-05-29-12:00:00_sensor1
2026-05-29-12:00:00_sensor2
→ 異なるセンサーが並列に書き込み
ベスト (時系列 + ホットスポット回避):
行キー = sensor1_<reversed_timestamp>
sensor2_<reversed_timestamp>
→ センサー単位範囲スキャン可、ホットスポット回避
SSD vs HDD
・通常運用 + リアルタイム参照 → SSD
・バックアップ / アーカイブ → HDD（コスト 1/4）
📱 5. Firestore の 3 モード
| モード | 用途 | API | リアルタイム同期 |
|---|
| Native | 新規アプリ | Firestore SDK | あり (Web/モバイル) |
| Datastore | レガシー互換 | Datastore API | なし |
| MongoDB-compatible | MongoDB アプリ移行 | MongoDB Wire Protocol | あり |
⚡ 6. Memorystore: Redis vs Memcached vs Valkey
| エンジン | 特徴 | 推奨用途 |
|---|
| Redis | 永続化 / データ構造 (List/Set/Hash/Sorted Set) / Pub/Sub / Lua | キャッシュ + リーダーボード + Pub/Sub軽量 |
| Memcached | シンプル KV、永続化なし | 純粋なキャッシュ |
| Valkey | Redis フォーク (OSS) / Redis 互換 | 新規 OSS 戦略 |
Tier (Redis のみ)
・Basic Tier → キャッシュのみ、再起動でデータ消失
・Standard Tier → リードレプリカ付き、HA、SLA 99.9%
・Cluster Tier → Cluster モード、シャーディング、最大 14.4 TiB
🏢 7. Bare Metal Solution を選ぶ条件
- Oracle DB の RAC / Exadata / Spatial / Advanced Compression など固有機能を使用
- SAP HANA の認定構成が必要
- 物理ハードウェア + 既存ライセンス（BYOL）が必要
- マネージド DB へのリフトアンドシフトが困難
BMS の制約: マネージドではない → OS / DB のパッチ・バックアップは顧客責任。Cloud SQL や AlloyDB と異なり、PITR や自動バックアップなし。
🤖 8. AI / LLM ユースケースの DB 選定
RAG パイプラインの典型構成
[ユーザー質問]
↓
[Vertex AI Embeddings API] (質問をベクトル化)
↓
[AlloyDB + pgvector + ScaNN] (類似ベクトル検索)
↓
[Vertex AI Gemini] (コンテキスト + 質問でレスポンス生成)
↓
[ユーザーへ回答]
| 選択肢 | シナリオ |
|---|
| AlloyDB + pgvector + ScaNN | 既存 PostgreSQL + 高速 ANN |
| Cloud SQL for PostgreSQL + pgvector | 小〜中規模、コスト重視 |
| Vertex AI Vector Search | 超大規模 (>1億ベクトル) + 超低レイテンシ |
| BigQuery + ML.GENERATE_EMBEDDING | 分析統合 |
| Spanner + Vector Index | グローバル分散 + ベクトル |
🌍 9. データレジデンシーと組織ポリシー
「データは EU 域内に保管」のような法令要件への対応
1. リージョン指定で **Regional インスタンスを EU リージョン**に作成
2. **組織ポリシー** gcp.resourceLocations で他リージョンへの作成を禁止
3. Multi-region は逆に NG ─ 複数地域にデータが分散される
📊 10. 試験で迷ったらこのフレーズ
- 「グローバル + 強整合 + 99.999%」 → Spanner Multi-region
- 「PostgreSQL を 4 倍速く」 → AlloyDB
- 「IoT + >1TB + 時系列」 → Bigtable
- 「モバイル + リアルタイム同期 + オフライン対応」 → Firestore Native
- 「MongoDB 互換 + フルマネージド」 → Firestore (MongoDB-compatible)
- 「リーダーボード + Pub/Sub軽量」 → Memorystore for Redis
- 「Oracle 完全機能 + リフトアンドシフト」 → Bare Metal Solution
- 「メンテダウンタイム 10秒以下」 → Cloud SQL Enterprise Plus
- 「ベクトル検索 + RAG」 → AlloyDB + pgvector + ScaNN
- 「データレジデンシー」 → Regional + 組織ポリシー