変更要約: Professional Cloud Developer 第2章を新規作成（ドメイン1「設計」後半: データの保存とアクセス＝Cloud SQL/AlloyDB/Spanner/Firestore/Bigtable/Cloud Storage/BigQuery・スキーマ/行キー・結果/強整合性・署名付き URL・BigQuery 書き込み、可用性/レジリエンス/コスト＝リージョン/ゾーン分散とレイテンシ・ゾーン/リージョンフェイルオーバー・リソース要件・サーバーレスのゼロスケール・冪等性/指数バックオフ）。
2.1データの保存とアクセス
データ量と性能・整合性要件に応じたストレージの選択（AlloyDB・Spanner・Bigtable・Firestore・Cloud SQL・Cloud Storage・BigQuery）、構造化/非構造化のスキーマ設計、結果整合性と強整合性の違い、Cloud Storage の署名付き URL、そして分析・AI/ML 向けの BigQuery への書き込みを理解します。
アプリの心臓部はデータです。開発者は、データの形・量・整合性・アクセスパターンに合った保存先を選び、安全にアクセスします。
2.1.1ストレージの選択とスキーマ
構造化 RDB は、一般的な業務に Cloud SQL、高性能 PostgreSQL 互換に AlloyDB、グローバル強整合に Spanner。半構造化/ドキュメントは Firestore、超大量・低遅延の時系列/IoT は Bigtable。非構造化オブジェクトは Cloud Storage、大規模分析は BigQuery。スキーマは、RDB なら正規化とインデックス、Bigtable なら 行キー設計（ホットスポット回避）が要です。「グローバル強整合＝Spanner」「超大量・低遅延＝Bigtable」「分析＝BigQuery」と結びます。
2.1.2整合性とアクセス
レプリケーションには 結果整合性（速いが一時的に古い値が見える）と 強整合性（常に最新だがコスト高）があり、要件で選びます（Spanner は強整合、Bigtable は単一行で強整合など特性が異なる）。Cloud Storage のオブジェクトへ一時的・限定的にアクセスさせるには 署名付き URL を発行します（公開せずに期限付きで共有）。分析や AI/ML 向けにはデータを BigQuery へ書き込みます。「期限付き限定アクセス＝署名付き URL」「整合性は要件で選ぶ」を押さえます。
「要件 → サービス」が頻出。例：「グローバルで強整合の RDB」＝Spanner、「超大量・低遅延の時系列」＝Bigtable（行キー設計）、「ドキュメント型」＝Firestore、「分析」＝BigQuery、「オブジェクトに期限付きアクセス」＝署名付き URL、「高性能 PostgreSQL 互換」＝AlloyDB。
混同に注意：
①Spanner（強整合 RDB）/Bigtable（低遅延 NoSQL）/BigQuery（分析）を取り違えない。
②署名付き URL は期限付き＝バケット公開とは別。
③結果整合性は一時的に古い値が見え得る（要件で選ぶ）。
2.1.3この節のまとめ
- ストレージはデータの形/量/整合性で選ぶ（Cloud SQL/AlloyDB/Spanner/Firestore/Bigtable/Cloud Storage/BigQuery）
- 整合性＝結果整合性/強整合性を要件で選ぶ。Bigtable は行キー設計が要
- オブジェクトへの期限付きアクセスは署名付き URL、分析/ML は BigQuery へ書き込み
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. グローバルに分散しつつ強整合のリレーショナル DB が必要です。最適なのはどれですか？
Q2. 超大量・低遅延の時系列/IoT データを扱いたい。最適なのはどれですか？（行キー設計が要）
Q3. 公開せずに、Cloud Storage のオブジェクトへ期限付きで限定アクセスさせたい。使うのはどれですか？
Q4. ドキュメント型データをモバイル/Web アプリでスケーラブルに扱いたい。最適なのはどれですか？
Q5. 結果整合性と強整合性の違いとして正しいものはどれですか？
Q6. 分析や AI/ML のためにデータを書き込む先として最適なのはどれですか？