SQLウェアハウスのサイジング、スケーリング、キューイングの動作
この記事では、Databricks SQL ウェアハウスのクエリ キューのサイズ、スケーリング、管理して、パフォーマンスとコストを最適化する方法について説明します。Databricks ほとんどのワークロードでサーバレス SQLウェアハウスを使用することをお勧めします。 サーバレス SQLウェアハウスは、クエリのリソースを動的に管理することで、最高のパフォーマンスと効率を実現します。
サーバレス SQLウェアハウス management
サーバレス SQLウェアハウスは、 Intelligent Workload Management (IWM) を使用してクエリワークロードを自動的に管理します。 IWM は、インフラストラクチャを管理することなく、クエリを迅速かつコスト効率よく処理する AI を活用した機能のセットです。
インテリジェントなワークロード管理とオートスケール
IWMは機械学習モデルを使用して、コンピュートリソースを動的に管理します。
-
新しいクエリが到着すると、IWM はリソース要件を予測し、使用可能なキャパシティーをチェックします。
- 容量が存在する場合、クエリはすぐに開始されます。
- そうでない場合、クエリはキューに配置されます。
-
IWM はキューを継続的に監視します。待機時間が長くなると、オートスケーラーはすぐに プロビジョニング より多くのクラスタリング キューに入れられたクエリを処理します。
-
需要が減少すると、IWM はリソースをスケールダウンしてコストを削減し、最近のピーク負荷を処理するのに十分な容量を維持します。
このアプローチでは、次のことが可能になります。
- クエリの待機時間を低く維持するための迅速なアップスケーリング。
- ハードウェアが利用可能になるとすぐにクエリを許可することで、高いスループットを実現します。
- 低需要時のコスト削減のための迅速なダウンスケーリング。
ウェアハウス SQLサーバレスのサイズ設定
クラスタリング サイズ (たとえば、 X-Small、中、大) によって、1 つのクラスタリングで使用できるコンピュート リソースが決まります。 オートスケーラーは、必要に応じてそのサイズのクラスタリングを追加または削除します。
適切なサイズを選択するには、次のガイドラインを参照してください。
- 1 つの大きなウェアハウスから始めて、サーバレス機能に同時実行性とパフォーマンスを管理させます。 通常、小規模から始めてスケールアップするよりも、必要に応じてサイズを縮小する方が効率的です。
- クエリがディスクにスピルしている場合は、クラスタリングのサイズを大きくします。 クエリ プロファイルでスピルがないか確認します。
- 多くの 並列 クエリーを持つワークロードの場合は、ピーク時の負荷を処理するのに十分な最大数のクラスタリングを構成します。 ウェアハウス モニタリング ページで Peak Queued Queries メトリクスを監視します。
サーバレス SQLウェアハウスの場合、クラスターサイズは、場合によっては、同等のクラスターサイズについて、pro および classic SQLウェアハウスのドキュメントに記載されているものとは異なるインスタンスタイプを使用することがあります。 一般に、サーバレス ウェアハウス SQLウェアハウスのクラスター サイズの価格/パフォーマンス比は、プロ ウェアハウスやクラシック ウェアハウスの価格/パフォーマンス SQL比と似ています。
モニタリング ウェアハウス performance
これらのツールを使用すると、ウェアハウス SQL監視し、適切なサイズを調整できます。 すべてのウェアハウスタイプのキュー内のクエリの最大数は 1,000 です。
- モニタリングページ: SQLウェアハウス モニタリングタブで、[ キューに入れられたクエリのピーク ] をオンにします。0 より大きな一貫した値は、より大きなクラスタリング サイズまたはより多くのクラスタリングが必要になる可能性があることを示します。
- クエリ履歴: 過去のクエリのパフォーマンスを確認して、ボトルネックを特定します。
- クエリプロファイル: 実行プランを検査して、 メトリクス ディスク にスピルされたバイトなどの 、ウェアハウスのサイズが小さすぎる可能性があることを示しています。
クラシックとプロの SQLウェアハウス
クラシック ウェアハウスとプロウェアハウスは、クラスタリングの数を構成する手動スケーリング モデルを使用します。
Sizing and クラスタリング プロビジョニング
クラシックまたはプロウェアハウスを作成するときは、 クラスタリング サイズを選択し、 クラスタリング の最小数と最大数を設定します。 これらの SKU には、10 個のクエリごとに 1 つのクラスタリングという固定制限があります。
次の表は、クラスタリングのサイズと、対応するドライバー数とワーカー数を示しています。 すべてのワーカーは i3.2xlarge インスタンスを使用します。
クラスターサイズ | ドライバー インスタンスの種類 | ワーカー数 |
|---|---|---|
2X-Small | i3.2xlarge | 1 |
X-Small | i3.2xlarge | 2 |
S | i3.4xlarge | 4 |
M | i3.8xlarge | 8 |
Large | i3.8xlarge | 16 時間 |
X-Large | i3.16xlarge | 32 |
2X-Large | i3.16xlarge | 64 |
3X-Large | i3.16xlarge | 128 |
4X-Large | i3.16xlarge | 256 |
プロおよびクラシック SQLウェアハウスのアベイラビリティーゾーン (AZ)
SQLウェアハウスの場合、AWS可用性ゾーンは 自動 (自動AZ)に設定され、ワークスペースサブネットで使用可能なIPに基づいてAZが自動的に選択されます。AWS が容量不足エラーを返した場合、他のアベイラビリティーゾーンで自動 AZ を再試行します。詳細については、 可用性ゾーンに関する情報、 AWS ドキュメントを参照してください。
この表の情報は、製品または地域の可用性とワークスペースの種類によって異なる場合があります。
キューイングとオートスケールロジック
クラシックおよびプロウェアハウスの場合、オートスケールは、実行中およびキューに入れられたすべてのクエリを処理する推定時間に基づいてクラスタリングを追加します。
- 2〜6分のクエリロード:クラスタリングを1つ追加します。
- 6-12分:クラスタリングを2つ追加します。
- 12-22分:クラスタリングを3つ追加します。
- 22 分以上: 3 クラスタリングと、さらに 15 分の読み込みごとに 1 を追加します。
付則：
- クエリがキューで 5 分間待機すると、ウェアハウスはスケールアップされます。
- 負荷が 15 分間連続して低いままの場合、ウェアハウスはその期間からのピーク負荷を処理するために必要な最小値までスケールダウンします。