1. Bigtable を選ぶシグナル
次のうち
2 つ以上該当すれば Bigtable が最適解の可能性大。
- データ量 > 1 TB
- 書き込み or 読み取り QPS > 10,000
- 時系列・IoT・センサー
- 低レイテンシ（数ミリ秒）要件
- キーバリュー or ワイドカラム的アクセスパターン
- HBase 互換 API が必要（Hadoop エコシステム）
Bigtable NG なシナリオ:
- JOIN や複雑な SQL クエリ → Cloud SQL / Spanner / BigQuery
- ACID トランザクション → Spanner
- 小規模データ（< 100GB） → コスト割高、Firestore か Cloud SQL
2. Instance / Cluster / Node / Tablet
┌─────────────────────────────────────────────────────────┐
│ Bigtable Instance │
│ ├─ Cluster A (us-central1-a) │
│ │ ├─ Node 1, 2, 3 ... N (各 ≒ 10,000 QPS) │
│ │ └─ Tablets (実データ。行キー範囲で分割) │
│ ├─ Cluster B (us-east1-b) (replication ターゲット) │
│ └─ Cluster C (asia-northeast1-a) │
│ │
│ ┌─ App Profile (ルーティング設定) │
│ │ default-profile: multi-cluster routing │
│ │ batch-profile: single-cluster routing (cluster-A) │
│ └────────────────────────────────────────────────────────│
└─────────────────────────────────────────────────────────┘
Instance の最大構成: 最大 8 リージョン、各リージョンに 1 クラスタ/ゾーン（つまり最大 8 リージョン × 3 ゾーン = 24 クラスタ）。
Node 性能: 1 ノード ≒ 10,000 QPS（SSD, KV アクセス）。実際は行サイズや並列度で変動。
Tablet の動作
Bigtable はテーブルを 行キーの範囲（ロウ範囲）で Tablet に自動分割する。Tablet は 1 つの Node が責任を持ち、サイズ拡大や負荷集中で自動的に分割・再配置される。
3. レプリケーションと App Profile
マルチクラスタ構成では、Bigtable は 非同期で各クラスタにデータを伝播する。これはマスターレス設計で、どのクラスタも書き込みを受け付ける。
レプリケーション遅延（公式）:「If your instance is responsive, the latency for replication is typically a few seconds or minutes.」
→ 通常は数秒、遅くても数分。完全な同期は保証されない。
Routing Policy
| Policy | 動作 | 整合性 | SLA | 用途 |
|---|
| Single-cluster routing |
1 クラスタ固定 |
read-your-writes |
99.9% |
バッチ処理、整合性必須 |
| Multi-cluster routing |
最寄り/任意のクラスタ |
eventual |
99.999% |
HA + 低レイテンシ |
| Cluster group routing |
指定グループ内で振り分け |
eventual |
99.999% |
地域別ターゲット |
| Row-affinity routing |
行キーハッシュで分散 |
特定行は同 cluster へ |
99.999% |
read-after-write を保ちつつ HA |
App Profile の使い分け: アプリ毎に App Profile を分けると、同じ Bigtable インスタンスで「分析バッチは single-cluster routing、リアルタイム配信は multi-cluster routing」のような ワークロード分離が可能。
4. 整合性モデル
マルチクラスタ ルーティング = eventual consistency。書いた直後に別クラスタから読むと「まだ古いデータが返る」可能性。
例: ユーザーが東京クラスタに書き込み → 直後に台湾クラスタから読み取り → 数秒間は反映されない。
Write Conflict Resolution
異なるクラスタに同じセル（4-tuple: row key, column family, column qualifier, timestamp）への書き込みが衝突した場合、Bigtable は "Last Write Wins"（サーバー時刻ベース）で自動解決する。
5. 行キー設計 — Bigtable の生命線
Bigtable の性能は 行キーの設計で 90% 決まる。テーブルにはインデックスが 行キーしかないため、行キー = 唯一のクエリパス。
5-1. ホットスポット問題
時系列センサーデータ (悪い例)
行キー = "sensor1_2026-05-30T10:00:00.000"
"sensor1_2026-05-30T10:00:00.001"
"sensor1_2026-05-30T10:00:00.002"
...
→ 同センサーの書き込みが順次同じ Tablet に集中
→ 1 Node に負荷集中 → 性能劣化 (ホットスポット)
対策1: タイムスタンプ反転 (Reverse Timestamp)
行キー = "sensor1_" + (LONG_MAX - ts)
→ 新しい書き込みは行範囲の "頭" 寄り
→ 直近データ取得時はスキャンも自然な順序
対策2: ハッシュプレフィックス (Salting)
行キー = hash(sensor_id) % 16 + "#" + sensor_id + "_" + ts
→ 16 個の Tablet に均等分散
→ ただしセンサー単位の範囲スキャンが分散され遅くなるトレードオフ
5-2. クエリパターンと行キー設計
| クエリ | 推奨行キー |
|---|
| 「センサー X の直近 1 時間」 | sensor_X#reverse_ts |
| 「全センサー、特定時刻のスナップショット」 | ts#sensor_id |
| 「ユーザー Y のアクション履歴」 | user_Y#reverse_ts |
| 「直近 1 時間の全アクション」 | ※ 苦手。BigQuery の方が向く |
SQL の感覚で複数インデックスを期待しない。Bigtable はセカンダリインデックス非対応。複数のクエリパターンが必要なら同じデータを別の行キーで 2 テーブルに保持（denormalization）するのが正解。
6. 列ファミリと列修飾子
Bigtable のセルアドレス = (Row Key, Column Family, Column Qualifier, Timestamp)
Row Key: "sensor1#reverse_ts"
├── Column Family: "telemetry"
│ ├── temperature: 22.3
│ ├── humidity: 65
│ └── pressure: 1013
└── Column Family: "metadata"
├── location: "Tokyo"
└── model: "v2"
列ファミリ数の制限: 通常 最大 100 個を超えないこと。多すぎると性能劣化。
列修飾子: 1 セルあたり最大 100MB（推奨 < 10MB）。1 行全体で最大 256MB（推奨 < 100MB）。
列ファミリの設計指針
- 同時にアクセスする列を同じファミリに（I/O 効率化）
- 異なる TTL や GC ポリシーを設定したい列は別ファミリに
- 列ファミリ毎にストレージ最適化（圧縮、ブロックサイズ）が異なる
7. SSD vs HDD と料金
| 項目 | SSD | HDD |
|---|
| レイテンシ | 数ミリ秒 | 数十〜数百ミリ秒 |
| QPS / Node | ~ 10,000 (read+write) | ~ 500 (read), ~ 10,000 (write) |
| 料金 | 標準 | 約 1/4 |
| 容量上限 | 16 TB / Node | 64 TB / Node |
| 用途 | 本番、低レイテンシ参照 | バックアップ、アーカイブ、低頻度アクセス |
SSD/HDD は後から変更不可。クラスタ作成時に決定する必要があり、変更したい場合は新クラスタを作って レプリケーションで移行する必要がある。
8. Key Visualizer でホットスポット検出
Key Visualizer は 行キー範囲（Y軸） × 時間（X軸） のヒートマップ。色の明るさが負荷を示す。
ホットスポットの典型パターン
Y軸 = 行キー範囲 |
X軸 = 時間 → ↓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓ ← 末尾行に書き込み集中
→ 連番主キーの典型症状
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
対策: タイムスタンプ反転 or ハッシュプレフィックスで分散
Key Visualizer の制約:
- 最小テーブルサイズ: 1 GB / クラスタ 以上で利用可
- 新規テーブル: データ蓄積に数日〜1週間
- データ保持: 14 日
- 表示間隔: 15 分 単位
9. 落とし穴と試験頻出
セカンダリインデックスがない:
SQL の感覚で「created_at にインデックス追加」はできない。クエリパターンを先に決め、それを行キーとして設計する。
クラスタ数とノード数の上限:
クォータ上、デフォルトでは 1 インスタンスあたり ~30 ノード。大規模ならクォータ申請が必要。
マルチクラスタ ルーティング = 必ず eventual consistency。「Multi-cluster routing で強整合」を選ぶと不正解。強整合が必要なら Single-cluster routing または Row-affinity routing。
試験頻出のひっかけ
| 問題文 | NG 回答 | 正解 |
|---|
| センサー時系列、高 QPS、低レイテンシ |
Firestore |
Bigtable + reverse_ts |
| マルチリージョン分散 + 強整合 |
Bigtable Multi-cluster |
Spanner Multi-region |
| Bigtable で複雑な範囲クエリ |
セカンダリインデックス追加 |
別の行キーで 2 テーブル + 同期書き込み |
| ホットスポット解消 |
ノード追加 |
行キー再設計 |