03_要点と暗記

セクション3 要点と暗記：データの保存 🎯

試験直前の総ざらい用。暗記すべき表と一問一答でセクション3を固めます。 このセクションはストレージ選定が最頻出。下の早見表を白紙から再現できれば合格ラインです。

🔑 暗記必須テーブル

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

要件・キーワード 選ぶサービス
非構造化・画像/動画/ログ・バックアップ・データレイク Cloud Storage
大規模分析・BI・アドホックSQL・PB級集計 BigQuery
一般的なRDB・Webアプリ・MySQL/PostgreSQL/SQL Server・リージョナル Cloud SQL
PostgreSQL互換で高性能・トランザクション＋分析(HTAP) AlloyDB
グローバル分散・水平スケール・強整合・無停止(99.999%) Spanner
時系列/IoT・ミリ秒応答・毎秒大量書き込み・キー参照・PB級 Bigtable
モバイル/Web・リアルタイム同期・ドキュメント Firestore
キャッシュ・セッション・サブミリ秒（正本ではない） Memorystore
レイク(GCS/他クラウド)をBQから細粒度統制して分析 BigLake

② 整合性・ワークロード別の早見

軸 強整合(ACID) 結果整合/高スループット
グローバル分散RDB Spanner —
リージョナルRDB Cloud SQL / AlloyDB —
ドキュメント Firestore —
ワイドカラム/大量低レイテンシ （単一行のみ強整合） Bigtable

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

クラス アクセス頻度 最低保存期間 一言
Standard 頻繁 なし ホット・配信
Nearline 月1回 30日 たまに参照・バックアップ
Coldline 四半期1回 90日 アーカイブ
Archive 年1回未満 365日 長期保管・コンプライアンス

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

④ BigQuery 設計の要点

観点 ベストプラクティス
データモデル 非正規化＋ネスト/繰り返し（STRUCT/ARRAY）でJOIN削減
スキャン量削減 パーティション（日付等）＋クラスタリング（よく絞る列）
クエリコスト 必要な列のみSELECT（SELECT *回避）・パーティションプルーニング
計算単位 スロット。散発→オンデマンド／大量予測可能→Editions/予約

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

DB 手法 ポイント
Bigtable フィールドプロモーション / ソルティング 高カーディナリティな識別子を行キー先頭に、時刻は後置。SSD/HDD選択。作成後タイプ変更不可
Spanner ハッシュ化主キー / キー分散 単調増加キーを避ける。親子はインターリーブ。TrueTimeで強整合

⑥ レイク / プラットフォーム / ガバナンス

用語 役割
データレイク（GCS） 生データをそのまま貯める（スキーマオンリード）
データウェアハウス（BigQuery） 整形・統合済み分析データ（スキーマオンライト）
BigLake レイク上のデータをBQから細粒度アクセス制御で分析
Dataplex 分散データを論理レイク/ゾーンに束ね横断ガバナンス
Dataplex Catalog メタデータカタログ（検索・発見・タグ・系統）
データメッシュ ドメイン主体の分散所有＋フェデレーテッドガバナンス

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

Q1. グローバル規模で水平スケールしつつ、強整合のACIDトランザクションが必要なRDBは？

A. Cloud Spanner（TrueTimeでグローバル外部一貫性を実現）

Q2. 車両IoTから毎秒数百万件の書き込み、ミリ秒で直近値を読みたい。結果整合性で良い。最適なストレージは？

A. Bigtable（ワイドカラムNoSQL・低レイテンシ・高スループット）

Q3. PostgreSQL互換のまま高性能で、トランザクションと分析クエリの両方を同じDBで速く処理したい。選ぶのは？

A. AlloyDB（PostgreSQL互換のHTAP寄り。MySQL/SQL Serverなら Cloud SQL）

Q4. めったに読まないが法令で7年保持が必要な書類画像。最もコストが低い保存方法は？

A. Cloud Storage の Archive クラス（必要ならライフサイクルでStandard→Archive、保持後に削除）

Q5. BigQueryでクエリコストを下げたい。基本的な3つの打ち手は？

A. ①日付等でパーティション ②よく絞る列でクラスタリング ③必要な列だけSELECT（SELECT *回避）。いずれも「スキャン量削減」が狙い。

Q6. BigQueryで注文と注文明細を扱う。RDB流に正規化してJOINを多用すべき？

A. いいえ。非正規化し、明細はネスト/繰り返しフィールド（ARRAY）で1行に畳み込むのがBigQuery流（JOIN削減）。

Q7. Bigtableで行キーの先頭にタイムスタンプを置いたら書き込みが遅い。原因と対策は？

A. 最新書き込みが単一ノードに集中するホットスポット。対策はフィールドプロモーション（高カーディナリティな識別子を先頭に昇格しタイムスタンプは後置）やソルティングで分散。

Q8. Spannerで主キーに単調増加するシーケンスを使ったら性能が出ない。なぜ？どうする？

A. キーが特定スプリットに集中しホットスポット化するため。UUID/ハッシュ化主キーやキー先頭のハッシュ化で均等分散する。親子テーブルはインターリーブでローカリティ向上。

Q9. モバイルアプリでオフライン対応とリアルタイム同期が必要なドキュメント型DBは？

A. Firestore

Q10. GCS上のParquetデータをコピーせず、BigQueryから列/行レベルのアクセス制御付きで分析したい。使うのは？

A. BigLake（BigLakeテーブルで細粒度のガバナンスを付与）

Q11. 散らばったGCS/BigQueryを論理的なレイク・ゾーンに束ね、横断で品質・セキュリティ・発見性を管理したい。サービスは？

A. Dataplex（メタデータの検索・発見は Dataplex Catalog）

Q12. 各部門がデータを「プロダクト」として所有しつつ、全社共通のルールで統制するモデルは？

A. データメッシュ（フェデレーテッドガバナンス）。GCPでは Dataplex＋Catalog で横串、Analytics Hubで共有。

Q13. Webアプリのバックエンドで、リージョナルなMySQLのマネージドDBが欲しい。グローバル分散は不要。選ぶのは？

A. Cloud SQL（グローバル強整合・無停止スケールが要るなら Spanner）

Q14. データベースの前段に置いて、頻繁な読み取りをサブミリ秒で返すキャッシュ層が欲しい。使うのは？

A. Memorystore（Redis/Memcached）。永続的な正本ではなくキャッシュとして使う点に注意。

🎯 ひっかけ注意ポイント

📝 セルフチェック