メインコンテンツまでスキップ

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 つのクラスタリングという固定制限があります。

クラスターサイズ

ドライバー インスタンスの種類

ワーカー数

合計 vCPU

永続ディスク SSD の合計 (TB)

ローカル SSD の合計 (TB)

2X-Small

N2-ハイmem-8

1 x N2-HighMem-8

16 時間

.2

1.5

X-Small

N2-ハイmem-8

2 x N2-HighMem-8

24

.3

2.25

S

N2-ハイMEM-16

4 x N2-HighMem-8

48

.5

4.5

M

N2-ハイMEM-32

8 x N2-HighMem-8

96

.9

9

Large

N2-ハイMEM-32

16 x N2-HighMem-8

160

1.7

18

X-Large

N2-ハイMEM-64

32 x N2-HighMem-8

320

3.3

30

2X-Large

N2-ハイMEM-64

64 x N2-HighMem-8

576

6.5

54

3X-Large

N2-ハイMEM-64

128 x N2-HighMem-8

1088

12.9

102

4X-Large

N2-ハイMEM-64

256 x N2-HighMem-8

2112

25.7

198

すべてのワーカーのインスタンスサイズは n2-highmem-8 です。

注記

この表の情報は、製品または地域の可用性とワークスペースの種類によって異なる場合があります。

コンピュート Engine API quota requirements​

関連するコンピュート エンジン (Engine API ) クォータ フィールドは次のとおりです。

  • N2 CPU
  • 永続ディスク SSD (GB)
  • ローカル SSD (GB)

クォータ要件に関する詳細情報については、 コンピュートエンジン APIを参照してください。

警告

必要な CPU とストレージ リソースをプロビジョニングしないと、SQLウェアハウスは起動しません。コンピュート エンジン APIを参照してください。必要に応じて、リソース クォータを増やして、 SQLウェアハウスの使用をサポートできます。 「クォータの確認と増加」を参照してください。ワークスペースのコストに関する情報については、「 ワークスペースあたりのコスト」を参照してください。

キューイングとオートスケールロジック​

クラシックおよびプロウェアハウスの場合、オートスケールは、実行中およびキューに入れられたすべてのクエリを処理する推定時間に基づいてクラスタリングを追加します。

  • 2〜6分のクエリロード:クラスタリングを1つ追加します。
  • 6-12分:クラスタリングを2つ追加します。
  • 12-22分:クラスタリングを3つ追加します。
  • 22 分以上: 3 クラスタリングと、さらに 15 分の読み込みごとに 1 を追加します。

付則：

  • クエリがキューで 5 分間待機すると、ウェアハウスはスケールアップされます。
  • 負荷が 15 分間連続して低いままの場合、ウェアハウスはその期間からのピーク負荷を処理するために必要な最小値までスケールダウンします。
に最終更新