セクション3：データの保存

3.1 ストレージ選定の意思決定ツリー【最重要】 🔧

この試験で最も得点に直結するのがストレージ選定です。次のツリーを丸暗記してください。

サービス特徴比較表（選定の早見）

🎯 選定でよく問われる対比 🎯

• Cloud SQL vs Spanner：リージョナルで足りる→Cloud SQL／グローバル強整合・無停止スケール→Spanner。「グローバル」「水平スケール」「99.999%」が出たらSpanner。
• Bigtable vs BigQuery：ミリ秒のキー参照・大量書き込み→Bigtable／アドホックなSQL分析→BigQuery。同じ「大規模」でも用途が逆。
• Bigtable vs Cloud SQL/Spanner：ACIDの複数行トランザクションが要る→RDB／単純キーで超高スループット→Bigtable。
• Firestore vs Bigtable：ドキュメント＋モバイル同期→Firestore／時系列・ワイドカラム→Bigtable。
• Memorystore は正本にしない：永続データの保管先ではなく、前段のキャッシュ。

3.1（続き）コストとパフォーマンス・ライフサイクル管理

🔧 GCS ライフサイクル管理

オブジェクトの年齢や条件に応じて自動でクラス移行・削除するルール。コスト最適化の定番。

• ⚠️ クラスには最低保存期間があり、早期削除/移行には早期削除料金が発生（Nearline 30日 / Coldline 90日 / Archive 365日）。「30日で大量に上書きするデータをNearlineに」はアンチパターン。
• Autoclass：アクセスパターンを自動学習してクラスを自動最適化。手動ルール設計を避けたい場合に有効。

🎯 アクセスパターン分析からの選定

3.2 BigQuery設計のベストプラクティス 🔧🎯

🔧 非正規化とネスト/繰り返しフィールド

• JOINを減らすためにネスト（STRUCT）・繰り返し（ARRAY）で1行に畳み込む。
• 巨大ファクト×小ディメンションは、ディメンションをネストして埋め込むか、小さければJOINでも可。
• ⚠️ 「正規化してJOINを増やせば速くなる」はRDBの発想。BigQueryでは逆効果のことが多い。

🔧 パーティション＋クラスタリングの設計指針

• コスト削減の本丸＝スキャン量削減：パーティションプルーニング＋クラスタリング＋必要列のみSELECT。
• ⚠️ パーティションの粒度が細かすぎるとパーティション数上限や小さすぎる断片で非効率。日次が基本、超大量なら時間単位も。
• ⚠️ クエリでパーティション列に関数をかけるとプルーニングが効かないことがある（例：DATE(timestamp_col) でフィルタする設計に注意）。

🎯 マテリアライズドビュー / BI Engine（詳細はセクション4）

• 繰り返す重い集計はマテリアライズドビューで事前計算（自動リフレッシュ）。
• BIダッシュボードの低レイテンシ化は BI Engine（インメモリ）。
• ⚠️ 「BIが遅い」→ まずマテビュー/BI Engine、SELECT *回避、パーティション/クラスタ見直し。

3.1（深掘り）Bigtable設計のベストプラクティス 🔧🎯

Bigtableは行キーで1次元にソートされて分散格納される。性能の良し悪しは行キー設計でほぼ決まる。

🔧 行キー設計の原則

• 読み取りパターンに合わせて設計する（よく一緒に読む行を近くに並べる）。
• 連続スキャン（範囲読み取り）したい単位でプレフィックスを揃える。
• 書き込みを多数のノードに分散させ、ホットスポット（一部ノードへの集中）を避ける。

⚠️ アンチパターン：ホットスポット

🎯 フィールドプロモーション（Field Promotion）

時系列のホットスポットを避ける定番手法。高カーディナリティな識別子を行キーの先頭に「昇格」させ、その後ろにタイムスタンプを置く。

• 識別子が少数で偏る場合はソルティング（ハッシュ接頭辞）で更に分散。
• ⚠️ ただし分散しすぎると範囲スキャンが非効率になるトレードオフ。読み取り単位とのバランスを取る。

🔧 SSD vs HDD・サイジング

• スループットが足りなければノード追加でほぼ線形にスケール（CPU使用率を指標に）。
• ⚠️ ストレージタイプ（SSD/HDD）はインスタンス作成後に変更不可。

3.1（深掘り）Spanner設計のベストプラクティス 🎯

🎯 TrueTime と強整合

• TrueTime＝GPSと原子時計で各ノードの時刻誤差を有界化する仕組み。これによりグローバルに外部一貫性（強整合）を実現。
• 「世界中で強整合なトランザクション」が出たら Spanner一択。

🎯 インターリーブ（Interleaving）

親テーブルの行に、関連する子テーブルの行を物理的に隣接配置する機能。

• 親子を一緒に読む（例：顧客と注文）クエリのJOINを高速化し、ローカリティを高める。
• ⚠️ Bigtableの「フィールドプロモーション」とは別概念。Spannerはインターリーブで覚える。

⚠️ Spannerのホットスポット回避

• 単調増加する主キー（連番・タイムスタンプ）は避ける（特定スプリットに集中）。
• 対策：UUID/ハッシュ化主キー、またはキーの先頭バイトをハッシュして分散（ビット反転連番など）。
• 設計の合言葉は「キーを均等に分散させる」。RDBでありながらBigtable同様にホットスポットを意識する点が頻出。

3.3 / 3.4 レイク・プラットフォームの設計判断 🔧🎯

🔧 BigLake の使いどころ

• GCSや他クラウドのオブジェクトをコピーせず、BigQueryのSQL・行/列レベルのアクセス制御で統制したい。
• オープンフォーマット（Parquet/Iceberg）でロックイン回避＋細粒度ガバナンスを両立。
• ⚠️ 「外部テーブル」だけでは細粒度のセキュリティが弱い → BigLakeテーブルにすると列/行レベル制御が可能。

🔧 Dataplex によるレイク管理

• 物理的に散らばったGCS/BigQueryを論理レイク／ゾーンに整理し、横断で品質・セキュリティ・発見性を適用。
• Dataplex Catalogでメタデータを集約し、ディスカバリと系統（lineage）を提供 → データスワンプ化を防止。

🎯 データメッシュ × フェデレーテッドガバナンス

• 各ドメイン（部門）がデータプロダクトを所有（自律・スケール）。
• 一方で共通ルール（命名・品質・セキュリティ・相互運用）を全体に強制（統制）。
• GCPでの実装：ドメインごとのプロジェクト/データセット＋Dataplexで横串ガバナンス＋Analytics Hubで安全に共有。
• ⚠️ 「中央チームが全データを抱える」設計はスケールしない → 分散所有＋フェデレーテッドガバナンスが現代的な解答。

🎯 トレードオフ早見

🎯 統合シナリオ演習（考え方の練習）

設計の骨子（解答例）

1. グローバル強整合トランザクション → Spanner（TrueTime）。主キーはハッシュ化してホットスポット回避、顧客×注文はインターリーブ。
2. 大量GPSテレメトリ・ミリ秒参照 → Bigtable（SSD）。行キーは vehicleID#reversed_timestamp 等のフィールドプロモーションで書き込み分散。
3. アドホック分析・BI → BigQuery。日付パーティション＋vehicleIDクラスタリング、非正規化＋ネスト構造。BIはBI Engine/マテビューで高速化。
4. 本人確認画像（コールド長期保管）→ Cloud Storage。ライフサイクルで Standard→Coldline/Archive、保持期間後に削除。
5. 生データレイク（GCS）を BigLake でBQから細粒度統制しつつ分析、Dataplex/Catalogで論理ゾーン化・発見性確保、部門所有はデータメッシュ＋フェデレーテッドガバナンス、共有はAnalytics Hub。

🔑 暗記必須テーブル

① ストレージ選定 早見表【最優先・丸暗記】

② Cloud Storage クラスとライフサイクル

保存料：Standard > … > Archive（Archiveが最安）／取り出し料：逆（Archiveが最高）。早期削除には早期削除料金。自動最適化は Autoclass。

③ Bigtable / Spanner のホットスポット対策

✅ 一問一答（確認テスト）

🎯 ひっかけ注意ポイント

📝 セルフチェック

• ストレージ選定早見表を白紙から再現できる
• 意思決定ツリー（構造化度→OLAP/OLTP→モデル→分散/整合性）を説明できる
• Bigtableのホットスポット対策（フィールドプロモーション/ソルティング）を図で描ける
• BigQueryのコスト削減3点（パーティション/クラスタリング/必要列のみ）を即答できる
• GCSの4クラスと最低保存期間を言える
• 問題集セクション3 で80%以上取れた