Question#1(DP-420)

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 をパーティションキーとして持たせる等)が求められます。

コメント

コメント

コメントする

目次