Azure Cosmos DB と .NET のパフォーマンスに関するヒントPerformance tips for Azure Cosmos DB and .NET

Azure Cosmos DB は、高速で柔軟性に優れた分散データベースです。待機時間とスループットが保証されており、シームレスにスケーリングできます。Azure Cosmos DB is a fast and flexible distributed database that scales seamlessly with guaranteed latency and throughput. Azure Cosmos DB でデータベースをスケーリングするために、アーキテクチャを大きく変更したり、複雑なコードを記述したりする必要はありません。You do not have to make major architecture changes or write complex code to scale your database with Azure Cosmos DB. スケールアップとスケールダウンは、API 呼び出しを 1 回行うだけの簡単なものです。Scaling up and down is as easy as making a single API call. 詳細については、コンテナーのスループットをプロビジョニングする方法またはデータベースのスループットをプロビジョニングする方法に関するページを参照してください。To learn more, see how to provision container throughput or how to provision database throughput. ただし、Azure Cosmos DB にはネットワーク呼び出しによってアクセスするため、SQL .NET SDK を使うと、最高のパフォーマンスを実現するためにクライアント側の最適化を行うことができます。However, because Azure Cosmos DB is accessed via network calls there are client-side optimizations you can make to achieve peak performance when using the SQL .NET SDK.

データベースのパフォーマンスを向上させる場合は、So if you're asking "How can I improve my database performance?" 以下のオプションを検討してください。consider the following options:

ネットワークNetworking

  1. 接続ポリシー:直接接続モードを使用するConnection policy: Use direct connection mode

    クライアントが Azure Cosmos DB に接続する方法は、特に監視対象となるクライアント側の待機時間の観点から、パフォーマンスに重要な影響を及ぼします。How a client connects to Azure Cosmos DB has important implications on performance, especially in terms of observed client-side latency. クライアントの接続ポリシーを構成する際に使用できる 2 つの主要な構成設定として、接続 "モード" と接続 "プロトコル" があります。There are two key configuration settings available for configuring client Connection Policy – the connection mode and the connection protocol. 次の 2 つのモードが用意されています。The two available modes are:

    • ゲートウェイ モード (既定値)Gateway Mode (default)

      ゲートウェイ モードは構成済みの既定のモードであり、すべての SDK プラットフォームでサポートされています。Gateway Mode is supported on all SDK platforms and is the configured default. ゲートウェイ モードでは標準の HTTPS ポートと単一のエンドポイントを使用するため、ファイアウォールの厳しい制限がある企業ネットワーク内でアプリケーションを実行する場合は、ゲートウェイ モードが最適な選択肢です。If your application runs within a corporate network with strict firewall restrictions, Gateway Mode is the best choice since it uses the standard HTTPS port and a single endpoint. ただし、パフォーマンスのトレードオフとして、Gateway モードでは、Azure Cosmos DB に対してデータの読み取りまたは書き込みを行うたびに、追加のネットワーク ホップが必要になります。The performance tradeoff, however, is that Gateway Mode involves an additional network hop every time data is read or written to Azure Cosmos DB. そのため、ネットワーク ホップ数が少ない直接モードの方がパフォーマンスが向上します。Because of this, Direct Mode offers better performance due to fewer network hops. Azure Functions や従量課金プランを使用する場合など、ソケット接続の数に制限がある環境でアプリケーションを実行する場合、Gateway 接続モードも推奨されます。Gateway connection mode is also recommended when you run applications in environments with limited number of socket connections, for example when using Azure Functions or if you are on a consumption plan.

    • 直接モードDirect Mode

      直接モードは、TCP および HTTPS プロトコル経由の接続をサポートします。Direct mode supports connectivity through TCP and HTTPS protocols. .NET SDK の最新バージョンを使用している場合は、.NET Standard 2.0 と .NET Framework で直接接続モードがサポートされます。If you are using the latest version of .NET SDK, direct connectivity mode is supported in .NET Standard 2.0 and .NET framework. 直接モードを利用するときは、次の 2 つのプロトコル オプションがあります。When using Direct Mode, there are two protocol options available:

      • TCPTCP
      • HTTPSHTTPS

      ゲートウェイ モードを使用している場合、Cosmos DB はポート 443 を使用し、MongoDB 用の Azure Cosmos DB の API を使用している場合はポート 10250、10255、および 10256 を使用します。When using Gateway mode, Cosmos DB uses port 443 and ports 10250, 10255 and 10256 when using Azure Cosmos DB's API for MongoDB. 10250 ポートは geo レプリケーションなしで既定の MongoDB インスタンスにマップされ、10255/10256 ポートは geo レプリケーション機能付きで MongoDB インスタンスにマップされます。The 10250 port maps to a default MongoDB instance without geo-replication and 10255/10256 ports map to the MongoDB instance with geo-replication functionality. 直接モードで TCP を使用する場合は、Azure Cosmos DB が動的 TCP ポートを使用するため、ゲートウェイ ポートに加えてポート範囲 10000 ~ 20000 を開いておく必要があります。When using TCP in Direct Mode, in addition to the Gateway ports, you need to ensure the port range between 10000 and 20000 is open because Azure Cosmos DB uses dynamic TCP ports. これらのポートが開いていない場合に TCP を使用しようとすると、[503 サービスを利用できません] エラーが表示されます。If these ports are not open and you attempt to use TCP, you receive a 503 Service Unavailable error. 次の表は、さまざまな API で使用可能な接続モードと、各 API のサービス ポート ユーザーを示しています。The following table shows connectivity modes available for different APIs and the service ports user for each API:

      接続モードConnection mode サポートされるプロトコルSupported protocol サポートされる SDKSupported SDKs API/サービス ポートAPI/Service port
      GatewayGateway HTTPSHTTPS すべての SDKAll SDKS SQL (443)、Mongo (10250、10255、10256)、Table (443)、Cassandra (10350)、Graph (443)SQL(443), Mongo(10250, 10255, 10256), Table(443), Cassandra(10350), Graph(443)
      直接Direct HTTPSHTTPS .NET と Java SDK.NET and Java SDK 10,000 ~ 20,000 の範囲内のポートPorts within 10,000-20,000 range
      直接Direct TCPTCP .NET SDK.NET SDK 10,000 ~ 20,000 の範囲内のポートPorts within 10,000-20,000 range

      Azure Cosmos DB は、HTTPS を介したシンプルなオープン RESTful プログラミング モデルを提供します。Azure Cosmos DB offers a simple and open RESTful programming model over HTTPS. さらに、RESTful な通信モデルである効率的な TCP プロトコルも用意されており、.NET クライアント SDK を通じて使用できます。Additionally, it offers an efficient TCP protocol, which is also RESTful in its communication model and is available through the .NET client SDK. Direct TCP と HTTPS は、どちらも最初の認証とトラフィックの暗号化で SSL を使用します。Both Direct TCP and HTTPS use SSL for initial authentication and encrypting traffic. 最適なパフォーマンスを実現するために、可能であれば TCP プロトコルを使用します。For best performance, use the TCP protocol when possible.

      接続モードは、ConnectionPolicy パラメーターを使用して DocumentClient インスタンスの作成時に構成されます。The Connectivity Mode is configured during the construction of the DocumentClient instance with the ConnectionPolicy parameter. 直接モードを使用する場合、ConnectionPolicy パラメーター内でプロトコルも設定できます。If Direct Mode is used, the Protocol can also be set within the ConnectionPolicy parameter.

      var serviceEndpoint = new Uri("https://contoso.documents.net");
      var authKey = "your authKey from the Azure portal";
      DocumentClient client = new DocumentClient(serviceEndpoint, authKey,
      new ConnectionPolicy
      {
         ConnectionMode = ConnectionMode.Direct,
         ConnectionProtocol = Protocol.Tcp
      });
      

      TCP は直接モードでのみサポートされるため、ゲートウェイ モードを使用する場合は、ゲートウェイとの通信に HTTPS プロトコルが常に使用され、ConnectionPolicy の Protocol 値は無視されます。Because TCP is only supported in Direct Mode, if Gateway Mode is used, then the HTTPS protocol is always used to communicate with the Gateway and the Protocol value in the ConnectionPolicy is ignored.

      Azure Cosmos DB 接続ポリシーの図

  2. OpenAsync を呼び出して最初の要求での開始時の待機時間を回避するCall OpenAsync to avoid startup latency on first request

    既定では、最初の要求でアドレス ルーティング テーブルを取得する必要があるため、最初の要求の待機時間が長くなります。By default, the first request has a higher latency because it has to fetch the address routing table. 最初の要求でこの開始時の待機時間を回避するには、次のように初期化中に OpenAsync() を 1 回呼び出します。To avoid this startup latency on the first request, you should call OpenAsync() once during initialization as follows.

     await client.OpenAsync();
    

  3. パフォーマンスを確保するために同じ Azure リージョン内にクライアントを併置するCollocate clients in same Azure region for performance

    可能であれば、Azure Cosmos DB を呼び出すアプリケーションを Azure Cosmos DB データベースと同じリージョンに配置します。When possible, place any applications calling Azure Cosmos DB in the same region as the Azure Cosmos DB database. 大ざっぱな比較ですが、Azure Cosmos DB の呼び出しは、同じリージョン内であれば 1 ~ 2 ミリ秒以内で完了するのに対し、米国西部と米国東部との間では待ち時間が 50 ミリ秒を超えます。For an approximate comparison, calls to Azure Cosmos DB within the same region complete within 1-2 ms, but the latency between the West and East coast of the US is >50 ms. 要求がクライアントから Azure データセンターの境界まで流れるときに使用されるルートに応じて、この待機時間が要求ごとに異なる可能性があります。This latency can likely vary from request to request depending on the route taken by the request as it passes from the client to the Azure datacenter boundary. 最短の待機時間は、プロビジョニングされた Azure Cosmos DB エンドポイントと同じ Azure リージョン内に呼び出し元アプリケーションを配置することによって実現されます。The lowest possible latency is achieved by ensuring the calling application is located within the same Azure region as the provisioned Azure Cosmos DB endpoint. 使用可能なリージョンの一覧については、「 Azure のリージョン」を参照してください。For a list of available regions, see Azure Regions.

    Azure Cosmos DB 接続ポリシーの図 Illustration of the Azure Cosmos DB connection policy

  4. スレッド/タスクの数を増やすIncrease number of threads/tasks

    Azure Cosmos DB の呼び出しはネットワーク経由で行われるため、クライアント アプリケーションで要求間の待機時間をできるだけ短くするために、要求の並列処理の次数を変えることが必要な場合があります。Since calls to Azure Cosmos DB are made over the network, you may need to vary the degree of parallelism of your requests so that the client application spends very little time waiting between requests. たとえば、.NET の タスク並列ライブラリを使用する場合、Azure Cosmos DB に対する読み取りタスクまたは書き込みタスクを 100 件単位で作成してください。For example, if you're using .NET's Task Parallel Library, create in the order of 100s of Tasks reading or writing to Azure Cosmos DB.

  5. 高速ネットワークの有効化Enable accelerated networking

    待機時間と CPU ジッターを減らすために、クライアントの仮想マシンでは高速ネットワークを有効にしておくことをお勧めします。In order to reduce latency and CPU jitter, we recommend that the client virtual machines are accelerated networking enabled. 高速ネットワークを有効にするには、「高速ネットワークを使った Windows 仮想マシンの作成」または「高速ネットワークを使った Linux 仮想マシンの作成」の記事をご覧ください。See the Create a Windows virtual machine with Accelerated Networking or Create a Linux virtual machine with Accelerated Networking articles to enable accelerated networking.

SDK の使用例SDK Usage

  1. 最新の SDK をインストールするInstall the most recent SDK

    Azure Cosmos DB SDK は、最適なパフォーマンスを提供するために頻繁に改善されています。The Azure Cosmos DB SDKs are constantly being improved to provide the best performance. Azure Cosmos DB SDK のページを参照して、最新の SDK を確認し、改善点を確認してください。See the Azure Cosmos DB SDK pages to determine the most recent SDK and review improvements.

  2. アプリケーションの有効期間中はシングルトン Azure Cosmos DB クライアントを使用するUse a singleton Azure Cosmos DB client for the lifetime of your application

    各 DocumentClient インスタンスはスレッド セーフであり、直接モードで動作しているときには効率的な接続管理とアドレスのキャッシュが実行されます。Each DocumentClient instance is thread-safe and performs efficient connection management and address caching when operating in Direct Mode. DocumentClient による効率的な接続管理とパフォーマンスの向上を実現するために、アプリケーションの有効期間中は、AppDomain ごとに DocumentClient の単一のインスタンスを使用することをお勧めします。To allow efficient connection management and better performance by DocumentClient, it is recommended to use a single instance of DocumentClient per AppDomain for the lifetime of the application.

  3. ゲートウェイ モードを使用するときはホストあたりの System.Net MaxConnections を増やすIncrease System.Net MaxConnections per host when using Gateway mode

    Gateway モードを使用するときは Azure Cosmos DB の要求は HTTPS/REST を介して行われ、ホスト名または IP アドレスごとの既定の接続数の制限の対象となります。Azure Cosmos DB requests are made over HTTPS/REST when using Gateway mode, and are subjected to the default connection limit per hostname or IP address. 場合によっては、Azure Cosmos DB に対する複数の同時接続をクライアント ライブラリが活かすためには、MaxConnections を 100 ~ 1000 に増やす必要があります。You may need to set the MaxConnections to a higher value (100-1000) so that the client library can utilize multiple simultaneous connections to Azure Cosmos DB. .NET SDK 1.8.0 以降では、ServicePointManager.DefaultConnectionLimit の既定値は 50 です。この値を変更するには、Documents.Client.ConnectionPolicy.MaxConnectionLimit をより大きな値に設定します。In the .NET SDK 1.8.0 and above, the default value for ServicePointManager.DefaultConnectionLimit is 50 and to change the value, you can set the Documents.Client.ConnectionPolicy.MaxConnectionLimit to a higher value.

  4. パーティション分割コレクションに対する並列クエリを調整するTuning parallel queries for partitioned collections

    SQL .NET SDK Version 1.9.0 以降では、並列クエリがサポートされています。この機能を使用すると、パーティション分割コレクションにクエリを並列的に実行できます。SQL .NET SDK version 1.9.0 and above support parallel queries, which enable you to query a partitioned collection in parallel. 詳細については、SDK の操作に関連したコード サンプルを参照してください。For more information, see code samples related to working with the SDKs. 並列クエリは、シリアル クエリよりもクエリの待機時間とスループットを向上させるように設計されています。Parallel queries are designed to improve query latency and throughput over their serial counterpart. 並列クエリには、ユーザーが要件に合わせて調整できる 2 つのパラメーターが用意されています。(a) MaxDegreeOfParallelism は、並列でクエリを実行できるパーティションの最大数を制御します。(b) MaxBufferedItemCount は、プリフェッチされる結果の数を制御します。Parallel queries provide two parameters that users can tune to custom-fit their requirements, (a) MaxDegreeOfParallelism: to control the maximum number of partitions then can be queried in parallel, and (b) MaxBufferedItemCount: to control the number of pre-fetched results.

    (a) "MaxDegreeOfParallelism の調整:" 並列クエリは、複数のパーティションに並列にクエリを実行することによって機能します。(a) Tuning MaxDegreeOfParallelism: Parallel query works by querying multiple partitions in parallel. ただし、個々のパーティション分割されたコレクションからのデータは、クエリごとに順番に取得されます。However, data from an individual partitioned collect is fetched serially with respect to the query. そのため、MaxDegreeOfParallelism をパーティションの数に設定すると、その他のすべてのシステムの条件が変わらなければ、クエリのパフォーマンスを最大にできる可能性が最大になります。So, setting the MaxDegreeOfParallelism to the number of partitions has the maximum chance of achieving the most performant query, provided all other system conditions remain the same. パーティションの数が不明な場合は、MaxDegreeOfParallelism に大きな数を設定できます。システムが最小値 (パーティションの数、ユーザー指定の入力) を MaxDegreeOfParallelism として選択します。If you don't know the number of partitions, you can set the MaxDegreeOfParallelism to a high number, and the system chooses the minimum (number of partitions, user provided input) as the MaxDegreeOfParallelism.

    並列クエリが最も有効に機能するのは、クエリに対するデータがすべてのパーティションに均等に分散している場合であることに注意する必要があります。It is important to note that parallel queries produce the best benefits if the data is evenly distributed across all partitions with respect to the query. パーティション分割されたコレクションが、クエリによって返されるすべてまたは大部分のデータがわずかな数のパーティション (最悪の場合は 1 つのパーティション) に集中するように分割されている場合、クエリのパフォーマンスに関してこれらのパーティションがボトルネックになるでしょう。If the partitioned collection is partitioned such a way that all or a majority of the data returned by a query is concentrated in a few partitions (one partition in worst case), then the performance of the query would be bottlenecked by those partitions.

    (b) "MaxBufferedItemCount の調整:" 並列クエリは、結果の現在のバッチがクライアントによって処理されている間に結果をプリフェッチするように設計されています。(b) Tuning MaxBufferedItemCount: Parallel query is designed to pre-fetch results while the current batch of results is being processed by the client. プリフェッチは、クエリの全体的な遅延の削減に役立ちます。The pre-fetching helps in overall latency improvement of a query. MaxBufferedItemCount は、プリフェッチされる結果の量を制限するパラメーターです。MaxBufferedItemCount is the parameter to limit the number of pre-fetched results. MaxBufferedItemCount を、返される結果の予期される数 (またはそれ以上の数) に設定すると、クエリに対するプリフェッチの効果が最大になります。Setting MaxBufferedItemCount to the expected number of results returned (or a higher number) allows the query to receive maximum benefit from pre-fetching.

    プリフェッチは MaxDegreeOfParallelism とは無関係に同じように動作し、すべてのパーティションからのデータに対して単一のバッファーが存在します。Pre-fetching works the same way irrespective of the MaxDegreeOfParallelism, and there is a single buffer for the data from all partitions.

  5. サーバー側の GC を有効にするTurn on server-side GC

    ガベージ コレクションの頻度を減らした方がよい場合もあります。Reducing the frequency of garbage collection may help in some cases. .NET では、 gcServer を true に設定します。In .NET, set gcServer to true.

  6. RetryAfter 間隔でバックオフを実装するImplement backoff at RetryAfter intervals

    パフォーマンス テストでは、調整される要求の割合がわずかになるまで負荷を上げる必要があります。During performance testing, you should increase load until a small rate of requests get throttled. スロットル状態になった場合、クライアント アプリケーション側でバックオフ値を適用し、サーバー側によって指定された再試行間隔のスロットル時間を後退させるようにしてください。If throttled, the client application should backoff on throttle for the server-specified retry interval. バックオフにより、再試行までの待ち時間を最小限に抑えることができます。Respecting the backoff ensures that you spend minimal amount of time waiting between retries. 再試行ポリシーは、SQL .NET および Java のバージョン 1.8.0 以降、Node.js および Python のバージョン 1.9.0 以降、および .NET Core SDK のサポートされているすべてのバージョンでサポートされています。Retry policy support is included in Version 1.8.0 and above of the SQL .NET and Java, version 1.9.0 and above of the Node.js and Python, and all supported versions of the .NET Core SDKs. 詳細については、RetryAfter に関するページを参照してください。For more information, RetryAfter.

    .NET SDK のバージョン 1.19 以降では、次の例のように、追加の診断情報をログに記録し、待ち時間に関する問題をトラブルシューティングするメカニズムがあります。With version 1.19 and later of the .NET SDK, there is a mechanism to log additional diagnostic information and troubleshoot latency issues as shown in the following sample. 読み取り待ち時間の長い要求についての診断文字列をログに記録できます。You can log the diagnostic string for requests that have a higher read latency. 取得した診断文字列は、特定の要求に対して 429 が確認された回数を把握するのに役立ちます。The captured diagnostic string will help you understand the number of times you observed 429s for a given request.

    ResourceResponse<Document> readDocument = await this.readClient.ReadDocumentAsync(oldDocuments[i].SelfLink);
    readDocument.RequestDiagnosticsString 
    
  7. クライアント ワークロードをスケールアウトするScale out your client-workload

    高スループット レベル (1 秒あたりの要求ユニット数が 50,000 超) でテストを行っている場合、コンピューターが CPU 使用率またはネットワーク使用率の上限に達したことでクライアント アプリケーションがボトルネックになることがあります。If you are testing at high throughput levels (>50,000 RU/s), the client application may become the bottleneck due to the machine capping out on CPU or Network utilization. この状態に達しても、クライアント アプリケーションを複数のサーバーにスケールアウトすることで引き続き同じ Azure Cosmos DB アカウントで対応できます。If you reach this point, you can continue to push the Azure Cosmos DB account further by scaling out your client applications across multiple servers.

  8. ドキュメント URI をキャッシュして読み取り待機時間を減らすCache document URIs for lower read latency

    最適な読み取りパフォーマンスを実現するために、できる限りドキュメント URI をキャッシュします。Cache document URIs whenever possible for the best read performance. リソースを作成するときに resourceid をキャッシュするロジックを定義する必要があります。You have to define logic to cache the resourceid when you create the resource. Resourceid ベースの参照は名前ベースの参照よりも高速であるため、これらの値をキャッシュすると、パフォーマンスが向上します。Resourceid based lookups are faster than name based lookups, so caching these values improves the performance.

  9. パフォーマンスを向上させるために、クエリ/読み取りフィードのページ サイズを調整するTune the page size for queries/read feeds for better performance

    読み取りフィード機能 (ReadDocumentFeedAsync など) を使用してドキュメントの一括読み取りを実行したときや、SQL クエリを発行したときに、結果セットが大きすぎる場合、セグメント化された形式で結果が返されます。When performing a bulk read of documents using read feed functionality (for example, ReadDocumentFeedAsync) or when issuing a SQL query, the results are returned in a segmented fashion if the result set is too large. 既定では、100 項目または 1 MB (先に達した方) のチャンク単位で結果が返されます。By default, results are returned in chunks of 100 items or 1 MB, whichever limit is hit first.

    該当するすべての結果を取得するために必要なネットワーク ラウンド トリップの回数を減らすために、x-ms-max-item-count 要求ヘッダーを使用して、ページ サイズを最大 1,000 まで増やすことができます。To reduce the number of network round trips required to retrieve all applicable results, you can increase the page size using x-ms-max-item-count request header to up to 1000. ごく少数の結果のみを表示する必要がある場合は (ユーザー インターフェイスやアプリケーション API が一度に 10 件しか結果を返さない場合など)、読み取りとクエリに使用されるスループットを減らすために、ページ サイズを 10 に減らすこともできます。In cases where you need to display only a few results, for example, if your user interface or application API returns only 10 results a time, you can also decrease the page size to 10 to reduce the throughput consumed for reads and queries.

    注意

    maxItemCount プロパティは、改ページ位置の自動修正の目的にのみ使用しないでください。The maxItemCount property shouldn't be used just for pagination purpose. 主な用途は、1 ページに返される項目の最大数を減らすことで、クエリのパフォーマンスを向上させることです。It's main usage it to improve the performance of queries by reducing the maximum number of items returned in a single page.

    また、使用可能な Azure Cosmos DB SDK を使用してページ サイズを設定することもできます。You can also set the page size using the available Azure Cosmos DB SDKs. FeedOptions の MaxItemCount プロパティでは、列挙操作で返される項目の最大数を設定できます。The MaxItemCount property in FeedOptions allows you to set the maximum number of items to be returned in the enmuration operation. maxItemCount が-1 に設定されている場合、ドキュメント サイズに応じて最適な値が SDK によって自動的に見つけられます。When maxItemCount is set to -1, the SDK automatically finds the most optimal value depending on the document size. 例:For example:

     IQueryable<dynamic> authorResults = client.CreateDocumentQuery(documentCollection.SelfLink, "SELECT p.Author FROM Pages p WHERE p.Title = 'About Seattle'", new FeedOptions { MaxItemCount = 1000 });
    

    クエリが実行されると、結果のデータは TCP パケット内で送信されます。When a query is executed, the resulting data is sent within a TCP packet. maxItemCount に指定した値が小さすぎると、TCP パケット内でデータを送信するために必要なトリップ数が多くなり、パフォーマンスに影響します。If you specify too low value for maxItemCount, the number of trips required to send the data within the TCP packet are high, which impacts the performance. そのため、maxItemCount プロパティに設定する値がわからない場合は、-1 に設定して SDK で自動的に既定値を選択することをお勧めします。So if you are not sure what value to set for maxItemCount property, it's best to set it to -1 and let the SDK choose the default value.

  10. スレッド/タスクの数を増やすIncrease number of threads/tasks

    「ネットワーク」の「スレッド/タスクの数を増やす」を参照してください。See Increase number of threads/tasks in the Networking section.

  11. 64 ビット ホスト プロセスを使用するUse 64-bit host processing

    SQL SDK は、SQL .NET SDK バージョン 1.11.4 以降を使用している場合に、32 ビット ホスト プロセスで動作します。The SQL SDK works in a 32-bit host process when you are using SQL .NET SDK version 1.11.4 and above. ただし、クロス パーティション クエリを使用する場合は、パフォーマンス向上のために 64 ビット ホスト プロセスを使用することをお勧めします。However, if you are using cross partition queries, 64-bit host processing is recommended for improved performance. 次の種類のアプリケーションでは 32 ビット ホスト プロセスが既定で使用されるため、64 ビットに変更するには、アプリケーションの種類に基づいて次の手順に従ってください。The following types of applications have 32-bit host process as the default, so in order to change that to 64-bit, follow these steps based on the type of your application:

    • 実行可能なアプリケーションの場合、これは [ビルド] タブの [プロジェクトのプロパティ] ウィンドウで [32 ビットを優先] オプションをオフにすることで実行できます。For Executable applications, this can be done by unchecking the Prefer 32-bit option in the Project Properties window, on the Build tab.

    • VSTest ベースのテスト プロジェクトの場合、Visual Studio テスト メニュー オプションから [テスト] -> [テストの設定] -> [Default Processor Architecture as X64 (X64 としての既定のプロセッサ アーキテクチャ)] の順に選択することで実行できます。For VSTest based test projects, this can be done by selecting Test->Test Settings->Default Processor Architecture as X64, from the Visual Studio Test menu option.

    • ローカルでデプロイされた ASP.NET Web アプリケーションの場合、 [ツール] -> [オプション] -> [プロジェクトおよびソリューション] -> [Web プロジェクト] の順に選択して、 [Web サイトおよびプロジェクト用 IIS Express の 64 ビット バージョンを使用する] をチェックすることで実行できます。For locally deployed ASP.NET Web applications, this can be done by checking the Use the 64-bit version of IIS Express for web sites and projects, under Tools->Options->Projects and Solutions->Web Projects.

    • Azure にデプロイされた ASP.NET Web アプリケーションの場合、Azure Portal の [アプリケーションの設定] で、 [Platform as 64-bit (64 ビットとしてのプラットフォーム)] を選択することで実行できます。For ASP.NET Web applications deployed on Azure, this can be done by choosing the Platform as 64-bit in the Application Settings on the Azure portal.

インデックス作成ポリシーIndexing Policy

  1. インデックス作成から未使用のパスを除外して書き込みを高速化するExclude unused paths from indexing for faster writes

    Cosmos DB のインデックス作成ポリシーでは、パスのインデックス作成 (IndexingPolicy.IncludedPaths および IndexingPolicy.ExcludedPaths) を使用して、インデックス作成に含める/除外するドキュメント パスを指定できます。Cosmos DB’s indexing policy also allows you to specify which document paths to include or exclude from indexing by leveraging Indexing Paths (IndexingPolicy.IncludedPaths and IndexingPolicy.ExcludedPaths). インデックス作成コストはインデックス付きの一意のパスの数に直接関係するため、パスのインデックス作成を使用すると、クエリ パターンが事前にわかっているシナリオで書き込みパフォーマンスが向上し、インデックス ストレージを削減できます。The use of indexing paths can offer improved write performance and lower index storage for scenarios in which the query patterns are known beforehand, as indexing costs are directly correlated to the number of unique paths indexed. たとえば、次のコードは、ワイルドカード "*" を使用して、ドキュメントのセクション全体 (サブツリー) をインデックス作成から除外する方法を示しています。For example, the following code shows how to exclude an entire section of the documents (a subtree) from indexing using the "*" wildcard.

    var collection = new DocumentCollection { Id = "excludedPathCollection" };
    collection.IndexingPolicy.IncludedPaths.Add(new IncludedPath { Path = "/*" });
    collection.IndexingPolicy.ExcludedPaths.Add(new ExcludedPath { Path = "/nonIndexedContent/*");
    collection = await client.CreateDocumentCollectionAsync(UriFactory.CreateDatabaseUri("db"), excluded);
    

    詳細については、Azure Cosmos DB インデックス作成ポリシーに関するページをご覧ください。For more information, see Azure Cosmos DB indexing policies.

スループットThroughput

  1. 測定と調整によって 1 秒あたりの要求ユニットの使用量を削減するMeasure and tune for lower request units/second usage

    Azure Cosmos DB には、UDF、ストアド プロシージャ、トリガーを使ったリレーショナル クエリや階層クエリなど、さまざまなデータベース操作が用意されています。これらの操作はすべて、データベース コレクション内のドキュメントに対して実行できます。Azure Cosmos DB offers a rich set of database operations including relational and hierarchical queries with UDFs, stored procedures, and triggers – all operating on the documents within a database collection. これらの操作のそれぞれに関連付けられたコストは、操作を完了するために必要な CPU、IO、およびメモリに応じて異なります。The cost associated with each of these operations varies based on the CPU, IO, and memory required to complete the operation. ハードウェア リソースの管理について考える代わりに、各種のデータベース操作を実行しアプリケーション要求を処理するのに必要なリソースに関する単一の測定単位として要求単位 (RU) を考えることができます。Instead of thinking about and managing hardware resources, you can think of a request unit (RU) as a single measure for the resources required to perform various database operations and service an application request.

    コンテナーごとに設定された要求ユニットの数に基づいて、スループットをプロビジョニングします。Throughput is provisioned based on the number of request units set for each container. 要求単位の消費は、1 秒あたりのレートとして評価されます。Request unit consumption is evaluated as a rate per second. コンテナーのプロビジョニング済み要求ユニット レートを超過したアプリケーションは、レートがそのコンテナーにプロビジョニングされているレベルを下回るまで制限されます。Applications that exceed the provisioned request unit rate for their container are limited until the rate drops below the provisioned level for the container. アプリケーションでより高いスループットが必要になった場合は、追加の要求ユニットをプロビジョニングしてスループットを増やすことができます。If your application requires a higher level of throughput, you can increase your throughput by provisioning additional request units.

    クエリの複雑さは、操作で消費される要求ユニット数に影響します。The complexity of a query impacts how many Request Units are consumed for an operation. 述語の数、述語の特性、UDF 数、ソース データ セットのサイズのすべてがクエリ操作のコストに影響します。The number of predicates, nature of the predicates, number of UDFs, and the size of the source data set all influence the cost of query operations.

    操作 (作成、更新、または削除) のオーバーヘッドを測定するには、x-ms-request-charge ヘッダー (あるいは、.NET SDK の ResourceResponse または FeedResponse の同等の RequestCharge プロパティ) を調べて、これらの操作で使用される要求ユニット数を測定します。To measure the overhead of any operation (create, update, or delete), inspect the x-ms-request-charge header (or the equivalent RequestCharge property in ResourceResponse or FeedResponse in the .NET SDK) to measure the number of request units consumed by these operations.

    // Measure the performance (request units) of writes
    ResourceResponse<Document> response = await client.CreateDocumentAsync(collectionSelfLink, myDocument);
    Console.WriteLine("Insert of document consumed {0} request units", response.RequestCharge);
    // Measure the performance (request units) of queries
    IDocumentQuery<dynamic> queryable = client.CreateDocumentQuery(collectionSelfLink, queryString).AsDocumentQuery();
    while (queryable.HasMoreResults)
         {
              FeedResponse<dynamic> queryResponse = await queryable.ExecuteNextAsync<dynamic>();
              Console.WriteLine("Query batch consumed {0} request units", queryResponse.RequestCharge);
         }
    

    このヘッダーで返される要求の使用量は、プロビジョニングしたスループット (2000 RU/秒) の一部です。The request charge returned in this header is a fraction of your provisioned throughput (i.e., 2000 RUs / second). たとえば、上記のクエリが 1 KB のドキュメントを 1000 個返した場合、この操作のコストは 1000 になります。For example, if the preceding query returns 1000 1KB-documents, the cost of the operation is 1000. そのため、後続の要求をレート制限する前に、サーバーは 1 秒以内にこのような要求を 2 つだけ受け付けます。As such, within one second, the server honors only two such requests before rate limiting subsequent requests. 詳細については、要求ユニットに関する記事および要求ユニット計算ツールのページを参照してください。For more information, see Request units and the request unit calculator.

  2. レート制限と大きすぎる要求レートに対処するHandle rate limiting/request rate too large

    クライアントがアカウントの予約済みスループットを超えようとしても、サーバーでパフォーマンスの低下が発生することはなく、予約済みのレベルを超えてスループット容量が使用されることもありません。When a client attempts to exceed the reserved throughput for an account, there is no performance degradation at the server and no use of throughput capacity beyond the reserved level. サーバーはいち早く RequestRateTooLarge (HTTP 状態コード 429) で要求を終了させ、要求を再試行するまでにユーザーが待機しなければならない時間 (ミリ秒) を示す x-ms-retry-after-ms ヘッダーを返します。The server will preemptively end the request with RequestRateTooLarge (HTTP status code 429) and return the x-ms-retry-after-ms header indicating the amount of time, in milliseconds, that the user must wait before reattempting the request.

     HTTP Status 429,
     Status Line: RequestRateTooLarge
     x-ms-retry-after-ms :100
    

    SDK はすべてこの応答を暗黙的にキャッチし、サーバーが指定した retry-after ヘッダーを優先して要求を再試行します。The SDKs all implicitly catch this response, respect the server-specified retry-after header, and retry the request. アカウントに複数のクライアントが同時アクセスしている状況でなければ、次回の再試行は成功します。Unless your account is being accessed concurrently by multiple clients, the next retry will succeed.

    複数のクライアントが要求レートを常に上回った状態で累積的に動作している場合、現在クライアントによって内部的に 9 に設定されている既定の再試行回数では不十分な可能性があります。この場合、クライアントは状態コード 429 を含む DocumentClientException をアプリケーションにスローします。If you have more than one client cumulatively operating consistently above the request rate, the default retry count currently set to 9 internally by the client may not suffice; in this case, the client throws a DocumentClientException with status code 429 to the application. 既定の再試行回数は、ConnectionPolicy インスタンスで RetryOptions を設定することで変更できます。The default retry count can be changed by setting the RetryOptions on the ConnectionPolicy instance. 既定では、要求レートを超えて要求が続行されている場合に、30 秒の累積待機時間を過ぎると、状態コード 429 を含む DocumentClientException が返されます。By default, the DocumentClientException with status code 429 is returned after a cumulative wait time of 30 seconds if the request continues to operate above the request rate. これは、現在の再試行回数が最大再試行回数 (既定値の 9 またはユーザー定義の値) より少ない場合でも発生します。This occurs even when the current retry count is less than the max retry count, be it the default of 9 or a user-defined value.

    自動再試行動作により、ほとんどのアプリケーションの回復性とユーザービリティが向上しますが、パフォーマンス ベンチマークの実行時 (特に待機時間の測定時) に問題が生じることがあります。While the automated retry behavior helps to improve resiliency and usability for the most applications, it might come at odds when doing performance benchmarks, especially when measuring latency. 実験でサーバー スロットルが発生し、クライアント SDK によって警告なしに再試行が行われると、クライアントが監視する待機時間が急増します。The client-observed latency will spike if the experiment hits the server throttle and causes the client SDK to silently retry. パフォーマンスの実験中に待機時間が急増するのを回避するには、各操作で返される使用量を測定し、予約済みの要求レートを下回った状態で要求が行われていることを確認します。To avoid latency spikes during performance experiments, measure the charge returned by each operation and ensure that requests are operating below the reserved request rate. 詳細については、 要求ユニットに関する記事を参照してください。For more information, see Request units.

  3. スループットを向上させるためにサイズの小さいドキュメントに合わせて設計するDesign for smaller documents for higher throughput

    特定の操作の要求の使用量 (要求処理コスト) は、ドキュメントのサイズに直接関係します。The request charge (i.e. request processing cost) of a given operation is directly correlated to the size of the document. サイズの大きいドキュメントの操作は、サイズの小さいドキュメントの操作よりもコストがかかります。Operations on large documents cost more than operations for small documents.

次の手順Next steps

少数のクライアント コンピューターでの高パフォーマンス シナリオで Azure Cosmos DB の評価に使用するサンプル アプリケーションについては、Azure Cosmos DB のパフォーマンスとスケールのテストに関するページを参照してください。For a sample application used to evaluate Azure Cosmos DB for high-performance scenarios on a few client machines, see Performance and scale testing with Azure Cosmos DB.

また、スケーリングと高パフォーマンスのためのアプリケーションの設計の詳細については、Azure Cosmos DB でのパーティション分割とスケーリングに関するページをご覧ください。Also, to learn more about designing your application for scale and high performance, see Partitioning and scaling in Azure Cosmos DB.