変更要約: DP-420 第2章を新規作成（ドメイン1後半: SDK クライアント接続(gateway vs direct/シングルトン/エミュレーター/優先リージョン/429・一時エラーのリトライ)、SQL クエリとデータアクセス(配列・ネスト・集計・サブクエリ・関数/ポイント操作 vs クエリ/パッチ/Transactional Batch/Bulk/ETag 楽観的同時実行/一貫性上書き・セッショントークン/ページネーション・継続トークン/クエリメトリクス)、サーバーサイド JS(ストアドプロシージャ=論理パーティション内 ACID/プリ・ポストトリガー/UDF)）。
2.2SQL クエリとデータアクセス
Cosmos DB for NoSQL の SQL クエリ（配列/ネスト/集計/サブクエリ/関数）、ポイント操作 vs クエリ、パッチ、Transactional Batch、Bulk、ETag による楽観的同時実行、一貫性上書き、ページネーション/継続トークン、429 ハンドリング、クエリメトリクスを理解します。
データアクセスには「id＋パーティションキーで 1 件取る ポイント操作」と「条件で複数件を取る クエリ操作」があり、RU コストと使い分けが重要です。
2.2.1ポイント操作・クエリ・パッチ
ポイント操作（id＋パーティションキー指定の read/create/replace/upsert/delete）は最も安く速い＝単一項目が分かっているなら必ずこれを使う。クエリ操作 は SQL（配列/ネストオブジェクト/集計/並べ替え/相関サブクエリ/型チェック・数学・文字列・日付関数）で複数件を扱うが RU はクエリ次第で増える。項目の一部だけ更新するなら パッチ操作（partial update） で全体差し替えを避け効率化する。
2.2.2Transactional Batch・Bulk・ETag・継続トークン
Transactional Batch は 同一論理パーティション内の複数項目をアトミックに（全成功か全失敗）処理する。Bulk Support は大量項目を並列に高スループットで投入する（アトミックではない・一括ロード向け）。ETag と If-Match による楽観的同時実行制御 で、読み取り時の ETag と一致する場合だけ更新し競合上書きを防ぐ（不一致なら 412）。一貫性はクエリ要求オプションで（強い側へは不可・弱い側へ）上書きでき、セッショントークンでセッション一貫性を引き継ぐ。大きな結果は ページネーション＋継続トークン（continuation token） で次ページを取得する。クエリメトリクスで RU や実行内訳を診断する。
決め手：「単一項目を id＋パーティションキーで」＝ポイント操作(最安)。「同一論理パーティションのアトミック複数」＝Transactional Batch。「大量を高速一括投入(非アトミック)」＝Bulk。「競合上書き防止」＝ETag/If-Match(不一致412)。「次ページ」＝継続トークン。「一部更新」＝パッチ。
混同に注意：
①Transactional Batch（アトミック・同一論理パーティション）と Bulk（高スループット・非アトミック）を取り違えない。
②クエリで済むところをクロスパーティションにすると RU 増。
③ETag 不一致は 412＝再読込してリトライ。
④一貫性はクエリで弱める方向のみ上書き可（強める方向は不可）。
2.2.3この節のまとめ
- 単一項目はポイント操作(最安)、複数条件はクエリ、一部更新はパッチ
- Transactional Batch=同一論理パーティションのアトミック、Bulk=非アトミックの一括高速投入
- ETag/If-Match で楽観的同時実行(不一致412)、継続トークンでページネーション
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. id とパーティションキーが分かっている単一項目を最も低い RU で取得したい。最適なのはどれですか？
Q2. 同一論理パーティション内の複数項目を、全部成功か全部失敗のアトミックに更新したい。最適なのはどれですか？
Q3. 数百万件のデータを高スループットで一括投入したい（アトミック性は不要）。最適なのはどれですか？
Q4. 複数ユーザーの同時更新で、読み取り時から変更されていない場合だけ書き込んで競合上書きを防ぎたい。最適なのはどれですか？
Q5. 大きなクエリ結果を複数ページに分けて、次のページを効率的に取得したい。最適なのはどれですか？