セクション3 応用：データの保存 🔧🎯

このファイルは 🔧 実践（中堅） と 🎯 発展（シニア） レベル。 「どのストレージを選ぶか」「設計のベストプラクティス」「トレードオフ」「試験のひっかけ」に焦点を当てます。基礎概念は 01_基礎.md を参照。

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

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

Q1. データは構造化されているか？
  │
  ├─ NO（画像・動画・ログ・バックアップ等の非構造化/ファイル）
  │     └─►【Cloud Storage】（必要ならBigLakeでBQから分析）
  │
  └─ YES（構造化/半構造化）
        │
        Q2. ワークロードは？
        │
        ├─ 分析・集計が中心（OLAP）
        │     └─►【BigQuery】（レイク上のまま分析したい → BigLake）
        │
        └─ トランザクション・更新が中心（OLTP）
              │
              Q3. データモデルは？
              │
              ├─ ドキュメント指向 + モバイル/Webのリアルタイム同期
              │     └─►【Firestore】
              │
              ├─ ワイドカラム / キー参照で大量・低レイテンシ・高スループット
              │     └─►【Bigtable】（時系列・IoT・ミリ秒応答・PB級）
              │
              └─ リレーショナル（SQL・ACID）
                    │
                    Q4. グローバル分散 + 水平スケール + 強整合が必要？
                    │
                    ├─ YES（グローバル無停止・大規模）
                    │     └─►【Spanner】
                    │
                    └─ NO（リージョナルで十分）
                          │
                          Q5. PostgreSQLで高性能 or 分析も同じDBで（HTAP）？
                          ├─ YES →【AlloyDB】
                          └─ NO  →【Cloud SQL】（MySQL/PostgreSQL/SQL Server）

  ※ 超低レイテンシのキャッシュが欲しい → 上記の前段に【Memorystore】

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

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

• 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 ライフサイクル管理（Object Lifecycle Management）

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

ライフサイクルルールの例：
  作成から 30日経過 → Nearline へ移行
  作成から 90日経過 → Coldline へ移行
  作成から365日経過 → Archive へ移行
  作成から  7年経過 → 削除（保持義務終了後）

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

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

⚠️ 「分析クエリが遅い」と言われてBigtableを足すのは誤り。分析はBigQueryへ。Bigtableはキー参照のための低レイテンシストア。

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 *回避、パーティション/クラスタ見直し。

🎯 スロットとコスト（詳細はセクション5）

• 散発的・予測困難なクエリ → オンデマンド（使った分だけ）。
• 大量・予測可能・コスト平準化 → Editions/スロット予約（定額）。

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

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

🔧 行キー設計の原則

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

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

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

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

悪い: 20260528T1200#sensorA   ← 先頭が時刻 → 最新が1ノード集中（ホット）
良い: sensorA#20260528T1200   ← 先頭がセンサーID → 書き込みが分散
         └ フィールドプロモーション（IDを先頭に昇格）＋ 時系列は後置

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

🔧 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で安全に共有。
• ⚠️ 「中央チームが全データを抱える」設計はスケールしない → 分散所有＋フェデレーテッドガバナンスが現代的な解答。

🎯 トレードオフ早見

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

シナリオ：グローバル展開するライドシェア企業。 ① 世界中の決済・配車トランザクションは強整合で、無停止・水平スケールが必須。 ② 車両から毎秒数百万件のGPSテレメトリが届き、ミリ秒で直近位置を引きたい。 ③ 過去全データをアドホックにSQL分析してBIダッシュボードを出したい。 ④ ドライバーがアップロードする本人確認書類の画像を保管（数年は保持、めったに参照しない）。 ⑤ 取り込み生データはレイクにそのまま貯め、部門ごとに所有しつつ全社で統制・発見可能にしたい。

設計の骨子（解答例）

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。

この「要件を軸でふるい分け、各サービスへ割り当てる」思考が本番のストレージ設計問題そのものです。

まとめ：このセクションの設計判断の型

• まず意思決定ツリーでストレージを一意に絞る（構造化度→OLAP/OLTP→モデル→分散/整合性）
• BigQueryは非正規化＋ネスト、コストはパーティション＋クラスタリング＋必要列のみ
• Bigtableは行キー設計が命（フィールドプロモーション/ソルティングでホットスポット回避、SSD/HDD）
• SpannerはTrueTime・インターリーブ・キー分散でグローバル強整合
• レイク/プラットフォームは GCS＋BigLake＋Dataplex/Catalog、考え方はデータメッシュ＋フェデレーテッドガバナンス

→ 03_要点と暗記.md で記憶を固めましょう。