変更要約: DP-420 第4章を新規作成（ドメイン4: クエリ最適化とインデックス(インデックスポリシー included/excluded path・書き込み多 vs 読み取り多・複合インデックス・range/spatial・統合キャッシュ integrated cache 専用ゲートウェイ・RU コスト request charge/クエリメトリクス)、変更フィード(Azure Functions トリガー/SDK change feed processor・lease/変更フィードエスティメーター backlog/非正規化更新・参照強制・集計永続化・アーカイブ)）。
4.1クエリ最適化とインデックス
インデックス調整、クエリの RU コスト計算/取得、統合キャッシュ、読み取り多 vs 書き込み多のインデックス戦略、複合インデックス、カスタムインデックスポリシーを理解します。
Cosmos DB は既定で全プロパティをインデックスします。インデックスポリシー をワークロードに合わせて調整することが、クエリ性能と RU コストの最適化の核心です。
4.1.1インデックス戦略と複合インデックス
カスタムインデックスポリシーでは included path（インデックスする） と excluded path（除外する） を指定する。書き込み多のワークロード は不要なパスを除外してインデックス更新の RU を下げる（インデックスが少ないほど書き込みは安い）。読み取り多 はクエリの絞り込みに使うパスをインデックスする。複合インデックス（composite index） は、複数プロパティでの ORDER BY や複数フィルタを効率化する（単一インデックスでは賄えないクエリ向け）。空間データには spatial インデックス、範囲/等価には range インデックス を用途で選ぶ。
4.1.2RU コストの把握と統合キャッシュ
クエリやポイント操作の RU 消費 は応答ヘッダー（x-ms-request-charge）や クエリメトリクス で取得し、コストの高いクエリを特定して最適化する。読み取りが非常に多くデータがあまり変わらないワークロードでは Cosmos DB 統合キャッシュ（integrated cache） を使い、専用ゲートウェイ（dedicated gateway） 経由でポイント読み取りやクエリ結果をキャッシュして RU を大幅に削減する（結果整合の許容が前提）。「読み取り多で RU を下げたい」＝統合キャッシュ、「クエリのコストを知りたい」＝request charge/クエリメトリクス、が定石。
決め手：「書き込み多→インデックスを絞る(excluded path)」「読み取り多→絞り込みパスをインデックス」。「複数プロパティ ORDER BY/複数フィルタ」＝複合インデックス。「読み取り多で RU 大幅削減」＝統合キャッシュ(専用ゲートウェイ経由)。「クエリのコスト把握」＝request charge/クエリメトリクス。
混同に注意：
①統合キャッシュ（読み取り多の RU 削減・専用ゲートウェイ・結果は陳腐化しうる）とインデックス（クエリ効率）は別物。
②書き込み多でフルインデックスは書き込み RU を浪費＝excluded path で絞る。
③複合インデックスはクエリのプロパティ順/方向と一致が必要。
④インデックスポリシー変更はバックグラウンドで再構築される。
4.1.3この節のまとめ
- インデックスポリシーを調整＝書き込み多は excluded path で絞り、読み取り多は絞り込みパスをインデックス
- 複合インデックス＝複数プロパティの ORDER BY/複数フィルタを効率化
- 統合キャッシュ(専用ゲートウェイ)で読み取り多の RU を大幅削減、RU は request charge で把握
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 書き込みが非常に多く、クエリで使わないプロパティのインデックス更新コストを下げたい。最適なのはどれですか？
Q2. 複数プロパティでの ORDER BY や複数フィルタを含むクエリを効率化したい。最適なのはどれですか？
Q3. 読み取りが非常に多くデータがあまり変わらないワークロードで、RU を大幅に削減したい。最適なのはどれですか？
Q4. 特定のクエリがどれだけ RU を消費しているかを把握したい。最適なのはどれですか？
Q5. 統合キャッシュとインデックスの違いとして正しいのはどれですか？