Azure Cosmos DB の要求ユニット

適用対象: SQL API Cassandra API Gremlin API Table API MongoDB 用 Azure Cosmos DB API

Azure Cosmos DB では、多くの API (SQL、MongoDB、Cassandra、Gremlin、Table など) がサポートされています。 各 API には、固有のデータベース操作のセットがあります。 これらの操作の範囲は、単純なポイント読み取り/書き込みから、複雑なクエリにまで及びます。 各データベース操作は、それらの操作の複雑さに基づいて、システム リソースを消費します。

すべてのデータベース操作のコストは Azure Cosmos DB によって正規化され、要求ユニット (RU) によって表されます。 要求ユニットは、Azure Cosmos DB によってサポートされるデータベース操作を実行するために必要な CPU、IOPS、メモリなどのシステム リソースを抽象化する、パフォーマンスの通貨です。

1 KB の項目をポイント読み取りする (つまり、ID とパーティション キーの値で 1 つの項目をフェッチする) コストは、1 要求ユニット (または 1 RU) です。 その他のすべてのデータベース操作にも、同様に RU を使用してコストが割り当てられます。 Azure Cosmos コンテナーの操作にどの API 使用するかに関係なく、コストは RU によって測定されます。 データベース操作が書き込み、ポイント読み取り、またはクエリのいずれの場合でも、コストは常に RU で測定されます。

次の図では、RU の高度な概念を示します。

データベース操作による要求ユニットの消費

容量を管理および計画するために、Azure Cosmos DB では、特定のデータセットに対する特定のデータベース操作の RU の数が決定的であることが確認されます。 すべてのデータベース操作によって消費される RU の数を追跡するには、応答ヘッダーを調べます。 RU 使用量に影響を与える要因とアプリケーションのスループット要件を理解したら、費用対効果の高い方法でアプリケーションを実行できます。

使用している Azure Cosmos アカウントの種類によって、使用した RU に対する課金方法が決まります。 アカウントを作成するには、次の 3 つのモードがあります。

  1. プロビジョニング スループット モード:このモードでは、アプリケーションの RU の数は秒単位でプロビジョニングします (増分は 100 RU/秒)。 アプリケーション用にプロビジョニング済みスループットをスケーリングするために、いつでも RU の値を増やしたり減らしたりできます (100 RU 単位での増減)。 変更は、プログラムまたは Azure portal を使用して行うことができます。 ユーザーは、1 秒あたりにプロビジョニング済み RU の量に対して時間単位で課金されます。 詳細については、プロビジョニング スループットに関する記事を参照してください。

    次の 2 つの個別の細分性でスループットをプロビジョニングできます。

  2. "サーバーレス モード": このモードでは、Azure Cosmos アカウントでリソースを作成するときに、スループットをプロビジョニングする必要はありません。 請求期間が終了すると、データベース操作で使用した要求ユニットの量に対して課金されます。 詳細については、サーバーレス スループットに関する記事をご覧ください。

  3. 自動スケーリング モード:このモードでは、ワークロードの可用性、待機時間、スループット、またはパフォーマンスに影響を与えずに、使用量に基づいてデータベースまたはコンテナーのスループット (RU/秒) が自動的かつ瞬時にスケーリングされます。 このモードは、変動し予測できないトラフィック パターンを持ち、かつハイ パフォーマンスとスケーリングに対する SLA を必要とするミッション クリティカルなワークロードに最適です。 詳細については、自動スケーリングのスループットに関する記事を参照してください。

要求ユニットの考慮事項

ワークロードに使用される RU 数を推定するときは、次の要因を考慮してください。

  • アイテムのサイズ:アイテムのサイズが増加すると、そのアイテムの読み取りまたは書き込みのために消費される RU の数も増加します。

  • アイテムのインデックス付け:既定では、アイテムごとにインデックスが自動的に作成されます。 コンテナー内の一部のアイテムにインデックスを作成しないように選択すると、消費される RU は少なくなります。

  • アイテム プロパティの数:すべてのプロパティで既定のインデックス作成を実行した場合、アイテム プロパティの数が増加すると、アイテムを書き込むために消費される RU の数が増加します。

  • インデックス付きプロパティ:各コンテナーのインデックス ポリシーによって、既定でインデックスが作成されるプロパティが決まります。 書き込み操作の RU 消費量を削減するには、インデックス付きプロパティの数を制限します。

  • データの一貫性:強力な有界整合性制約の整合性レベルでは、他の緩和された整合性レベルの場合と比べて、読み取り操作の実行中に約 2 倍の RU が消費されます。

  • 読み取りの種類:ポイント読み取りの場合は、クエリよりも RU のコストが大幅に低くなります。

  • クエリのパターン:クエリの複雑さは、操作のために消費される RU の数に影響を与えます。 クエリ操作のコストに影響する要因は次のとおりです。

    • クエリ結果の数
    • 述語の数
    • 述語の性質
    • ユーザー定義関数の数
    • ソース データのサイズ
    • 結果セットのサイズ
    • プロジェクション

    同じデータに対する同じクエリによって、繰り返しの実行で常に同じ数の RU のコストがかかります。

  • スクリプトの使用:クエリと同様に、ストアド プロシージャとトリガーは、実行される操作の複雑さに基づいて RU を消費します。 アプリケーションを開発する場合は、要求使用量ヘッダーを調べて、各操作で消費される RU 量をより深く理解してください。

要求ユニットと複数のリージョン

Cosmos コンテナー (またはデータベース) に 'R' 個の RU をプロビジョニングする場合、Cosmos DB により、Cosmos アカウントに関連付けられている それぞれ のリージョンで 'R' 個の RU が利用可能であることが確保されます。 特定のリージョンに RU を選択的に割り当てることはできません。 Cosmos コンテナー (またはデータベース) でプロビジョニングされた RU は、Cosmos アカウントに関連付けられているすべてのリージョンでプロビジョニングされます。

Cosmos コンテナーに 'R' 個の RU が構成され、Cosmos アカウントに 'N' 個のリージョンが関連付けられていると仮定すると、このコンテナーでグローバルに利用できる RU の合計は R x N になります。

選択した整合性モデルもスループットに影響します。 整合性レベルが比較的緩やかな場合 (セッション一貫性のあるプレフィックス最終的 など)、比較的強固な場合 (有界整合性制約厳密 など) と比べ、ほぼ 2 倍の読み取りスループットを得ることができます。

次のステップ