一括操作で最適化されたパフォーマンス
Dataverseで数千または数百万のレコードを作成または更新する必要がある場合、選択によって一括操作プロジェクトの完了にかかる時間を何時間も節約できます。 この記事では、パフォーマンスに影響を与える要因と、一括操作のパフォーマンスを最適化するクライアント アプリケーションを構築するために必要なオプションについて説明します。 レコード数、レコード サイズ、ネットワーク遅延、データの複雑さなどの他の要素も考慮する必要があります。
テーブルの種類
データを保存するために選択したテーブルのタイプは、一括操作で期待できるスループットに最も大きな影響を与えます。 Dataverse は 標準 と エラスティック の 2 種類のテーブルを提供します。
- 標準 テーブルには、Azure SQL を使用してデータが保存されます。 標準テーブルは、トランザクションのサポートと リレーションシップ のモデリングのための優れた機能を提供します。
- エラスティック テーブルには、Azure Cosmos DB を使用してデータが保存されます。 エラスティック ケーブルは、自動的に水平方向にスケーリングして、大量のデータと高レベルのスループットを低遅延で処理します。 エラスティック テーブルは、ワークロードが予測不可能で急増したり、急速に増大したりするアプリケーションに適しています。
データの読み込み時間が主な懸念事項である場合、エラスティック テーブルは最高のパフォーマンスを提供します。 エラスティック テーブルをいつ使用するかについて
ビジネス ロジック
Dataverse は プラグイン を使用してレコードが作成または更新されるときに追加のビジネス ロジックを追加する機能を提供します。プラグイン は、標準テーブル操作のトランザクション前またはトランザクション内で 同期 を実行するように登録できます。 エラスティック テーブルでは、トランザクションがないため、操作の開始前に実行できるプラグインがサポートされています。 標準テーブルの同期ステップ中、またはエラスティック テーブルでの操作の前にプラグイン コードでエラーが発生すると、操作がキャンセルされます。 プラグイン開発者は、データ検証ロジックが確実に適用されるように、意図的に例外をスローして操作をキャンセルできます。
プラグインを同期して実行するように登録すると、操作が完了するまでの時間が長くなります。 パフォーマンスを維持するには:
- 操作用に登録される同期プラグインの数を制限します。 ロジックを同期的に適用することが必須でない限り、非同期プラグインまたは Power Automate フローを使用して非同期で実行するロジックを追加します。
- 使用しているプラグインが実行しようとするロジックが制限されていることを確認してください。 プラグインは 2 分間という十分な時間制限内で完了する必要がありますが、同期プラグインの実行時間が 2 秒を超えると、パフォーマンスが大幅に低下します。
- プラグインは必要な場合にのみ実行するようにしてください。 更新操作用のプラグインをフィルタリングして、特定の列が更新された場合にのみ実行することができます。
- ロジックを可能な限り効率的に実行できるようにプラグインが最適化されていることを確認してください。 標準テーブルの場合、トランザクションとレコードのロックがパフォーマンスに与える影響を考慮する必要があります。 スケーラブルなカスタマイズ設計 およびその他の プラグインを作成するためのベスト プラクティス について学びます
- プラグインを登録する API を選択します。 同期ロジックを適用して、より効率的な
CreateMultipleおよびUpdateMultipleの一括操作 API で実行できます。 CreateMultiple および UpdateMultiple (プレビュー) のプラグインを記述する方法について説明します。
ビジネス ロジックを回避する
一括操作プロジェクトを促進するには、作成または更新操作用に登録されている同期プラグインを無効にしてパフォーマンスを向上させることができます。 ビジネス ロジックが必須ではない場合、または最終的なデータの整合性を確保するために他の手順を計画している場合は、プラグイン ステップを手動で無効にし、一括操作プロジェクトの完了時に再度有効にすることができます。 ただし、プラグインを無効にすると、 すべての クライアントからロジックが適用されなくなります。 この期間中に 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 の使用方法にいくつかの制限を適用します。 これらの制限は、クライアント アプリケーションがサーバー リソースに対してイレギュラーな要求を行っていることを検出するように設計されています。 一括操作プロジェクトでは常にイレギュラーな要求が発生するため、サービス保護制限によって返されるエラーを管理する準備ができている必要があります。 サービス保護制限エラーが発生しない場合は、アプリケーションの機能を最大限に活用できていないことになります。
サービス保護制限エラーは、ネットワーク接続の一時的な喪失など、クライアントが処理できるように準備する必要がある一時的なエラーの一種にすぎません。 回復力のあるクライアント アプリケーションは、待機して再試行することでエラーに応答する必要があります。 唯一の違いは、サービス保護制限により、再試行するまでにどれくらいの時間を待つ必要があるかが示されることです。
詳細については、これらの記事 を参照してください。
並行要求
リクエストを並行して送信すると、スループットが大幅に向上しますが、リクエストを正しく送信する方法を理解する必要があります。
すべての環境が同じではない
すべての Dataverse 環境に同じ数の Web サーバー リソースが割り当てられているわけではありません。 Dataverse 環境をサポートする Web サーバー リソースを追加することで、環境のニーズに合わせて拡張します。 数千のアクティブ ユーザーをサポートする運用環境には、試用環境よりも多くの Web サーバーが必要です。 環境に多数の Web サーバーがある場合、リクエストを並行して送信すると、クライアント アプリケーションが達成できる合計スループットに劇的な違いが生じる可能性があります。
推奨並列化度 (DOP)
Dataverse は 環境に推奨される並列化度 (DOP) を示すデータを応答ヘッダーで返します。 応答ヘッダーが推奨するよりも多くの並列リクエストを送信すると、パフォーマンスが低下します。 アプリケーションの実行に使用するクライアント ハードウェアでは、これほど多くのリクエストを並行して送信するために、より多くの CPU コアが必要になる場合があります。 最大のスループットを得るには、より多くのクライアントを使用する必要がある場合があります。 たとえば、スケールアウトされたアプリ サービスや Azure 関数を使用できます。
クライアント側のアーキテクチャによっては、推奨される並列度を分割する必要がある場合があります。 たとえば、クライアントが 2 つあり、推奨される DOP が 50、各クライアントが 25 を使用するように構成することをお勧めします。
Azure アフィニティを無効にする
必要に応じて、アプリケーションを単一の 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 を無効にします。
- データを検証して、テーブル列のスキーマを満たしていることを確認します。 これにより、エラーを防止し、失敗する操作の数を減らすことができます。
参照
エラスティック テーブル
ビジネス プロセスを拡張するためのプラグインの使用
同期ロジックを回避する
一括操作メッセージ
CreateMultiple と UpdateMultiple のプラグインを書き込む
並行要求を送信する
注意
ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)
この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示