コストの最適化¶
このトピックでは、Snowflakeを最適化してコストを削減し、費用を最大限に活用する方法について説明します。
クラウドサービスのコスト最適化¶
クラウドサービスの使用量 が予想よりも多い場合は、Snowflakeの使用方法が次のパターンのいずれかに当てはまるかどうかを確認してください。各パターンには、クラウドサービスに関連するコストを削減するのに役立つ推奨事項が含まれています。
- パターン: トランザクションロックによるクエリのブロック
更新コマンドとマージコマンドはテーブルにトランザクションロックをかけ、ロックが解放されるまで他のコマンドがそのテーブル上で実行できないようにします。クエリは、ロックが解除されるのを待つ間、クラウドサービスのクレジットを消費します。クエリがクラウドサービスレイヤーでロックを待つ時間が長ければ長いほど、クレジットの消費量は増えます。
推奨: トランザクションロックは、ユーザーが1つのテーブルに対して同時に更新/マージコマンドを実行した場合、特に各コマンドが数行しか更新していない場合によく発生します。単発の更新ではなく、一括コマンドを使用することで、これらのロックを最小限に抑えることができます。この戦略では次を行います。
バッチ INSERT ステートメントを使用して、仮テーブルに新しいデータをロードします。単一行の挿入の使用は避けます。新しいデータを継続的にロードする API の呼び出しも、単一行の挿入ではなく、一括挿入を送信するように設計する必要があります。
仮テーブルを使用して、宛先テーブルを更新/マージします。
送信元が1日中新しいデータを送信し続ける場合、 タスク を使用して宛先テーブルを定期的に更新することを検討してください。
- パターン: 選択性の低いコピーコマンド
コピーコマンドを実行すると、Amazon Simple Storage Service（S3）からファイルを一覧表示します。ファイルの一覧表示はクラウドサービスのコンピュートのみを使用するため、選択性に乏しいコピーコマンドを実行すると、クラウドサービスの使用量が多くなる可能性があります。
推奨: S3バケツの構造を、ある種の日付の接頭辞を含むように変更して、必要なターゲットファイルのみを一覧表示するよう検討してください。
- パターン: 高頻度の DDL 演算とクローニング
データ定義言語（DDL）操作、特にクローン作成は、完全にメタデータ操作であり、クラウドサービスのコンピュートのみを使用することを意味します。大規模なスキーマやテーブルを頻繁に作成または削除したり、バックアップのためにデータベースをクローンしたりすると、クラウドサービスを大量に使用する可能性があります。
推奨: クローン作成は、ディープコピーに必要なリソースのほんの一部しか使わないため、引き続きクローンを行うべきです。クローン作成パターンを可能な限り細かくし、頻繁に実行しすぎないように見直します。例えば、スキーマ全体をクローンするのではなく、個々のテーブルのみのクローンをお勧めします。
- パターン: 高頻度、シンプルなクエリ
単一のシンプルなクエリによるクラウドサービスの消費はごくわずかですが、
SELECT 1、SELECT sequence1.NEXTVAL、SELECT CURRENT_SESSION()のようなクエリを非常に高い頻度（1日あたり数万）で実行すると、クラウドサービスを大幅に使用することになります。推奨： クエリの頻度を見直し、その頻度がユースケースに対して適切に設定されているかどうかを判断します。JDBC ドライバーを使用しているパートナーツールから
SELECT CURRENT_SESSION()クエリが頻繁に発生する場合は、パートナーがコードを更新して SnowflakeConnectionインターフェイス でgetSessionId()メソッドを使用していることを確認します。これにより、キャッシュを活用し、クラウドサービスの利用を減らすことができます。
- パターン: 高頻度 INFORMATION_SCHEMA クエリ
Snowflake Information Schema に対するクエリは、クラウドサービスのリソースのみを消費します。INFORMATION_SCHEMA ビューに対する単一のクエリによるクラウドサービスの消費はごくわずかかもしれませんが、これらのクエリを非常に高い頻度（1日あたり数万）で実行すると、クラウドサービスを大幅に使用することになります。
推奨： クエリの頻度を見直し、その頻度がユースケースに対して適切に設定されているかどうかを判断します。あるいは、 INFORMATION_SCHEMA ビューの代わりに ACCOUNT_USAGE スキーマ のビューをクエリすることができます。ACCOUNT_USAGE スキーマのクエリは、クラウドサービスではなく、仮想ウェアハウスを使用します。
- パターン: 高頻度 SHOW コマンド（データアプリケーションとサードパーティツールにより提供）
SHOW コマンドは完全にメタデータ操作であり、クラウドサービスのリソースのみを消費します。このパターンは通常、 SHOW コマンドを高頻度で実行するアプリケーションをSnowflakeの上に構築した場合に発生します。これらのコマンドは、サードパーティのツールによって起動されることもあります。
推奨: クエリの頻度を見直し、その頻度がユースケースに対して適切に設定されているかどうかを判断します。パートナーツールの場合は、パートナーに連絡を取り、使用方法を調整する予定があるかどうかを確認します。
- パターン: 単一行の挿入と断片化されたスキーマ（データアプリケーションにより提供）
Snowflakeは OLTP システムではないため、単一行の挿入は最適ではなく、クラウドサービスのリソースを大量に消費する可能性があります。
顧客ごとに1つのスキーマを定義するデータアプリケーションを構築すると、一定期間に数回のデータロードが発生する可能性があり、クラウドサービスの消費量が多くなる可能性があります。
このパターンでは、Snowflakeが維持する必要があるメタデータも多くなり、メタデータの操作にはクラウドサービスのリソースが消費されます。各メタデータ操作は、個々には最小限のリソースしか消費しませんが、全体としてはかなりの消費になる可能性があります。
推奨: 一般的に、単一行の挿入よりも、バッチまたは一括ロードを行います。
共有スキーマを使用することで大幅に効率化され、コスト削減につながります。すべてのテーブルを
customer_IDでクラスタ化し、 セキュアビュー を使用することをお勧めします。
- パターン: 複合 SQL クエリ
クエリに多くの結合/デカルト積が含まれる場合、大きなリストで IN 演算子を使用する場合、または非常に大きなクエリである場合、クラウドサービスの膨大なコンピュートを消費する可能性があります。これらのタイプのクエリは、いずれもコンパイル時間が長くなります。
推奨: クエリを見直して、あなたの意図したとおりになっていることを確認します。Snowflakeはこれらのクエリをサポートし、消費されたリソースに対してのみ課金されます。