変更要約: DP-420 第1章を新規作成（ドメイン1前半: 非リレーショナルモデリング(embed vs reference/非正規化/id・パーティションキー・一意キー/既定 TTL/バージョニング)、パーティション設計(キー選定/ホットパーティション・429/クロスパーティションコスト/データ・スループット分散/合成キー/階層パーティションキー/同一論理パーティション内トランザクション)、サイジングとスケーリング(RU/s/サーバーレス vs プロビジョニング vs Free/オートスケール/データベースレベルスループット/グローバル分散コスト)）。
1.2パーティション設計
パーティションキーの選定、ワークロード別戦略、クロスパーティションクエリのコスト、データ/スループット分散の評価、合成パーティションキーと階層パーティションキーを理解します。
Cosmos DB はデータを 論理パーティション に分けて水平スケールします。パーティションキーの選定はスケーラビリティと性能を左右する最重要設計で、いったん設定すると変更できません。
1.2.1キー選定と分散の評価
良いパーティションキーは カーディナリティが高く（値の種類が多い）、データ分散とリクエスト（スループット）分散の両方を均す。特定の値にアクセスが集中すると ホットパーティション（RU と容量の偏り）になり 429 を招く。キー選定では「どのクエリが頻繁か」「どのキーで絞り込むか」を見て、クロスパーティションクエリ（全パーティションを跨ぐ・RU コスト増・ファンアウト）を避けられる値を選ぶ。トランザクション（Transactional Batch・ストアドプロシージャ）は同一論理パーティション内に限られるため、トランザクション境界もキー選定に影響する。
1.2.2合成キーと階層パーティションキー
単一フィールドでは分散が偏る場合、合成パーティションキー（synthetic） として複数フィールドを連結（例 tenantId-date）した値や、ランダムサフィックスを付けてカーディナリティを上げる。複数のレベルで分割したいワークロード（例 テナント→ユーザー→セッション）には 階層パーティションキー（hierarchical partition key） を使い、最大 3 階層のキーで論理パーティションあたり 20GB の制限を超えてスケールしつつ、上位プレフィックスでの効率的なクエリを可能にする。「単一キーで偏る/上限に当たる」＝合成 or 階層を検討、が定石。
決め手：「データ＋スループットを均す高カーディナリティ」＝良いキー。「一値に集中」＝ホットパーティション/429。「全パーティション跨ぎ＝RU 増」＝クロスパーティションクエリ。「単一で偏る→連結/サフィックス」＝合成キー。「多レベル＋20GB 超え」＝階層パーティションキー。トランザクションは同一論理パーティション内のみ。
混同に注意：
①パーティションキーはコンテナ作成後に変更不可＝設計をやり直すには再作成/移行が要る。
②合成キー（カーディナリティ向上）と階層キー（多レベル・20GB 超え）は目的が異なる。
③クロスパーティションクエリは可能だが RU が増える＝設計で減らす。
④論理パーティションの 20GB 上限を意識する。
1.2.3この節のまとめ
- 良いキー＝高カーディナリティでデータ/スループットを均す・ホットパーティションと 429 を避ける
- クロスパーティションクエリは RU 増＝頻繁なクエリで絞れるキーを選ぶ
- 合成キー=カーディナリティ向上、階層パーティションキー=多レベル・20GB 超えのスケール
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 特定のパーティションキー値にアクセスが集中し RU が偏って 429 が頻発している。最も適切な対処はどれですか？
Q2. 単一フィールドではカーディナリティが低く偏る。分散を改善する手法はどれですか？
Q3. マルチテナントで「テナント→ユーザー→セッション」の階層で分割し、論理パーティション 20GB を超えてスケールしたい。最適なのはどれですか？
Q4. クロスパーティションクエリについて正しいのはどれですか？
Q5. Cosmos DB のトランザクション（Transactional Batch やストアドプロシージャ）が動作する範囲として正しいのはどれですか？