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

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

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

• データのロードの場合、ウェアハウスのサイズは、ロードされるファイルの数と各ファイルのデータ量と一致する必要があります。詳細については、 データロードの計画 をご参照ください。

• 小規模なテスト環境でのクエリの場合、より小さなウェアハウスサイズ（XS、S、M）で十分な場合があります。

• 大規模な本番環境でのクエリでは、より大きなウェアハウスサイズ（L、XL、2XLなど）の方が費用対効果が高い場合があります。

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

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

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

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

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

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

  ただし、設定する値は、クエリワークロードのギャップ（存在する場合）と一致する必要があります。例えば、着信クエリの間隔が2または3分である場合、ウェアハウスは中断と再開の継続的な状態になるため、また、再開するたびに最小クレジット使用量（つまり、60秒）が請求されるため、自動サスペンドを1または2分に設定しても意味がありません（自動再開も有効になっている場合）。

• 次の場合、ウェアハウスの自動サスペンドを無効にすることを検討できます：

  • ウェアハウスには、安定した重いワークロードがあります。

  • ウェアハウスを遅延や遅延時間なしで利用できるようにする必要があります。ウェアハウスのプロビジョニングは一般的に非常に高速です（例: 1秒か2秒）。ただし、ウェアハウスのサイズとプロビジョニングするコンピューティングリソースの可用性によっては、時間がかかる場合があります。

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

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

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

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

• コストやユーザーアクセスを制御する場合は、自動再開を無効のままにして、必要な場合にのみ手動でウェアハウスを再開します。

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

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

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

• 前述したように、ウェアハウスサイズは、大きいほど高速であるとは限りません。すでに迅速に実行されている小規模で基本的なクエリの場合、サイズを変更しても大幅な改善は見られない場合があります。

• 実行中のウェアハウスのサイズを変更しても、ウェアハウスで既に処理されているクエリには影響しません。追加のコンピューティングリソースは、完全にプロビジョニングされると、キューに入れられたクエリと新しいクエリにのみ使用されます。

• 5XL または 6XL ウェアハウスから 4XL 以下のウェアハウスにサイズを変更すると、古いウェアハウスが静止している間、顧客は新しいウェアハウスと古いウェアハウスの両方に対して短期間請求されます。

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

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

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

• Snowflake Enterprise Edition（または、それ以上のエディション）を使用している場合は、 すべて のウェアハウスをマルチクラスターウェアハウスとして構成する必要があります。

• 最大化モードで実行するための特定の要件がない限り、マルチクラスターウェアハウスは自動スケールモードで実行するように構成する必要があります。これにより、Snowflakeは必要に応じてクラスターを自動的に開始および停止できます。

• マルチクラスターウェアハウスのクラスターの最小数と最大数を選択する場合：

  最小

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

  最大

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