Azure Cosmos DB サービスのクォータ
適用対象: 
NoSQL MongoDB Cassandra Gremlin Table
この記事では、Azure Cosmos DB の各種リソースに提供される既定のクォータの概要を説明します。
ストレージとデータベースの操作
サブスクリプションで Azure Cosmos DB アカウントを作成した後は、データベース、コンテナー、および項目を作成することによってアカウント内のデータを管理できます。
プロビジョニング スループット
スループットは、要求ユニット (RU/秒 または RU) の単位で、コンテナー レベルまたはデータベース レベルで割り当てられます。 次の表は、コンテナー/データベースあたりのストレージとスループットの制限の一覧を示しています。 ストレージはデータとインデックス ストレージの量を組み合わせたものになります。
| リソース | 制限 |
|---|---|
| コンテナーあたりの最大 RU (専用スループット プロビジョニング モード) | 1,000,000 ¹ |
| データベースあたりの最大 RU (共有スループット プロビジョニング モード) | 1,000,000 ¹ |
| パーティションあたりの最大 RU (論理 & 物理) | 10,000 |
| すべての項目にわたる、(論理) パーティションあたりの最大ストレージ | 20 GB ² |
| 個別の (論理) パーティション キーの最大数 | 無制限 |
| コンテナーあたりの最大ストレージ | 無制限 |
| アカウントあたりの添付ファイルの最大サイズ (添付ファイル機能は非推奨になってきています) | 2 GB |
| 1 GB あたりに必要な最小 RU/秒 | 1 RU/秒 |
¹ Azure サポート チケットを提出することで、コンテナーまたはデータベースごとの最大 RU を増やすことができます。
² ストレージまたはスループットにより高い制限が必要なパーティション キーを持つワークロードを管理するためのベスト プラクティスについては、「合成パーティション キーの作成」を参照してください。 ワークロードが運用環境で論理パーティションの上限である 20 GB に既に達している場合は、長期的なソリューションとして、別のパーティション キーを使用してアプリケーションを再設計することをお勧めします。 アプリケーションの再設計に時間をかけられるよう、既存のアプリケーションの論理パーティション キーの制限を一時的に増やすことを要求できます。 Azure サポート チケットを呈出し、クォータの種類 [コンテナーの論理パーティション キー サイズの一時的な増加] を選択します。 一時的に増やすことを要求するのは一時的な軽減策であり、上限が引き上げられていると SLA の保証が適用されないため、長期的な解決策としては推奨されていません。 構成を削除するには、サポート チケットを提出し、クォータの種類 [コンテナーの論理パーティション キー サイズを既定値 (20 GB) に復元する] を選択します。 このサポート チケットの提出は、論理パーティションの 20 GB の制限に合わせてデータを削除するか、別のパーティション キーでアプリケーションを再設計した後に実行できます。
最小スループットの制限
手動スループットを使う Azure Cosmos DB コンテナー (または共有スループット データベース) には、400 RU/s 以上のスループットが必要です。 コンテナーのサイズが大きくなるにつれて、Azure Cosmos DB では、リソース (データベースまたはコンテナー) にその操作を行うための十分なリソースがあることを確認するために最小限のスループットが必要になります。
コンテナーまたはデータベースの現在のスループットと最小スループットは、Azure portal または SDK から取得できます。 詳細については、コンテナーとデータベースのスループットの割り当てに関する記事を参照してください。
実際の最小 RU/秒は、アカウントの構成によって異なる場合があります。 Azure Monitor メトリックを使用して、プロビジョニングされたスループット (RU/秒) とリソース上のストレージの履歴を表示できます。
コンテナーの最小スループット
このセクションを使用して、コンテナーの最小スループットを見積もります。
手動スループット
手動スループットでコンテナーに必要な最小 RU/秒を見積もるには、次の最大値を見つけます。
- 400 RU/秒
- 現在のストレージ (GB 単位) × 1 RU/秒
- コンテナーで今までプロビジョニングされた最高 RU/秒 ÷ 100
たとえば、400 RU/秒と 0 GB のストレージでプロビジョニングされたコンテナーがあるとします。 スループットを 50,000 RU/秒に増やし、20 GB のデータをインポートします。 この時点で、最小 RU/秒は MAX(400, 20 * 1 RU/s per GB, 50,000 RU/s / 100) = 500 RU/秒になります。 時間の経過と共に、ストレージは 2000 GB まで増えました。 この時点で、最小 RU/秒は MAX(400, 2000 * 1 RU/s per GB, 50,000 / 100) = 2000 RU/秒になります。
自動スケーリングのスループット
自動スケーリング スループットでコンテナーに必要な最小自動スケーリングの最大 RU/秒を見積もるには、次の最大値を見つけます。
- 1000 RU/秒
- [Current storage in GB] (現在のストレージ (GB 単位)) * 10 RU/s
- コンテナーで今までプロビジョニングされた最高 RU/秒 / 10
たとえば、1000 RU/秒で 0 GB のストレージでプロビジョニングされたコンテナーがあるとします。 スループットを 50,000 RU/秒に増やし、20 GB のデータをインポートします。 最小の最大 RU/秒は、MAX(1000, 20 * 10 RU/s per GB, 50,000 RU/s / 10) = 5,000 RU/秒になります。 時間の経過と共に、ストレージは 2000 GB まで増えました。 最小の最大 RU/秒は、MAX(1000, 2000 * 10 RU/s per GB, 50,000 / 10) = 20,000 RU/秒になります。
共有スループット データベースでの最小スループット
このセクションを使用して、コンテナー間でスループットを共有するデータベースの最小スループットを見積もります。
手動スループット
手動スループットで共有スループット データベースに必要な最小 RU/秒を見積もるには、次の最大値を見つけます。
- 400 RU/秒
- 現在のストレージ (GB 単位) × 1 RU/秒
- データベースで今までプロビジョニングされた最高 RU/秒 ÷ 100
- 400 + MAX(コンテナー数 - 25, 0) * 100 RU/秒
たとえば、400 RU/秒、15 GB のストレージ、10 個のコンテナーでプロビジョニングされたデータベースがあるとします。 この時点で、最小 RU/秒は MAX(400, 15 * 1 RU/s per GB, 400 / 100, 400 + 0 ) = 400 RU/秒になります。 データベースに 30 個のコンテナーがあった場合、最小 RU/秒は 400 + MAX(30 - 25, 0) * 100 RU/s = 900 RU/秒になります。
自動スケーリングのスループット
自動スケーリング スループットで共有スループット データベースに必要な最小自動スケーリングの最大 RU/秒を見積もるには、次の最大値を見つけます。
- 1000 RU/秒
- [Current storage in GB] (現在のストレージ (GB 単位)) * 10 RU/s
- データベースで今までプロビジョニングされた最高 RU/秒 / 10
- 1000 + MAX(コンテナー数 - 25, 0) * 1,000 RU/秒
たとえば、1000 RU/秒、15 GB のストレージと 10 個のコンテナーでプロビジョニングされたデータベースがあるとします。 自動スケーリング データベースの最小の最大 RU/秒は、MAX(1000, 15 * 10 RU/s per GB, 1000 / 10, 1000 + 0 ) = 1,000 RU/秒になります。 データベースに 30 個のコンテナーがあった場合、最小の最大 RU/秒は 1000 + MAX(30 - 25, 0) * 1000 RU/s = 5,000 RU/秒になります。
まとめると、プロビジョニングされたスループットを使用する場合の最小プロビジョニング済み RU の制限は次のようになります。
| プロビジョニングの種類 | リソース | 制限 |
|---|---|---|
| 手動スループット | コンテナーあたりの最小 RU (手動スループットを使う専用スループット プロビジョニング モード) | 400 |
| 手動スループット | データベースあたりの最小 RU 数 (手動スループットを使う共有スループット プロビジョニング モード) | 最初の 25 個のコンテナーに対して 400 RU/秒。 |
| 自動スケーリングのスループット | コンテナーあたりの最小の最大 RU 数 (自動スケーリング スループットを使う専用スループット プロビジョニング モード) | 1000 |
| 自動スケーリングのスループット | データベースあたりの最小の最大 RU 数 (自動スケーリング スループットを使う共有スループット プロビジョニング モード) | 最初の 25 個のコンテナーに対して 1,000 RU/秒。 |
Azure Cosmos DB は、SDK またはポータルを経由した、コンテナーまたはデータベースあたりのスループット (RU/s) のプログラムによるスケーリングをサポートしています。
プロビジョニングされた現在の RU/秒とリソースの設定によっては、最小 RU/秒から最大で 100 倍の最小 RU まで、各リソースを同期的かつ即座に拡張できます。 要求されたスループット値がこの範囲外である場合、スケーリングは非同期的に実行されます。 非同期のスケーリングは、要求されたスループットやコンテナー内のデータ ストレージ サイズに応じて、完了するまでに数分～数時間かかることがあります。 詳細情報。
サーバーレス
サーバーレスでは、使用量に基づく方法で Azure Cosmos DB リソースを使用できます。 次の表は、コンテナー/データベースあたりのストレージとスループットのバースト能力に関する制限の一覧を示しています。 これらの制限を増やすことはできません。 より多くのストレージのニーズに対応するために、追加のサーバーレス アカウントを割り当てることをお勧めします。
| リソース | 制限 |
|---|---|
| コンテナーあたりの最大 RU/秒 | 20,000* |
| すべての項目にわたる、(論理) パーティションあたりの最大ストレージ | 20 GB |
| コンテナーあたりの最大ストレージ | 1 TB (テラバイト) |
* 最大 RU/秒の可用性は、コンテナーに格納されているデータによって異なります。 「サーバーレスのパフォーマンス」を参照してください。
コントロール プレーン
Azure Cosmos DB では、Azure Cosmos DB アカウント内のリソースを作成、更新、削除するための管理レイヤーを提供するリソース プロバイダーが維持されています。 リソース プロバイダーは、Azure のデプロイと管理サービスである Azure リソース管理レイヤー全体とのインターフェイスを提供します。 Azure Cosmos DB リソースは、Azure portal、Azure PowerShell、Azure CLI、Azure Resource Manager、Bicep テンプレート、Rest API、Azure Management SDK、Terraform や Pulumi などのサード パーティ製ツールを使用して、作成および管理できます。
アカウント内でリソースを作成および管理するために、アプリケーションで使用される Azure Cosmos DB データ プレーン SDK からこの管理レイヤーにアクセスすることもできます。 また、データ プレーン SDK は、サービスへの最初の接続中にコントロール プレーン要求を行い、データベースとコンテナーの列挙や認証用のアカウント キーの要求などを行います。
Azure Cosmos DB の各アカウントには、アカウントのすべてのメタデータを含む master partition があります。 また、コントロール プレーン操作をサポートするためのスループットも少量です。 このメタデータを作成、読み取り、更新、削除するコントロール プレーン要求では、このスループットが消費されます。 コントロール プレーン操作によって消費されるスループットの量がこの量を超えると、Azure Cosmos DB 内のデータ プレーン操作と同じレート制限が適用されます。 ただし、データ操作のスループットとは異なり、マスター パーティションのスループットを増やすことはできません。
Get キーや List Keys など一部のコントロール プレーン操作では、マスター パーティションのスループットが消費されません。 ただし、Azure Cosmos DB アカウント内のデータに対する要求とは異なり、Azure 内のリソース プロバイダーは大量の要求を処理するように設計されていません。 記載されている制限を超えるコントロール プレーン操作が、連続する 5 分間にわたって継続的なレベルで行われる場合、Azure Cosmos DB リソースで要求が調整されたり、失敗または不完全な操作になったりする可能性があります。
コントロール プレーン操作は、Azure Cosmos DB アカウントの [分析情報] タブに移動することで監視できます。 詳細については、「コントロール プレーン要求の監視」を参照してください。 ユーザーはこれらをカスタマイズしたり、Azure Monitor を使用したりできます。また、メタデータ要求を監視するためのブックを作成したり、それらにアラートを設定したりすることもできます。
リソース制限
次の表に、サブスクリプションまたはアカウントごとのリソース制限の一覧を示します。
| リソース | 制限 |
|---|---|
| サブスクリプションあたりのアカウントの最大数 | 既定では 250 ¹ |
| アカウントあたりのデータベースおよびコンテナーの最大数 | 500 ² |
| アカウントでサポートされているメタデータ操作の最大スループット | 240 RU/秒 |
¹ Microsoft 内部のお客様には、別の制限が適用されます。 Azure サポート リクエストを作成すると、上限を最大 1,000 まで増加できます。 Cosmos DB は、空のデータベース アカウント (データベースまたはコレクションのないアカウント) を削除する権利を留保します。 ² この制限を増やすことはできません。 アカウントを持つ両方の合計数 (1 データベースと 499 コンテナー、250 データベースと 250 コンテナーなど)。
要求の制限
次の表に、アカウントごとに 5 分間隔あたりの要求制限を示します (特にその他の指定がない場合)。
| 操作 | 制限 |
|---|---|
| キーの一覧表示または取得の最大数 | 500 ¹ |
| 作成するデータベースおよびコンテナーの最大数 | 500 |
| 取得または一覧表示するデータベースおよびコンテナーの最大数 | 500 ¹ |
| プロビジョニングされたスループットの更新の最大数 | 25 |
| リージョン内フェールオーバーの最大数 | 10 (1 時間あたり) ² |
| 上記で定義されていないすべての操作 (PUT、POST、PATCH、DELETE、GET) の最大数 | 500 |
¹ ユーザーは SDK インスタンスにシングルトン クライアントを使用し、そのインスタンスの有効期間中は要求間でキーおよびデータベースとコンテナーの参照をキャッシュする必要があります。 ² リージョン内フェールオーバーは、単一リージョン書き込みのアカウントにのみ適用されます。 複数リージョン書き込みのアカウントには、書き込みリージョンの変更は必要ないか、または許可されません。
Azure Cosmos DB では、データのバックアップが一定の間隔で自動的に取得されます。 バックアップ保有期間の間隔とウィンドウの詳細については、「Azure Cosmos DB でのオンライン バックアップとオンデマンドのデータ復元」を参照してください。
アカウントあたりの制限
アカウントごとの制限の一覧を次に示します。
プロビジョニング スループット
| リソース | 制限 |
|---|---|
| アカウントあたりのデータベースとコンテナーの最大数 | 500¹ |
| データベースあたりのコンテナーの最大数 (共有スループット) | 25 |
| リージョンの最大数 | 制限なし (すべての Azure リージョン) |
サーバーレス
| リソース | 制限 |
|---|---|
| アカウントあたりのデータベースとコンテナーの最大数 | 500 |
| リージョンの最大数 | 1 (任意の Azure リージョン) |
コンテナーあたりの制限
使用する API に応じて、Azure Cosmos DB コンテナーは、コレクション、テーブル、グラフのいずれかを表すことができます。 コンテナーは、一意キー制約、ストアド プロシージャ、トリガー、UDF、およびインデックス作成ポリシーの構成をサポートしています。 次の表は、コンテナー内の構成に固有の制限の一覧を示しています。
| リソース | 制限 |
|---|---|
| データベースまたはコンテナー名の最大長 | 255 |
| コンテナーあたりのストアド プロシージャの最大数 | 100 ¹ |
| コンテナーあたりの UDF の最大数 | 50 ¹ |
| コンテナーあたりの一意キーの最大数 | 10 ¹ |
| 一意キー制約あたりのパスの最大数 | 16 ¹ |
| 最大 TTL 値 | 2147483647 |
¹ これらのコンテナーあたりの制限はいずれも、Azure サポート リクエストを作成することによって増やすことができます。
項目あたりの制限
使用する API に応じて、Azure Cosmos DB の項目では、コレクション内のドキュメント、テーブル内の行、グラフ内のノードまたはエッジのいずれかを表すことができます。 次の表は、Azure Cosmos DB での項目あたりの制限を示しています。
| リソース | 制限 |
|---|---|
| 項目の最大サイズ | 2 MB (JSON 表現の UTF-8 の長さ) ¹ |
| パーティション キー値の最大長 | 2048 バイト (大きいパーティション キーが有効になっていない場合は 101 バイト) |
| ID 値の最大長 | 1023 バイト |
| ID 値に使用できる文字 | サービス側では、'/' と '\' を除くすべての Unicode 文字を使用できます。 警告: ただし、相互運用性を最大限に高めるために、ID 値には英数字の ASCII 文字のみを使用することを強くお勧めします。 Cosmos DB SDK のいくつかのバージョン、コネクター (ADF、Spark、Kafka など)、HTTP ドライバーまたはライブラリなどには、ID 値に英数字以外の ASCII 文字が含まれていると正常に処理できない既知の制限があります。 したがって、相互運用性を高めるために、ID 値をエンコードするようにしてください。たとえば、Base64 と Base64 で許可されている特殊文字を組み合わせたカスタム エンコーディングを使用してください。 これは、英数字以外の ASCII 文字を使用しなければならない場合が該当します。 |
| 項目あたりのプロパティの最大数 | 実質的に無制限 |
| プロパティ名の最大長 | 実質的に無制限 |
| プロパティ値の最大長 | 実質的に無制限 |
| 文字列のプロパティ値の最大長 | 実質的に無制限 |
| 数値のプロパティ値の最大長 | IEEE754 倍精度 64 ビット |
| 埋め込みオブジェクト/配列の入れ子の最大レベル | 128 |
| 最大 TTL 値 | 2147483647 |
| JSON における数値の最大精度/範囲(安全な相互運用性を確保するため) | IEEE 754 binary64 |
¹ 16 MB までの大きなドキュメント サイズは、Azure Cosmos DB for MongoDB でのみサポートされます。 詳細については、 機能のドキュメント を参照してください。
パーティション キー値と ID 値に関する長さの制限および 2 MB の全体的なサイズ制限を除き、項目ペイロードに制限はありません (プロパティの数や入れ子の深さなど)。 RU の消費を削減するために、大きな、または複雑な項目構造を持つコンテナーのインデックス作成ポリシーを構成することが必要になる場合があります。 実際の例や大きな項目を管理するためのパターンについては、Azure Cosmos DB での項目のモデル化 に関するページを参照してください。
要求あたりの制限
Azure Cosmos DB は、コンテナー、項目、データベースなどのリソースに対して CRUD とクエリ操作をサポートしています。 また、コンテナー内の同じパーティション キーを持つ項目に対するトランザクション バッチ要求もサポートしています。
| リソース | 制限 |
|---|---|
| 1 つの操作 (ストアド プロシージャの実行や 1 回のクエリ ページ取得など) の最大実行時間 | 5 秒 |
| 最大要求サイズ (ストアド プロシージャ、CRUD など) | 2 MB |
| 最大応答サイズ (ページ分割されたクエリなど) | 4 MB |
| トランザクション バッチ内の操作の最大数 | 100 |
Azure Cosmos DB は、書き込み中のトリガーの実行をサポートします。 このサービスでは、書き込み操作あたり最大 1 つのプリトリガーと 1 つのポストトリガーがサポートされます。
クエリなどの操作が実行タイムアウトまたは応答サイズの制限に達すると、その操作は、実行を再開するために結果のページと継続トークンをクライアントに返します。 1 つのクエリをページや継続にまたがって実行できる期間に実質的に制限はありません。
Azure Cosmos DB は 承認のために HMAC を使用します。 主キーを使用して、リソースへのきめ細かいアクセス制御を行うことができます。 これらのリソースには、コンテナー、パーティション キー、または項目が含まれます。 次の表は、Azure Cosmos DB での承認トークン制限の一覧を示しています。
| リソース | 制限 |
|---|---|
| プライマリ トークンの最大有効期限 | 15 分 |
| リソース トークンの最小有効期限 | 10 分 |
| リソース トークンの最大有効期限 | 既定では 24 時間 ¹ |
| トークン承認の最大クロック スキュー | 15 分 |
¹ これは、Azure サポート チケットを提出することによって増やすことができます
自動スケーリングでプロビジョニングされたスループットの制限
自動スケーリングでのスループットとストレージの制限の詳細については、自動スケーリングおよび FAQ に関する記事をご覧ください。
| リソース | 制限 |
|---|---|
| システムをスケーリングできる最大 RU/秒 | Tmax: ユーザーによって設定された自動スケーリングの最大 RU/秒 |
| システムをスケーリングできる最小 RU/秒 | 0.1 * Tmax |
| システムがスケーリングされる現在の RU/秒 | 0.1*Tmax <= T <= Tmax: 使用量に基づきます |
| 請求可能な時間あたり最小 RU/秒 | 0.1 * Tmax 課金は時間単位で行われます。この場合、システムがスケーリングされる時間あたり最大 RU/秒または 0.1*Tmax のいずれか大きい方について課金されます。 |
| コンテナーの自動スケーリング最大 RU/秒の最小値 | MAX(1000, highest max RU/s ever provisioned / 10, current storage in GB * 10): 最も近い 1000 RU/秒に切り上げられます |
| データベースの自動スケーリング最大 RU/秒の最小値 | MAX(1000, highest max RU/s ever provisioned / 10, current storage in GB * 10, 1000 + (MAX(Container count - 25, 0) * 1000)): 最も近い 1,000 RU/秒に丸められます。 データベースに 25 個を超えるコンテナーがある場合は、自動スケーリング最大 RU/秒の最小値が、追加のコンテナー 1 つにつき 1000 RU/秒ずつインクリメントされることにご注意ください。 たとえば、コンテナーが 30 個ある場合、設定できる自動スケーリング最大 RU/s の最小値は 6000 RU/s (600 から 6000 RU/s の間でスケーリング) です。 |
SQL クエリの制限
Azure Cosmos DB は、SQL を使用した項目のクエリをサポートします。 次の表では、クエリ ステートメントでの制限 (句の数やクエリの長さなどの単位) について説明します。
| リソース | 制限 |
|---|---|
| SQL クエリの最大長 | 512 KB |
| クエリあたりの最大 JOIN | 10 ¹ |
| クエリあたりの最大 UDF | 10 ¹ |
| 多角形あたりの最大ポイント | 4096 |
| コンテナーあたり明確に含まれる最大パス | 1500 ¹ |
| コンテナーあたり明確に除外される最大パス | 1500 ¹ |
| 複合インデックスの最大プロパティ | 8 |
| 複合インデックス内のパスの最大数 | 100 |
¹ これらの SQL クエリの制限はいずれも、Azure サポート リクエストを作成することによって増やすことができます。
MongoDB 用 API 固有の制限
Azure Cosmos DB は、MongoDB に対して書き込まれたアプリケーションのための MongoDB ワイヤ プロトコルをサポートします。 サポートされるコマンドおよびプロトコル バージョンは、サポートされる MongoDB の機能と構文に関するページで見つけることができます。
次の表は、MongoDB 機能のサポートに固有の制限の一覧を示しています。 NoSQL 用 API に関して説明されているその他のサービス制限は、MongoDB 用 API にも適用されます。
| リソース | 制限 |
|---|---|
| ドキュメントの最大サイズ | 16 MB (JSON 表現の UTF-8 の長さ) ¹ |
| MongoDB クエリの最大メモリ サイズ (この制限は 3.2 サーバー バージョンにのみ適用されます) | 40 MB |
| MongoDB 操作の最大実行時間 (3.2 サーバー バージョンの場合) | 15 秒 |
| MongoDB 操作の最大実行時間 (3.6 および 4.0 サーバー バージョンの場合) | 60 秒 |
| インデックス定義の埋め込みオブジェクトまたは配列の入れ子の最大レベル | 6 |
| サーバー側の接続を終了するためのアイドル状態の接続のタイムアウト ² | 30 分 |
| Azure portal での MongoDB シェルに関する時間制限 | 24 時間で 120 分 |
¹ 最大 16 MB の大きなドキュメント サイズでは、Azure portal で機能を有効にする必要があります。 詳細については、 機能のドキュメント を参照してください。
² クライアント アプリケーションではドライバー設定内のアイドル状態の接続のタイムアウトを 2 から 3 分に設定することをお勧めします。これは、Azure LoadBalancer の既定のタイムアウトが 4 分であるためです。 このタイムアウトにより、中間ロード バランサーがアイドル状態でも、クライアント マシンと Azure Cosmos DB 間の接続が閉じられなくなります。
Azure Cosmos DB の無料制限を試す
次の表は、Azure Cosmos DB 無料試用版の制限の一覧を示しています。
| リソース | 制限 |
|---|---|
| 試用版の期間 | 30 日 (期限が切れた後は、新しい試用版を要求できます) 有効期限が切れると、格納されている情報は削除されます。 |
| サブスクリプションあたりの最大コンテナー数 (NoSQL、Gremlin、Table 用 API) | 1 |
| サブスクリプションあたりの最大コンテナー (MongoDB 用 API) | 3 |
| コンテナーあたりの最大スループット | 5000 |
| 共有スループット データベースあたりの最大スループット | 20000 |
| アカウントあたりの最大合計ストレージ | 10 GB |
Azure Cosmos DB 試用版は、米国中部、北ヨーロッパ、および東南アジア リージョンでのみグローバル分散をサポートしています。 Azure Cosmos DB 試用版アカウントに対して Azure サポート チケットを作成することはできません。 ただし、既存のサポート プランを所有するサブスクライバーにはサポートが提供されます。
Azure Cosmos DB Free レベル アカウントの制限
次の表は、Azure Cosmos DB の Free レベルのアカウントに対する制限を一覧表示しています。
| リソース | 制限 |
|---|---|
| Azure サブスクリプションあたりの Free レベルのアカウント数 | 1 |
| Free レベル割引の期間 | アカウントの有効期間。 アカウントの作成時にオプトインする必要があります。 |
| Free の最大 RU/秒 | 1000 RU/秒 |
| Free の最大ストレージ | 25 GB |
| 共有スループット データベースの最大数 | 5 |
| 共有スループット データベース内のコンテナーの最大数 | 25 Free レベルのアカウントでは、最大 25 個のコンテナーを使用する共有スループット データベースの最小 RU/秒は 400 RU/秒です。 |
前の表に加えて、アカウントあたりの制限も、Free レベルのアカウントに適用されます。 詳細については、Free レベル アカウントの作成に関するの記事を参照してください。