Q1.あなたは、ある自動車部品販売会社向けにAzure Cosmos DB for NoSQLソリューションを設計しています。
自動車の修理部品に関する製品データを保持するContainer1という新しいコンテナーを用意する予定です。
データ構造は提示された表のとおりです。
このデータベースに対して、データのパーティション分割方法を提案する必要があります。
提案では、I/Oの競合を最小限に抑えるようにワークロードを分散させる必要があります。
物理パーティションキーと論理パーティションキーには、それぞれどの列を推奨すべきですか。
回答領域で最適な選択肢を選んでください。
| 列名 | データの種類 | データの長さ（バイト） |
|---|---|---|
| 車のブランド | 文字列 | 30 |
| 車のモデル | 文字列 | 30 |
| モデル年 | 整数 | 4 |
| 部品名 | 文字列 | 50 |
| 部品の説明 | 文字列 | 500 |
| 保管場所 | 文字列 | 50 |
| 車のブランド | 車のモデル | モデル年 | 部品名 | 保管場所 | 部品の説明 |
|---|---|---|---|---|---|
| フォード | エスコート | 1999 | ドアハンドル | 棚5、ビン3 | 説明1 |
| フォード | エスコート | 2000 | ドアハンドル | 棚5、ビン5 | 説明2 |
| フォード | エスコート | 2001 | ドアハンドル | 棚32、ビン17 | 説明3 |
| フォード | エスケープ | 1999 | ドアハンドル | 棚43、ビン12 | 説明4 |
| シボレー | ベイサー | 1975 | ドアハンドル | 棚19、ビン12 | 説明5 |
| シボレー | ボルト | 2024 | トランクリリース | 棚20、ビン17 | 説明6 |
解答を見る
モデル年式は提示データで5種類の異なる値を持ち、ブランドや部品名よりカーディナリティが高いため、書き込みを広く分散でき、I/O競合やホットパーティションの発生を抑えられます。
このため物理パーティションキーにはモデル年式が適しています。
論理パーティションキーに車種を選ぶと、同じモデル年式のデータを車種単位でさらに細分化でき、モデル年式と車種の組み合わせは提示データで一意になります。
Azure Cosmos DBでは論理パーティションがパーティションキー値で形成され、物理パーティションへの配置はサービスが自動的に管理します。
そのため、データと要求を均等に分散できるキーを選ぶことが重要です。
Azure Cosmos DBでのパーティション分割と水平方向のスケーリング
Q2.Container1という名前のコンテナーをホストするAzure Cosmos DB for NoSQLデータベースがあります。
このContainer1を利用するApp1という新しいアプリケーションを開発しています。
App1がContainer1内のドキュメントを削除しようとした際に、その操作を阻止してアプリにエラーを返す必要があります。
何を使用すべきですか。
解答を見る
プリトリガーはデータベース項目が変更される前に実行されるため、削除処理が行われる前にJavaScriptで例外をスローし、操作を中止してApp1へエラーを返せます。
ポストトリガーは変更後に実行され、UDFは主にクエリ内の計算に使われるため、この用途には適しません。
トリガーは自動実行されないため、App1の削除要求時にプリトリガーを明示的に指定する必要があります。
なお、問題文の「ドキュメント」は、現在のMicrosoft公式資料では主に「項目（item）」と表記されます。
Azure Cosmos DB でストアド プロシージャ、トリガー、およびユーザー定義関数を記述する方法
Q3.Azure Cosmos DBのアカウントとデータベースをプロビジョニングするAzure Resource Manager（ARM）テンプレートが用意されています。
各アカウントは単一のAzureリージョンにデプロイされています。
各データベースにはプロビジョニング済みスループットが設定されています。
リージョン名、データベースのスループットの種類、スループット値は、いずれもテンプレートパラメーターとして定義されています。
次の各シナリオに従って、一部のアカウントとデータベースを変更する必要があります。
シナリオ1：読み取りリージョンを追加し、データベースのスループットを引き上げます。
シナリオ2：手動プロビジョニング済みのデータベーススループットを自動スケーリングへ切り替えます。
この対応では、管理の手間と変更に要する時間を最小限に抑える必要があります。
各シナリオでは何を使用すべきですか。
回答領域で最適な選択肢を選んでください。
解答を見る
リージョンの追加・削除と、その他のプロパティ変更は同一のデプロイで同時に実行できません。
そのためシナリオ1では、読み取りリージョンの追加とRU/sの増加を2回の増分デプロイに分割します。
増分モードなら、テンプレートに含まれない既存リソースが削除されません。
手動スループットから自動スケーリングへの移行はPOST操作であり、ARMテンプレートではサポートされないため、シナリオ2ではAzure PowerShellを使用します。
Azure Resource Manager テンプレートを使用して Azure Cosmos DB for NoSQL リソースを管理する
Azure Resource Manager のデプロイ モード
Q4.Azure Cosmos DB for NoSQLアカウントからデータを取り込めるように、Apache Kafkaのインスタンスを構成する必要があります。
telemetryという名前のコンテナーのデータを、iotという名前のKafkaトピックへ送り込む必要があります。
この構成では、データをコンパクトなバイナリ形式で保持する必要があります。
ソリューションに含めるべき構成項目を3つ選択してください。
各正解は、ソリューションの一部を表します。
解答を見る
Cosmos DBからKafkaへデータを送信するため、CosmosDBSourceConnectorを使用します。
Sinkコネクターは逆に、KafkaからCosmos DBへデータを書き込む際に使用します。
コンパクトなバイナリ形式にはAVROを用いるため、AvroConverterが必要です。
また、topicmapは「Kafkaトピック名#Cosmos DBコンテナー名」の形式となるため、iot#telemetryと設定します。
実際の構成では、データ本体に対するvalue.converterやスキーマレジストリの設定も確認が必要です。
Azure Cosmos DB用Kafka Connect
Kafka Connect for Azure Cosmos DB – ソース コネクタ
Q5.注文と、それぞれの注文に紐づく注文明細を格納するAzure Cosmos DB for NoSQLアカウントをデプロイする予定です。
単一の注文とその注文明細を読み取る際の性能を最大化し、コストを最小化できるアカウント設計を推奨する必要があります。
何を推奨すべきですか。
解答を見る
注文と注文明細を常に一緒に読み取る場合は、注文明細を配列として注文のJSON項目内に埋め込む非正規化設計が適しています。
注文全体を1回のポイント読み取りで取得でき、複数項目へのクエリや複数回の読み取りが不要になるため、待機時間とRU消費を抑えられます。
別コンテナーや別項目へ分割すると、追加の要求や結合処理が発生します。
Azure Cosmos DB for NoSQLは現行の正式名称で、旧称のSQL APIから変更されています。
Azure Cosmos DB for NoSQL でのデータ モデリング
Azure Cosmos DB での要求コストを最適化する
Q6.Azure Cosmos DBデータベースがあります。
製品データと製品カテゴリーデータを格納し、主に読み取り要求を処理するcontainer1という新しいコンテナーを作成する予定です。
このcontainer1のパーティションキーを構成する必要があります。
ソリューションは次の要件を満たす必要があります。
パーティションのサイズを最小限に抑える。
メンテナンス作業を最小限に抑える。
どの2つの特性を優先すべきですか。
各正解は、ソリューションの一部を表します。
解答を見る
カーディナリティが高いキーは、多数の異なる値によって項目を細かい論理パーティションへ分散できるため、各パーティションのサイズを小さく保ちやすくなります。
カーディナリティが低いと、多くの項目が同じキー値に集中する恐れがあります。
静的なキーは値が変化しないため、変更に伴う項目の削除・再作成を避け、メンテナンス作業を抑えられます。
Azure Cosmos DBでは、作成済み項目のパーティションキー値をその場で変更することはできません。
Azure Cosmos DBでのパーティション分割と水平方向のスケーリング
Q7.Azure Cosmos DB for NoSQLアカウントがあります。
すべてのログ情報をLog Analyticsワークスペースへ送信するよう、診断設定を構成しました。
このアカウント内のリソースについて、プロビジョニングされた1秒あたりの要求ユニット数（RU/s）がいつ変更されたのかを特定する必要があります。
そこで、次のクエリを作成しました。
AzureDiagnostics
| where Category == “ControlPlaneRequests”
このクエリに何を追加すべきですか。
解答を見る
Azure Cosmos DB for NoSQLコンテナーのスループット変更は、OperationNameが「SqlContainersThroughputUpdate」で始まるコントロールプレーン操作として記録されます。
したがって、Dを追加すればRU/sが変更された日時を抽出できます。
RegionAddCompleteはリージョン追加、SqlContainersCreateはコンテナー作成、MongoCollectionsThroughputUpdateはMongoDB用APIのコレクションに対するスループット変更を表します。
AzureDiagnosticsは現在レガシモードの共通テーブルであり、新しい構成ではリソース固有テーブルも選択できますが、このクエリではAzureDiagnosticsを使用します。
Azure Cosmos DB コントロール プレーン操作を監査する方法
Azure Cosmos DB を監視する
Q8.注：このセクションには、同じシナリオと問題を扱う問題セットが1つ以上含まれています。
各問題では固有のソリューションが提示され、それが示された目標を満たすかどうかを判断する必要があります。
セット内の複数のソリューションが問題を解決する場合もあれば、いずれのソリューションも解決しない場合もあります。
このセクションの問題は、一度回答すると後戻りできません。
そのため、これらの問題はレビュー画面には表示されません。
Azure Cosmos DB for NoSQLデータベースがあり、次の形式でデータを格納するfamiliesという名前のコンテナーをホストしています。
フィールドの意味：parentsは親、familyNameは姓、givenNameは名、childrenは子ども、genderは性別、femaleは女性、gradeは学年、petsはペット、typeは種類、dogは犬、catは猫、addressは住所、stateは州、countyは郡、cityは市、creationDateは作成日時、isRegisteredは登録済みかどうか、falseは偽を表します。
次のデータを返す必要があります。
家族のID
子どもの姓
ペットの種類が猫である場合、そのペットの名前
ソリューション：次のクエリを実行します。
SELECT f.id, c.familyName AS FamilyName, p.givenName AS petName FROM families f JOIN f.children c JOIN (SELECT value p FROM c.pets p WHERE p.type = ‘cat’) AS p
このソリューションは目標を満たしますか。
解答を見る
最初のJOINでchildren配列の各要素が展開され、c.familyNameから子どもの姓を取得できます。
続く複数値サブクエリは、各子どものpets配列をtypeがcatである要素だけに絞り込み、そのgivenNameをpetNameとして返します。
その結果、f.id、子どもの姓、猫の名前という要求された項目を取得できるため、目標を満たします。
現在の公式資料でも、配列内の自己結合とJOIN前に配列を絞り込む複数値サブクエリがサポートされています。
サブクエリ – Cosmos DB のクエリ言語 (Azure と Fabric)
自己結合 – Cosmos DB のクエリ言語 (Azure と Fabric)
Q9.Azure Cosmos DB for NoSQLアカウントに、db1という名前のデータベースがあります。
REST APIを介して公開されているサードパーティ製のアプリケーションがあります。
このアプリケーションからdb1内のコンテナーへ、毎週データを移行する必要があります。
どのツールを使用すべきですか。
解答を見る
Azure Data Factoryのコピーアクティビティでは、RESTコネクターをソースとしてREST APIからデータを取得し、Azure Cosmos DB for NoSQLコネクターをシンクとしてコンテナーへ書き込めます。
また、スケジュールトリガーで繰り返し間隔を設定できるため、パイプラインを毎週自動実行できます。
Azure Migrateは主にサーバーなどのAzureへの移行に使用し、Database Migration AssistantはSQL Server系の評価や移行を目的とするため、定期的なREST連携には適しません。
Azure Data Factoryを使用して REST エンドポイントとの間でデータをコピーおよび変換する
Azure Data Factoryを使用してNoSQLのAzure Cosmos DB内のデータをコピーおよび変換する
Q10.次のAzure Resource Manager（ARM）テンプレートがあります。
コード内のconsistentは一貫性のあるインデックス作成、ascendingは昇順、descendingは降順を表します。
このテンプレートを増分モードでデプロイする予定です。
次の各記述について、正しい場合は「はい」を、それ以外の場合は「いいえ」を選択してください。
| 問題文 | はい | いいえ | |
|---|---|---|---|
| テンプレートをデプロイすると、acct01という名前のAzure Cosmos DBアカウントが存在しない場合に、そのアカウントが作成される。 | |||
| テンプレートをデプロイすると、mydb内にmycontainerという名前のコンテナーが存在しない場合に、そのコンテナーが作成される。 | |||
| テンプレートをデプロイすると、mycontainerが存在しパーティションキーがnameである場合に、そのパーティションキーがcompanyidへ変更される。 |
解答を見る
テンプレートにはコンテナーの子リソースだけが定義されているため、存在しないacct01アカウントやmydbデータベースは自動的には作成されません。
親リソースが既に存在していれば、増分デプロイによって未作成のmycontainerは作成されます。
既存コンテナーのパーティションキーは/nameから/companyidへ直接変更できず、別のパーティションキーを使うには新しいコンテナーへのデータ移行が必要です。
Microsoft.DocumentDBは現在もAzure Cosmos DBで使用される正式なリソースプロバイダー名前空間です。
Microsoft.DocumentDB データベースアカウント/sqlデータベース/コンテナ
子リソースの名前と種類を設定する