ウェアハウスに関する考慮事項¶

このトピックでは、Snowflakeで仮想ウェアハウスを使用してクエリを処理するための一般ガイドラインとベストプラクティスを提供します。すべてのクエリシナリオは異なり、同時ユーザー/クエリの数、クエリ対象のテーブルの数、データサイズと構成、およびウェアハウスの可用性、待ち時間、コストに関する特定の要件など、さまざまな要因の影響を受けるため、特定または絶対の数値、値、推奨事項を提供しません。

また、データのロードに関するウェアハウスの考慮事項についてはカバーしません。別のトピックで説明します（サイドバーを参照）。

ウェアハウスを効果的かつ効率的に使用するための鍵は次のとおりです：

さまざまな種類のクエリとさまざまなウェアハウスサイズを試して、特定のクエリのニーズとワークロードに最適な組み合わせを決定します。
ウェアハウスのサイズに焦点を合わせないでください。Snowflakeは1秒あたりの課金を利用するため、より大きなウェアハウス（L、XL、2XLなど）を実行し、使用していないときは単に中断することができます。

注釈

これらのガイドラインとベストプラクティスは、すべてのアカウントの標準である単一クラスターウェアハウスと、 Snowflake Enterprise Edition （以上）で利用可能なマルチクラスターウェアハウスの両方に適用されます。

このトピックの内容：

ウェアハウスのクレジットはどのように請求されますか？¶

クレジットチャージは以下に基づいて計算されます。

ウェアハウスサイズ。
クラスターの数（マルチクラスターウェアハウスを使用している場合）。
各クラスターのコンピューティングリソースが実行される時間の長さ。

例:

XS:: 各クラスターが実行する、連続する満時間ごとに1クレジットを請求します。連続する各サイズは、通常、ウェアハウスあたりのコンピューティングリソースの数を2倍にします。
4XL:: 各クラスターが実行する、連続する満時間ごとに128クレジットを請求します。

次の点に注意してください。

コンピューティングリソースがウェアハウスにプロビジョニングされる場合、
- コンピューティングリソースのプロビジョニングの最小請求料金は1分（つまり、60秒）です。
- 最初の60秒間が終了する前にウェアハウスを停止しても利点はありません。その期間のクレジットはすでに請求されているからです。
- 最初の60秒後、稼働中のウェアハウスに対する後続のすべての請求は1秒単位です（すべてのコンピューティングリソースがシャットダウンされるまで）。以下に3つの例を示します。
  - ウェアハウスが30〜60秒間実行された場合は、60秒間で請求されます。
  - ウェアハウスが61秒間実行された場合は、61秒間のみ請求されます。
  - ウェアハウスが61秒間実行され、シャットダウンしてから再起動し、60秒間未満実行されると、121秒間（60 + 1 + 60）で請求されます。
ウェアハウスのサイズを変更すると、ウェアハウス内の各クラスターの追加コンピューティングリソースがプロビジョニングされます。
- これにより、ウェアハウスに対して請求されるクレジット数がそれに対応して増加します（追加のコンピューティングリソースの実行中）。
- 追加のコンピューティングリソースは、プロビジョニングされると請求されます（つまり、追加のコンピューティングリソースのクレジットは、ウェアハウスのサイズが変更された時間に対応して請求されます）。
- 5XL または 6XL ウェアハウスから 4XL 以下のウェアハウスにサイズを変更すると、古いウェアハウスが静止している間、顧客は新しいウェアハウスと古いウェアハウスの両方に対して短期間請求されます。
- クレジット使用状況は時間単位で表示されます。1秒あたりの請求では、クレジットの使用状況/請求額の端数が表示されます。

クエリ構成がウェアハウス処理に及ぼす影響¶

クエリの処理に必要なコンピューティングリソースは、クエリのサイズと複雑さに依存します。大半の場合、特により大規模で複雑なクエリの場合、クエリは、ウェアハウスサイズに関して線形にスケーリングされます。クエリ処理に影響を与える要因を考慮する場合、次のことを考慮してください：

クエリされるテーブルの全体的なサイズは、行数よりも影響が大きくなります。
述語を使用したクエリフィルタリングは、クエリ内の結合/テーブルの数と同様に、処理に影響を与えます。

Tip

最良の結果を得るには、同じウェアハウスで比較的同種のクエリ（サイズ、複雑さ、データセットなど）を実行してください。同じウェアハウスでさまざまなサイズや複雑さのクエリを実行すると、ウェアハウスの負荷を分析するのが難しくなり、ワークロード内のクエリのサイズ、構成、数に合わせて最適なサイズを選択することが難しくなります。

ウェアハウスのキャッシュはクエリにどのように影響しますか？¶

各ウェアハウスは、実行中に、クエリがウェアハウスによって処理されるときにアクセスされるテーブルデータのキャッシュを保持します。これにより、クエリ内のテーブルではなくキャッシュから読み取ることができる場合は、後続のクエリのパフォーマンスが向上します。キャッシュのサイズは、ウェアハウス内のコンピューティングリソースによって決定されます（つまり、ウェアハウスが大きいほど、したがって、ウェアハウス内のコンピューティングリソースが大きいほど、キャッシュは大きくなります）。

ウェアハウスが中断されると、このキャッシュはドロップされるため、ウェアハウスの再開後、一部のクエリの初期パフォーマンスが低下する可能性があります。再開されたウェアハウスが実行され、より多くのクエリが処理されると、キャッシュが再構築され、キャッシュを利用できるクエリのパフォーマンスが向上します。

ウェアハウスを中断するか、実行したままにするかを決定するときは、このことに留意してください。つまり、ウェアハウスを中断することでクレジットを節約することと、パフォーマンスを向上させるために以前のクエリからのデータのキャッシュを維持することとのトレードオフを検討します。

ウェアハウスの作成¶

ウェアハウスを作成するとき、コストとパフォーマンスの観点から考慮する必要がある、2つの最も重要な要素は次のとおりです。

ウェアハウスサイズ（つまり、利用可能なコンピューティングリソース）
手動管理と自動管理（ウェアハウスの開始/再開および中断用）。

ウェアハウス内のクラスターの数は、 Snowflake Enterprise Edition （または、それ以上）およびマルチクラスターウェアハウスを使用している場合にも重要です。詳細については、スケールアップとスケールアウト（このトピック内）をご参照ください。

初期ウェアハウスのサイズの選択¶

ウェアハウスに選択する初期サイズは、ウェアハウスが実行しているタスクと処理するワークロードによって異なります。例：

データのロードの場合、ウェアハウスのサイズは、ロードされるファイルの数と各ファイルのデータ量と一致する必要があります。詳細については、データロードの計画をご参照ください。
小規模なテスト環境でのクエリの場合、より小さなウェアハウスサイズ（XS、S、M）で十分な場合があります。
大規模な本番環境でのクエリでは、より大きなウェアハウスサイズ（L、XL、2XLなど）の方が費用対効果が高い場合があります。

ただし、1秒あたりのクレジット請求と自動中断により、より大きなサイズから始めて、ワークロードに合わせてサイズを調整する柔軟性が得られることに注意してください。ウェアハウスのサイズはいつでも縮小できます。

また、より小さく、より基本的なクエリの場合、大きくても必ずしも高速ではありません。通常、小規模/単純なクエリは、同時に処理されるクエリの数に関係なく、追加リソースの恩恵を受けないため、XL（またはより大きな）ウェアハウスを必要としません。一般に、ウェアハウスのサイズを、ウェアハウスによって処理されるクエリの予想されるサイズと複雑さに合わせてみてください。

Tip

複数のサイズのウェアハウス（例：XL、L、M）に対して同じクエリを実行して実験します。実験するクエリのサイズと複雑さは、通常5〜10分（またはそれ以下）以内に完了することがわかっている必要があります。

ウェアハウスの停止の自動化¶

ウェアハウスは、指定された期間が経過した後に、アクティビティがなくなると自動的に中断するように設定できます。自動中断は、ウェアハウスの非アクティブな期間（分、時間など）を指定することにより有効になります。

ワークロードとウェアハウスの可用性の要件に応じて、自動中断を設定することをお勧めします：

自動中断を有効にする場合は、Snowflakeが1秒あたりの請求を使用するため、低い値（5または10分以下）に設定することをお勧めします。これは、使用されていないときにウェアハウスが稼働しないように（そしてクレジットを消費しないように）します。

ただし、設定する値は、クエリワークロードのギャップ（存在する場合）と一致する必要があります。例えば、着信クエリの間隔が2または3分である場合、ウェアハウスは中断と再開の継続的な状態になるため、また、再開するたびに最小クレジット使用量（つまり、60秒）が請求されるため、自動中断を1または2分に設定しても意味がありません（自動再開も有効になっている場合）。
次の場合、ウェアハウスの自動中断を無効にすることを検討できます：
- ウェアハウスには、安定した重いワークロードがあります。
- ウェアハウスを遅延や遅延時間なしで利用できるようにする必要があります。ウェアハウスのプロビジョニングは一般的に非常に高速です（例: 1秒か2秒）。ただし、ウェアハウスのサイズとプロビジョニングするコンピューティングリソースの可用性によっては、時間がかかる場合があります。

重要

自動中断を無効にすることを選択した場合は、ウェアハウスがクエリを処理していないときでも、ウェアハウスの継続的な実行に関連するコストを慎重に検討してください。特に大規模なウェアハウス（XL、2XLなど）の場合は、コストが大幅に上昇する可能性があります。

自動中断を無効にするには、ウェブインターフェイスで明示的に Never を選択するか、 SQL で 0 または NULL を指定する必要があります。

ウェアハウス再開の自動化¶

ウェアハウスは、新しいクエリが送信されたときに自動的に再開するように設定できます。

特定のウェアハウスの使用をどの程度制御したいかに応じて、自動再開を有効/無効にすることをお勧めします：

コストとアクセスが問題にならない場合は、自動再開を有効にして、必要なときにいつでもウェアハウスが開始されるようにします。プロビジョニングが理由で、ウェアハウスの再開が少し遅れることがあることに注意してください。
コストやユーザーアクセスを制御する場合は、自動再開を無効のままにして、必要な場合にのみ手動でウェアハウスを再開します。

スケールアップとスケールアウト¶

Snowflakeは、ウェアハウスを拡張する2つの方法をサポートしています：

ウェアハウスのサイズを変更してスケールアップします。
クラスターをマルチクラスターウェアハウスに追加してスケールアウトします（Snowflake Enterprise Edition 以上が必要）。

ウェアハウスのサイズ変更によりパフォーマンスが向上¶

ウェアハウスのサイズを変更すると、一般に、特に大規模で複雑なクエリのクエリパフォーマンスが向上します。また、同時に送信されるすべてのクエリを処理するための十分なコンピューティングリソースが、ウェアハウスにない場合に発生するキューイングを減らすのに役立ちます。ウェアハウスのサイズ変更は、並行性の問題を処理するためのものではないことに注意してください。代わりに、追加のウェアハウスを使用してワークロードを処理するか、マルチクラスターウェアハウスを使用します（この機能がアカウントで使用可能な場合）。

Snowflakeは、実行中でも、いつでもウェアハウスのサイズ変更をサポートしています。クエリの実行速度が遅く、同じウェアハウスで実行したいサイズと複雑さの類似したクエリがある場合、実行中にウェアハウスのサイズを変更することを選択できます。ただし、次のことに注意してください：

前述したように、ウェアハウスサイズは、大きいほど高速であるとは限りません。すでに迅速に実行されている小規模で基本的なクエリの場合、サイズを変更しても大幅な改善は見られない場合があります。
実行中のウェアハウスのサイズを変更しても、ウェアハウスで既に処理されているクエリには影響しません。追加のコンピューティングリソースは、完全にプロビジョニングされると、キューに入れられたクエリと新しいクエリにのみ使用されます。
5XL または 6XL ウェアハウスから 4XL 以下のウェアハウスにサイズを変更すると、古いウェアハウスが静止している間、顧客は新しいウェアハウスと古いウェアハウスの両方に対して短期間請求されます。

Tip

実行中のウェアハウスのサイズを小さくすると、コンピューティングリソースがウェアハウスから削除されます。コンピューティングリソースが削除されると、リソースに関連付けられたキャッシュがドロップされます。これは、ウェアハウスの中断が再開後にパフォーマンスに影響を与えるのと同じように、パフォーマンスに影響を与える可能性があります。

稼働中のウェアハウスのサイズを縮小するか、現在のサイズのままにするかを選択する際には、この点に留意してください。つまり、クレジットの節約とキャッシュの維持の間にトレードオフがあります。

マルチクラスターウェアハウスにより同時実行性が向上¶

マルチクラスターウェアハウスは、多数の同時ユーザーやクエリに関連するキューイングおよびパフォーマンスの問題を処理するために特別に設計されています。さらに、ユーザー/クエリの数が変動する傾向にある場合、マルチクラスターウェアハウスはこのプロセスを自動化するのに役立ちます。

マルチクラスターウェアハウスを使用するかどうか、およびマルチクラスターウェアハウスごとに使用するクラスターの数を決定するときは、以下を考慮してください。

Snowflake Enterprise Edition（または、それ以上のエディション）を使用している場合は、すべてのウェアハウスをマルチクラスターウェアハウスとして構成する必要があります。
最大化モードで実行するための特定の要件がない限り、マルチクラスターウェアハウスは自動スケールモードで実行するように構成する必要があります。これにより、Snowflakeは必要に応じてクラスターを自動的に開始および停止できます。
マルチクラスターウェアハウスのクラスターの最小数と最大数を選択する場合：

最小:

デフォルト値 1 のままにします。これにより、必要な場合にのみ追加のクラスターが開始されます。ただし、ウェアハウスの高可用性が懸念される場合は、値を 1 より高く設定します。これにより、万一クラスターに障害が発生した場合でも、マルチクラスターウェアハウスの可用性と継続性を確保できます。

最大:

ウェアハウスサイズと対応するクレジットコストを考慮しながら、この値をできるだけ大きく設定します。たとえば、最大クラスター = 10 のXLマルチクラスターウェアハウスは、10個のクラスターすべてが1時間連続して実行されると、1時間で160クレジットを消費します。