2.2Cosmos DB 向けの開発

グローバル分散・低遅延の NoSQL データベースが Azure Cosmos DB です。開発ではパーティションキー・RU/s・整合性レベルの理解が要です。

2.2.1キー・スループット・整合性

• パーティションキー：データを物理的に分散させる鍵。偏らないよう設計し、ホットパーティションを避ける。
• RU/s（リクエストユニット）：スループットの単位。プロビジョンド（固定/自動スケール）とサーバーレスがある。
• 整合性レベル：強整合〜結果整合の5段階。強いほど正確だが遅延/コストが増える。
• 変更フィード：コンテナの変更を時系列で取得し、イベント駆動処理（Functions 連携など）に使える。

Cosmos DB はグローバル分散・低遅延の NoSQL です。設計の核は パーティションキー——カーディナリティが高く読み書きが均等に分散する値を選び、偏ると ホットパーティション や 429 を招きます。スループットは RU/s（リクエストユニット） で、プロビジョンド（手動/オートスケール・予測可能な負荷）か サーバーレス（断続的・使った分だけ）を選択、専用 RU とコンテナ間で共有する データベース共有 RU があります。整合性レベル は 強整合 / 有界整合性制約 / セッション（既定）/ 整合性のあるプレフィックス / 結果整合 の5段で、強いほど正確だが遅延/コスト増（セッションが多くのアプリで好バランス）。複数リージョン書き込み（マルチリージョン書き込み）でグローバルに低遅延化、API は NoSQL/MongoDB/Cassandra/Gremlin/Table を選べます。変更フィード でコンテナ変更を時系列取得し Functions 連携。429（TooManyRequests）は 指数バックオフでリトライ し、必要なら RU/キー設計を見直します。判断軸は「分散＝パーティションキー」「断続負荷＝サーバーレス」「整合性は遅延とのトレードオフ」「変更の取得＝変更フィード」。

2.2.2この節のまとめ

• パーティションキー（分散）／RU/s（スループット）／整合性レベル
• 変更の時系列取得＝変更フィード、429＝バックオフ