Microsoft認定Azure Cosmos DB Developer Specialty(DP-420)WEB問題集

WEB問題集

Question#1(DP-420)

あなたは、著者(authors)、その著者が書いた本(books)、およびその本のレビュー(reviews)を含む Azure Cosmos DB for NoSQL データモデルを設計しています。

サーバー側のトランザクション・サポートを使用して、エンティティ間の参照整合性を維持する必要があります。 使用できるトランザクションの最大のスコープ(範囲)はどれですか?
ディスカッション 0

正解:D

Azure Cosmos DB において、ACID 特性(原子性、一貫性、独立性、永続性)を備えたトランザクションを実行する場合、その「範囲(スコープ)」には厳格な制限があります。

1. なぜ「D(同じ論理パーティション内のアイテム)」が正解なのか
  • Cosmos DB のトランザクション制限: Cosmos DB のストアドプロシージャ、トリガー、およびトランザクションバッチ(TransactionalBatch)は、単一の論理パーティション内にあるアイテムに対してのみ動作します。
  • 物理的な理由: トランザクションを保証するためには、対象となるすべてのデータが物理的に同じサーバー(レプリカセット)上に存在する必要があります。論理パーティションキーが同じであれば、それらのデータは必ず同じ物理パーティション内に配置されるため、サーバー側での一括処理が可能になります。
2. 他の選択肢が不適切な理由
  • A (同じコンテナー内のアイテム): コンテナー内には複数の論理パーティションが存在する可能性があります。パーティションキーが異なるアイテム同士(異なる論理パーティション)に対しては、サーバー側のトランザクションは実行できません。
  • B (単一のアイテム): 単一のアイテムに対する操作は当然トランザクションとして成立しますが、今回の要件は「著者、本、レビュー」という複数のエンティティ間の参照整合性を維持することなので、スコープとしては「単一」よりも「論理パーティション」の方が広く、適切です。
  • C (同じデータベース内のアイテム): データベースは複数のコンテナーを跨ぐため、物理的に分散されています。コンテナーを跨いだトランザクションはサポートされていません。
設計への応用:データモデリングの重要性 この制約があるため、今回の IoT や著者/本のシナリオで参照整合性を保ちたい場合は、関連するデータを同じパーティションキーに配置する設計(例:すべてに AuthorId をパーティションキーとして持たせる等)が求められます。
Question#2(DP-420)

ホットスポット問題(1/3)

あなたは、db1 という名前の Azure Cosmos DB for NoSQL データベースを所有しています。 以下のコードを実行します。 以下の各ステートメントについて、その内容が正しい場合は「はい(Yes)」を、そうでない場合は「いいえ(No)」を選択してください。 ステートメント: ttl 値のないアイテムを customers コンテナーに挿入しても、期限切れになることはない。
ディスカッション 0

正解:A

  1. 根拠: コード内で DefaultTimeToLive = -1 と設定されています。
  2. 仕様: コンテナーレベルで -1 が設定されている場合、TTL 機能は「オン」になりますが、個別のアイテムに ttl フィールドが指定されていない限り、そのアイテムはデフォルトで無期限(決して消えない)となります。
Question#3(DP-420)

ホットスポット問題(2/3)

あなたは、db1 という名前の Azure Cosmos DB for NoSQL データベースを所有しています。 以下のコードを実行します。 以下の各ステートメントについて、その内容が正しい場合は「はい(Yes)」を、そうでない場合は「いいえ(No)」を選択してください。 ステートメント: customers コンテナーに挿入されるすべてのアイテムは、customerId フィールドを含まなければならない。
ディスカッション 0

正解:A

  1. 根拠: PartitionKeyPath = "/customerId" と定義されています。
  2. 仕様: Azure Cosmos DB では、コンテナーにアイテムを挿入する際、パーティションキーとして指定されたパスのフィールドがアイテム内に存在しなければなりません。存在しない場合、エラー(または undefined パーティションへの割り当て)となりますが、スキーマ設計上、パーティションキーは必須項目とみなされます。
Question#4(DP-420)

ホットスポット問題(3/3)

あなたは、db1 という名前の Azure Cosmos DB for NoSQL データベースを所有しています。 以下のコードを実行します。 以下の各ステートメントについて、その内容が正しい場合は「はい(Yes)」を、そうでない場合は「いいえ(No)」を選択してください。 ステートメント: TTL 値が 12 に設定されたアイテムを customers コンテナーに挿入すると、12 日後に期限切れになる。
ディスカッション 0

正解:B

  1. 根拠: TTL の数値の単位は「日」ではなく「秒」です。
  2. 仕様: アイテムレベルで ttl: 12 を指定して挿入した場合、そのアイテムは挿入(または最終更新)から 12 秒後に期限切れとなります。設問の「12 日後」という記述は誤りです。
Question#5(DP-420)

あなたは Azure サブスクリプションを所有しており、その中には Azure Cosmos DB for NoSQL アカウントが含まれています。

複数のアイテムを返す SQL クエリを記述する必要があります。ソリューションは以下の要件を満たす必要があります。
  • 返される各アイテムに、ISO 8601 文字列としてフォーマットされた現在の協定世界時 (UTC) の日付と時刻を含めること。
  • 開発の労力を最小限に抑えること。
あなたは何を使用すべきですか?
ディスカッション 0

正解:C

この問題は、Azure Cosmos DB の組み込み関数(Built-in functions)の戻り値の型とフォーマットの違いを理解しているかを問うています。

1. なぜ「(GetCurrentDateTime)」が正解なのか
  • フォーマットの要件: 要件には「ISO 8601 文字列」と指定されています。
  • 動作: GetCurrentDateTime() 関数は、現在の UTC 日付と時刻を、まさに ISO 8601 フォーマット(例: 2026-01-17T22:54:11.1234567Z)の文字列として返します。
  • 開発労力: 組み込み関数をそのまま呼び出すだけなので、追加のコード(UDF など)を記述する必要がなく、開発労力が最小限で済みます。
2. 他の選択肢が不適切な理由
  • (UDF): 独自の関数を JavaScript で記述・登録すれば同じことが可能ですが、組み込み関数が存在するため「開発労力を最小限に抑える」という要件に反します。
  • (GetCurrentTimestamp): この関数は、現在の UTC 日付と時刻を**数値(Unix タイムスタンプ、ミリ秒単位)**として返します。ISO 8601 文字列ではないため不適切です。
  • (DateTimePart): この関数は、指定された日付文字列から「年」や「月」などの特定の部分を抽出するための関数です。現在の時刻を取得するものではありません。
参考:Cosmos DB での日付の扱い Cosmos DB には「DateTime」という専用のデータ型は存在しません。日付を扱う場合は、以下のいずれかの形式で保存・管理するのが標準的です。
  1. ISO 8601 文字列: GetCurrentDateTime() で取得。クエリでの比較(文字列比較として動作)に適している。
  2. Unix タイムスタンプ: GetCurrentTimestamp() で取得。数値計算や効率的なインデックスに適している。
まとめ
  • 問い: UTC 日時を ISO 8601 文字列で取得したい。
  • 正解: GetCurrentDateTime() を使用する。