WEB問題集
DP420-MOD#1
Azure Cosmos DB for NoSQL でコンテナーのパーティション キーを選定するとき、最も重視すべき特性として正しいものはどれですか?
解説
【正解: A】の理由
良いパーティション キーは高カーディナリティ (取り得る値の種類が多い) で、データとリクエスト (RU/s 消費) を多数の論理パーティションへ均一に分散できる必要があります。これによりストレージとスループットが特定パーティションに偏らず、ホット パーティションを避けてスケールアウトを最大化できます。
【他選択肢が違う理由】
- B: 低カーディナリティでは値の種類が少なく、少数の論理パーティションにデータが集中してホット パーティションやスケール制約を招きます。
- C: 全ドキュメントが同一値だと論理パーティションが1つになり、20 GB / 単一物理パーティションの上限に達してスケールできません。
- D: パーティション キーの値は一度設定すると変更できないため、頻繁に変化する性質はキーとして不適切です。
【参考】
DP420-MOD#2
Azure Cosmos DB for NoSQL で、単一の論理パーティションにスコープした効率的なクエリを記述します。各ドロップダウンで適切な値を選択してください。
SELECT * FROM c
WHERE c.{{BLANK1}} = "tenant-01"
AND c.status = {{BLANK2}}| ステートメント | 選択 |
|---|---|
BLANK1: 単一パーティション クエリにするため等値フィルターするパーティション キーのプロパティ パーティション キーのプロパティを等値 (=) でフィルターすると、クエリが単一論理パーティションにスコープされ RU を節約できます。 | |
BLANK2: status を文字列リテラルで等値比較する値 NoSQL の文字列リテラルは二重引用符で囲み、status = "active" のように等値比較します。 | |
パーティション キーを等値フィルターするとクロスパーティション クエリを避けられるか パーティション キーを等値で指定すると単一パーティションへルーティングされ、クロスパーティション (ファンアウト) を回避できます。 |
解説
【正解マッチング】
| 判定対象 | 正解 |
|---|---|
| BLANK1: 単一パーティション クエリにするため等値フィルターするパーティション キーのプロパティ | partitionKey |
| BLANK2: status を文字列リテラルで等値比較する値 | "active" |
| パーティション キーを等値フィルターするとクロスパーティション クエリを避けられるか | はい |
【各判定の詳細】
- 「BLANK1: 単一パーティション クエリにするため等値フィルターするパーティション キーのプロ…」→ partitionKey: パーティション キーのプロパティを等値 (=) でフィルターすると、クエリが単一論理パーティションにスコープされ RU を節約できます。
- 「BLANK2: status を文字列リテラルで等値比較する値」→ "active": NoSQL の文字列リテラルは二重引用符で囲み、status = "active" のように等値比較します。
- 「パーティション キーを等値フィルターするとクロスパーティション クエリを避けられるか」→ はい: パーティション キーを等値で指定すると単一パーティションへルーティングされ、クロスパーティション (ファンアウト) を回避できます。
【参考】
DP420-MOD#3
階層パーティション キーを設計・適用する手順を順序通りに並べてください。
- 単一キーでは 20 GB 上限を超えるテナント等の高基数パーティションを特定
- 上位レベル (例 TenantId) と下位レベル (例 UserId) を最大 3 レベルで定義
- kind を MultiHash にして階層キーを指定しコンテナーを作成
- 上位レベルでの等値フィルター クエリが対象パーティションに絞られるか検証
解説
【正しい順序】
- ステップ 1: 上限超過の特定
- ステップ 2: レベル定義
- ステップ 3: コンテナー作成
- ステップ 4: 検証
【各ステップの理由】
- ステップ 1 上限超過の特定: 単一キーで上限超過する対象を特定します。
- ステップ 2 レベル定義: 上位/下位レベルを最大 3 レベルで決めます。
- ステップ 3 コンテナー作成: MultiHash で階層キーを指定し作成します。
- ステップ 4 検証: 上位レベル フィルターの効率を確認します。
【誤った順序の問題点】
- レベル定義の前にコンテナーを作成する: 階層レベルが決まっていないと正しい paths/kind を指定できません。
- 上位レベル フィルターの検証を省略: 上位プレフィックスで絞り込めるか確認しないと、フルファンアウトが残る可能性があります。
【参考】
DP420-MOD#4
Cosmos DB for NoSQL での非正規化 (denormalization) の適用について、正しい説明を選択してください。
3 つ選択してください
解説
【正解: A / B / C】の理由
非正規化は、頻繁に読まれる項目を複製・埋め込みして JOIN や追加クエリを避け、読み取りを最適化する手法です。複製により書き込み時のコストは増えるため、コピーの整合 (変更フィード等) を併せて設計します。読み取り負荷が高いシステムで読み取り最適化のトレードオフとして用います。
【他選択肢が違う理由】
- D: 非正規化はデータを複製するためストレージは増え、重複も意図的に増やす手法です。
- E: 複製コピーは自動で強整合同期されず、変更フィード等で整合を取る必要があります。
- F: 非正規化は第 3 正規形を崩して読み取りを最適化する手法で、正規化を守るものではありません。
【参考】
DP420-MOD#5
各 RU コスト要素を説明にマッチさせてください。
項目（ドラッグしてください）
- 読み書きする項目のサイズ
- クエリの複雑さ/結果件数
- インデックス作成ポリシー
- フィルター述語の選択性
項目サイズに比例して増える要素
クエリ効率に依存する要素
書き込み時の処理に影響する要素
解説
【正しいマッチング完全版】
※ 項目サイズは読み書き RU に比例し、クエリの複雑さ/結果件数や述語の選択性はクエリ RU を左右し、インデックス作成ポリシーは書き込み時のインデックス更新コストに影響します。
- 読み書きする項目のサイズ → 項目サイズに比例して増える要素
- クエリの複雑さ/結果件数 → クエリ効率に依存する要素
- インデックス作成ポリシー → 書き込み時の処理に影響する要素
- フィルター述語の選択性 → クエリ効率に依存する要素
【正解マッチング】
| 項目 | カテゴリ |
|---|---|
| 読み書きする項目のサイズ | 項目サイズに比例して増える要素 |
| クエリの複雑さ/結果件数 | クエリ効率に依存する要素 |
| インデックス作成ポリシー | 書き込み時の処理に影響する要素 |
| フィルター述語の選択性 | クエリ効率に依存する要素 |