Dataverse で数千または数百万のレコードを作成または更新する必要がある場合は、一括操作プロジェクトが完了するまでの時間を節約できます。 この記事では、パフォーマンスに影響する要因と、一括操作のパフォーマンスを最適化するクライアント アプリケーションを構築するために必要なオプションについて説明します。 レコードの数、レコード サイズ、ネットワーク待機時間、データの複雑さなど、他の要因についても考慮する必要があります。
テーブルの種類
データを格納するために選択するテーブルの種類は、一括操作で予想できるスループットに最も大きな影響を与えます。 Dataverse には、 標準 と エラスティックの 2 種類のテーブルが用意されています。
- 標準テーブルには、Azure SQL を使用してデータが格納されます。 標準テーブルは、トランザクションをサポートし、リレーションシップをモデル化するためのより大きな機能を提供します。
- エラスティック テーブルには、Azure Cosmos DB を使用してデータが格納されます。 エラスティック テーブルは、待機時間が短い大量のデータと高レベルのスループットを処理するために、自動的に水平方向にスケーリングされます。 エラスティック テーブルは、予測不能、スパイク、または急速に増加するワークロードを持つアプリケーションに適しています。
データの読み込み時間が主な懸念事項である場合は、エラスティック テーブルが最適なパフォーマンスを提供します。 エラスティック テーブルを使用するタイミングについて説明します
ビジネス ロジック
Dataverse には、プラグインを使用してレコードが作成または更新されるときに、追加のビジネス ロジックを追加 する機能が用意されています。 プラグインは 、標準テーブル操作のトランザクションの前または内部 で同期的に 実行するように登録できます。 エラスティック テーブルは、トランザクションがないため、操作が開始される前に実行できるプラグインをサポートします。 標準テーブルの同期ステップ中、またはエラスティック テーブル内の操作の前にプラグイン コードで発生したエラーは、操作を取り消します。 プラグイン開発者は、意図的に例外をスローして操作をキャンセルし、データ検証ロジックが適用されるようにすることができます。
同期的に実行するように登録されているプラグインでは、操作が完了するまでの時間が長くなります。 パフォーマンスを維持するには:
- 操作に登録される同期プラグインの数を制限します。 ロジックを同期的に適用する必要がない限り、非同期プラグインまたは Power Automate フローを使用して非同期的に実行するロジックを追加します。
- 実行しようとしているロジックで、使用しているプラグインが制限されていることを確認します。 プラグインは十分な 2 分の時間制限内で完了する必要がありますが、実行時間が 2 秒を超える同期プラグインはパフォーマンスを著しく低下させます。
- プラグインは、必要な場合にのみ実行してください。 更新操作用のプラグインは、特定の列が更新された場合にのみ実行されるようにフィルター処理できます。
- 可能な限り効率的にロジックを実行するようにプラグインが最適化されていることを確認します。 標準テーブルの場合、トランザクションとレコード ロックがパフォーマンスに与える影響を考慮する必要があります。 プラグインを記述するためのスケーラブルなカスタマイズ設計とその他のベスト プラクティスについて説明します
- プラグインを登録する API を選択します。 同期ロジックを適用して、より効率的な
CreateMultipleおよびUpdateMultiple一括操作 API で実行できます。 CreateMultiple と UpdateMultiple のプラグインを記述する方法について説明します。
ビジネス ロジックをバイパスする
一括操作プロジェクトを迅速化するために、作成操作または更新操作に登録されているプラグインを無効にして、パフォーマンスを向上させることができます。 ビジネス ロジックが不可欠でない場合、または最終的なデータの整合性を確保するために他の手順を計画している場合は、プラグインの手順を手動で無効にし、一括操作プロジェクトが完了したときに再度有効にすることができます。 ただし、プラグインを無効にすると、 ロジックがクライアント から適用されなくなります。 この期間中に Dataverse にデータを追加するユーザーまたはその他のプロセスには、ビジネス ロジックは適用されません。
一括操作を実行するクライアント アプリケーションの開発者は、渡し渡しロジックに送信する要求に 省略可能なパラメーター を適用できます。 このヘッダーを使用できるのは、システム管理者、または特定の特権が付与されているユーザーだけです。 カスタム Dataverse ロジックをバイパスする方法について説明します。
一括操作 API
Dataverse には、作成操作と更新操作で可能な限り高いスループットを実現する 一括操作 API が 用意されています。 これらの API には、 CreateMultiple、 UpdateMultiple、および UpsertMultipleが含まれます。 エラスティック テーブルの場合のみ、 DeleteMultipleを使用できます。
これらの API は最高のスループットを提供しますが、標準テーブルには次の制限があります。
- 現在、すべてのテーブルで使用できるわけではありません。 カスタム テーブルではそれらをサポートする必要がありますが、アカウントや連絡先など、すべての主要な Dataverse テーブルでサポートされているわけではありません。 ドキュメントに記載されているクエリを実行して、テーブルでこれらの API を使用できるかどうかを判断できます。
- データ エラーを許さない。 変更するデータが慎重にスクラブされ、検証されていることを確認する必要があります。 これらの API の 1 つの操作内で発生したエラーが発生すると、操作全体が失敗します。
- プラグインでの使用はサポートされていません。 現時点では、これらの API は外部クライアント アプリケーションでのみ使用する必要があります。
一括操作はすべてのエラスティック テーブルで使用でき、エラスティック テーブルは失敗した個々の操作に関する情報を返すことができます。 エラスティック テーブルを使用した一括操作の詳細について説明します。
バッチAPI群
一括操作 API を使用できない場合は、SDK for .NET で ExecuteMultiple を使用でき、Web API では OData $batchを使用できます。
これらの API を使用して、一連の操作を 1 つの要求にグループ化し、主に要求数が少なくなり、各操作のネットワーク経由で送受信されるペイロードの合計が減少するため、効率が向上します。 クライアント アプリケーションは、操作が完了するのを待ってから次の要求を送信する必要はありません。
要求内の各操作はサーバーに順番に適用されるため、操作ごとの効率は向上しません。 ただし、操作は個別に実行されるため、失敗した操作に関する情報を取得したり、エラーが発生したときにバッチを停止したりできます。 要求ごとに最大 1,000 の操作を送信できますが、最良の結果を得るには、少ない数から始めて、ケースに最適なサイズ バッチを決定する実験を行うことをお勧めします。
注
一括操作 API とバッチ API の両方で、並列で使用するとパフォーマンスが大幅に向上します。 並列要求を参照してください。
クライアント アーキテクチャ
Dataverse は、多数の同時実行ユーザーを持つ複数のアプリケーションをサポートするデータ ソースとして設計されています。 スループットを最適化するには、Dataverse の長所を使用するようにクライアントを設計します。
クライアント側コードのボトルネックは、パフォーマンスの問題の主な原因です。 開発者がコードの機能を完全に使用できない場合が多く、パフォーマンスに影響する可能性があります。 最適化の失敗がパフォーマンスに大きな影響を与える可能性があるため、クライアント アプリケーションでインフラストラクチャのコアまたはコンピューティングを利用する方法を最適化することが重要です。 たとえば、Azure Functions を使用する場合、自動スケールの実装、ウォームアップ インスタンスの使用、CPU 使用率の調整、複数のコアの利用、コンカレンシーの許可など、パフォーマンスを最適化するために実行できるいくつかの手順があります。
サービス保護制限
すべてのユーザーに一貫した可用性とパフォーマンスを確保するために、Dataverse では API の使用方法にいくつかの制限が適用されます。 これらの制限は、クライアント アプリケーションがサーバー リソースに対して特別な要求を行うタイミングを検出するように設計されています。 一括操作プロジェクトは常に特別な要求を行うので、サービス保護の制限が返すエラーを管理するための準備が必要です。 サービス保護の制限エラーが発生していない場合は、アプリケーションの機能を最大化していません。
サービス保護の制限エラーは、ネットワーク接続の一時的な損失など、クライアントが処理できるように準備する必要があるもう 1 種類の一時的なエラーです。 回復性のあるクライアント アプリケーションは、待機して再試行することでエラーに応答する必要があります。 唯一の違いは、サービス保護の制限によって、再試行の前に待機する必要がある時間が示される点です。
詳細については、次の記事を参照してください。
並列リクエスト
要求を並列で送信することでスループットが大幅に向上しますが、それらを正しく送信する方法を理解する必要があります。
すべての環境が同じとは言えない
すべての Dataverse 環境に同じ数の Web サーバー リソースが割り当てられているわけではありません。 Dataverse は、サポートする Web サーバー リソースを追加することで、環境のニーズに合わせてスケーリングします。 何千人ものアクティブ ユーザーをサポートする運用環境では、試用環境よりも多くの Web サーバーが必要です。 環境に多数の Web サーバーがある場合、要求を並列で送信すると、クライアント アプリケーションで実現できる合計スループットに大きな違いが生じます。
推奨される並列処理の次数 (DOP)
Dataverse は、 環境に対して推奨される並列処理 (DOP) の次数を示すデータを応答ヘッダーに返します。 応答ヘッダーが推奨するよりも多くの並列要求を送信すると、パフォーマンスが低下します。 アプリケーションの実行に使用するクライアント ハードウェアでは、この多くの要求を並列で送信するために、より多くの CPU コアが必要になる場合があります。 最大スループットを取得するには、より多くのクライアントを使用する必要がある場合があります。 たとえば、スケールアウトされたアプリ サービスまたは Azure 関数を使用できます。
クライアント側のアーキテクチャによっては、推奨される並列処理の次数を分割する必要がある場合があります。 たとえば、2 つのクライアントがあり、推奨される DOP が 50 の場合です。25 を使用するように各クライアントを構成します。
Azure アフィニティを無効にする
必要に応じて、アプリケーションを 1 つの Web サーバーに関連付けようとする Azure アフィニティ Cookie を削除 することで、使用可能なすべての Web サーバーを使用するようにクライアントを構成するときに最適な結果を確認できます。 Azure アフィニティを無効にすることは、サーバーからキャッシュされたデータを使用してユーザー エクスペリエンスを最適化する対話型アプリケーションには適していません。
接続を最適化する
.NET を使用する場合は、 次のような構成変更を適用 して接続を最適化し、要求が既定の設定で制限されないようにする必要があります。
// Bump up the min threads reserved for this app to ramp connections faster - minWorkerThreads defaults to 4, minIOCP defaults to 4
ThreadPool.SetMinThreads(100, 100);
// Change max connections from .NET to a remote service default: 2
System.Net.ServicePointManager.DefaultConnectionLimit = 65000;
// Turn off the Expect 100 to continue message - 'true' will cause the caller to wait until it round-trip confirms a connection to the server
System.Net.ServicePointManager.Expect100Continue = false;
// Can decrease overall transmission overhead but can cause delay in data packet arrival
System.Net.ServicePointManager.UseNagleAlgorithm = false;
推奨事項の概要
前に説明した要因に基づいて、次の推奨事項に従って、一括操作プロジェクトのスループットを最適化します。
- 要件に合ったテーブルの種類を選択します。 エラスティック テーブルでは、一括操作の容量が大幅に増えます。
- 使用しているテーブルのカスタム ビジネス ロジックを最小化、無効化、またはバイパスします。 必要に応じてカスタム ロジックをバイパスするようにクライアント アプリケーションを構成します。
- 可能な場合は Dataverse 一括操作 API を使用し、それ以外の場合はバッチ API を使用します。
- サービス保護の制限によって返されるエラーなど、一時的なエラーを管理するようにクライアント アプリケーションを設計します。
- 要求を並列で送信します。 応答ヘッダーを使用して、推奨される並列処理の次数 (DOP) を示します。 必要に応じてアフィニティ Cookie を無効にします。
- データを検証して、テーブル列スキーマを満たしていることを確認します。 これにより、エラーを防ぎ、失敗した操作の数を減らすことができます。
こちらも参照ください
エラスティック テーブル
ビジネス プロセスを拡張するためのプラグインの使用
カスタム Dataverse ロジックをバイパスする
一括操作メッセージ
CreateMultiple および UpdateMultiple 用のプラグインを記述する
並列要求を送信する