Azure Synapse Analytics サーバーレス SQL プールのパフォーマンス チューニング ガイダンス
適用対象:Azure Synapse Analytics
この記事は、Azure Synapse Analytics サーバーレス SQL プールのパフォーマンスを向上させる際に役立ちます。
Note
Azure Synapse Analytics で現在アクティブまたは最近解決された既知の問題のリストを確認します。
最適なパフォーマンスを実現し、Azure Synapse Analytics サーバーレス SQL プールのリソース制約に関連するエラーを防ぐ方法については、次のいくつかのセクションを参照してください。
ベスト プラクティスとトラブルシューティング ガイド
次の記事の情報と戦略は、サーバーレス SQL プールから最高のパフォーマンスを得るのに役立ちます。 これらの記事を使用してユース ケースを確認し、一般的な問題のトラブルシューティングを行うことをお勧めします。
- Azure Synapse Analytics のサーバーレス SQL プールのベスト プラクティス
- Azure Synapse Analytics のサーバーレス SQL プールのトラブルシューティング
サーバーレス SQL プールでのスケーリングについて
サーバーレス SQL プールでは、適切なサイズを手動で選択する必要はありません。 システムは、クエリ要件に基づいてサイズを自動的に調整し、インフラストラクチャを管理し、ソリューションに適したサイズを選択します。
Delta Lake ファイルのパフォーマンス チューニング ガイダンス
Delta Lake ファイルのパフォーマンス チューニングの詳細については、次のリソースを参照してください。
- Delta Lake ドキュメント ページ。
- Delta Lake とは
- Azure Synapse Analytics でサーバーレス SQL プールを使用して Delta Lake ファイルのクエリを実行する
CSV ファイルのパフォーマンス チューニング ガイダンス
サーバーレス SQL プール上の CSV ファイルに対してクエリを実行する場合、パフォーマンスを高めるために最も重要なタスクは、外部テーブルに統計を作成することです。 統計は Parquet ファイルと CSV ファイルに自動的に作成され、 OPENQUERY()
を使用してアクセスされますが、外部テーブルを使用して CSV ファイルを読み取るには、統計を手動で作成する必要があります。
サーバーレス SQL プール内の CSV ファイルのクエリにおける統計の役割の詳細については、次の記事を参照してください。
Power BI やその他のレポート ツールを使用するための推奨事項
Power BI やその他のレポート ツールを使用する場合は、次のベスト プラクティスをお勧めします。
- テナントの場所を常に確認する。
- ユーザー エクスペリエンスを向上させるためにキャッシュを設定する。
- 数百万ものレコードをダッシュボードに返さないようにする。
- スケジュールされた更新を使用して、SQL サーバーレス プール リソースをドレインする並列クエリ実行を回避します。
- Spark を使用して、一般的な分析クエリを事前に集計します。 この "1 回書き込み/読み取り回数" アプローチでは、継続的に実行される大量のクエリを回避できます。
- 異なるデータ ストア間の結合の場合: フィルターを使用して、Azure インフラストラクチャ全体に移動されたビッグ データ ボリュームを回避します。
- 文字データ型
Latin1_General_100_BIN2_UTF8
照合順序を使用します。 この照合順序では、ツールがストレージから読み取るときにフィルターを押し下げて、ストレージからサーバーレス SQL プールにすべてのデータを転送することを回避できます。 - クエリの実行中にデータを
char
またはvarchar
にキャストまたは変換する場合は、最適なサイズを使用します。 可能な場合は、VARCHAR(MAX)
を使用しないようにしてください。 - 自動推論では、データ型が最適ではない形式に変換されます。 データ型を最適化するには、
WITH
句を使用してください。 - Azure Synapse SQL サーバーレス プール リソースには制限があります。 クエリを同時に実行すると、リソースが消費されます。 複数の更新が並行して行われると、Power BI (PBI) ダッシュボードがリソース制限に達するのが一般的です。 スケジュールされた更新とロード テストは、この問題を回避するのに役立ちます。 また、複数の Azure Synapse ワークスペースを使用すると、より大きなコンカレンシー要件に対処できます。
- クエリ
sys.columns
を実行するか、sp_describe_first_result_set
とselect top 0 from <view>
を使用して、ビューの作成後にデータ型を確認できます。 この方法は、SELECT * FROM...
を使用するよりも高速でコストが低くなります。 - ステートメント ジェネレーターを使用すると、クエリに最適な列形式を自動作成することができます。
OPENJSON
関数を使用して、入れ子になった JSON データを列として公開します。 ただし、AS JSON
コマンドも使用する場合は、列の種類をNVARCHAR(MAX)
する必要があります。 この方法は、パフォーマンスには最適ではありません。 最適なオプションは、WITH
句を使用して、入れ子になった配列を列として表示することです。- Cosmos DB トランザクション ストアのパーティション キーは、分析ストアでは使用されません。 Azure Synapse Link では、データ インジェストとポイント読み取りを最適化するために、トランザクション データをモデル化できるようになりました。
追加のガイダンスとベスト プラクティス
カテゴリ | 推奨されるアクションまたはドキュメント |
---|---|
データ探索 | Azure Storage クエリの結果を Azure Storage に格納する 論理データ ウェアハウス |
OPENROWSET および外部テーブル | OPENROWSET 関数 外部テーブル ストアド プロシージャ ビュー データ変換 |
サーバーレス SQL プールで使用可能な T-SQL 機能 | Azure Synapse プールの T-SQL 機能 |
サードパーティの情報に関する免責事項
この資料に記載されているサードパーティ製品は、マイクロソフトと関連のない他社の製品です。 明示的か黙示的かにかかわらず、これらの製品のパフォーマンスや信頼性についてマイクロソフトはいかなる責任も負わないものとします。