動的テーブルのコストを理解する¶
このトピックでは、動的テーブルに関連する計算コストとストレージコストの概要を説明します。Snowflakeコストに関する一般的な情報については、 総コストについて をご参照ください。
コンピューティングコスト¶
動的テーブルには、仮想ウェアハウスとクラウドサービスのコンピューティングという2つのコンピューティングコストがあります。
動的テーブルは、 リフレッシュ を実行するために少なくとも1つの 仮想ウェアハウス <label-virtual_warehouse_credit_usage>`を必要とします。それぞれの操作にコンピューティングコストを分ける場合は、任意で2番目のウェアハウスを割り当てることができます。詳細については、 :doc:/user-guide/dynamic-tables-warehouses` をご参照ください。
動的テーブルのリフレッシュは コンピューティングクレジット を消費し、その頻度は構成された ターゲットラグ によって決まります。ターゲットラグ値が小さいと、より頻繁にリフレッシュがトリガーされるため、コンピューティングコストが高くなります。
動的テーブルは、基礎となるベースオブジェクトの変更を識別し、仮想ウェアハウスを実行する必要があるかどうかを判断するために、 クラウドサービスのコンピューティング も必要とします。クラウドサービスコンピューティングで変更が見つからない場合は、リフレッシュする新しいデータがないため、ウェアハウスコンピューティングクレジットは消費されません。変更が存在する場合、動的テーブルクエリが変更をフィルタリングしたとしても、動的テーブルがそれらの変更が適用されるかどうかを評価するために更新されるため、仮想ウェアハウスはクレジットを消費します。
If the associated virtual warehouses are suspended and Cloud Services compute detects no changes in the base tables, the warehouses remain suspended and the dynamic tables don't consume any credits. When Cloud Services compute identifies changes in the base tables, the appropriate warehouse automatically resumes. If the changes support incremental refresh, the dynamic table refreshes by using the WAREHOUSE parameter. If reinitialization is required --- for example, because of a base table schema change --- the dynamic table uses the INITIALIZATION_WAREHOUSE to perform a full reinitialization. For information on how dynamic tables automatically suspend, see 自動動的テーブル一時停止.
仮想ウェアハウスのクレジットの消費量を確認する¶
動的テーブルのリフレッシュが仮想ウェアハウスのクレジットを消費したかどうかを確認するには、 Snowsight の Refresh History タブを使用します。
ナビゲーションメニューで Transformation » Dynamic tables を選択します。
動的テーブルを選択し、 Refresh History タブを選択します。
ウェアハウスを使用して更新されたリフレッシュを表示するには、 Warehouse used only チェックボックスを選択します。
Tip
動的テーブルパイプラインに関連するコストをよりよく理解するために、Snowflakeでは専用のウェアハウスを使用して動的テーブルをテストすることを推奨しています。このようにして、動的テーブルに関連する仮想ウェアハウスの消費を分離できます。動的テーブルを共有ウェアハウスに移動するのは、コストベースラインを確立した後です。
詳細については、 動的テーブルのウェアハウスの使用を理解する をご参照ください。
不変性制約のコンピューティングコスト¶
IMMUTABLE WHERE 制約を使用する場合、Snowflakeは不変性条件に一致しない行のみを再計算するため、再初期化のコストを削減できます。これは、次のシナリオのような再初期化が発生する可能性がある状況で役立ちます。
上流のテーブルまたはビューの再作成。
上流のデータガバナンスポリシーの変更。
フェールオーバーグループ内のセカンダリリージョンへのフェールオーバー。
IMMUTABLE WHERE 制約を使用すると、制約はその述語に一致する変更やデータを無視できるため、増分リフレッシュやフルリフレッシュのコストを削減できます。
動的テーブルに不変性制約を追加しても余分な計算はトリガーされませんが、削除すると計算がトリガーされます。これは、次のリフレッシュで 再初期化 が発生するためです。IMMUTABLE WHERE 制約の述語を変更すると、Snowflakeが元の条件で返された行が新しい条件で引き続き返されるかどうかを判断できるかどうかに応じて、再初期化をトリガーする場合があります。
たとえば、以下の変更は再初期化をトリガーしません。
(ts < CURRENT_TIMESTAMP() - INTERVAL 「2日」)から(ts < CURRENT_TIMESTAMP() - INTERVAL 「1日」)まで（年<= 2023）から（年<= 2024）まで
以下の変更は再初期化をトリガーします。
（ts < '2025-01-02'）から（ts < '2025-01-01'）まで（年<2024年）から（月< 10）まで
ストレージコスト¶
動的テーブルには、マテリアライズされた結果を格納するためのストレージが必要です。通常のテーブルと同様に、Time Travel、Fail-safeストレージ、クローン作成機能のために追加のストレージコストが発生する場合があります。
Dynamic Apache Iceberg™テーブル にはSnowflakeストレージコストはかかりません。詳細については、 請求 をご参照ください。
このセクションでは、動的テーブルのストレージに関する以下の考慮事項について説明します。
このストレージがどのようにコストを発生させるかについての詳細については、 ストレージコストについて および データストレージに関する考慮事項 をご参照ください。
Time TravelおよびFail-safeストレージ¶
Snowflake Time Travelを使用すると、特定の時点における動的テーブルの履歴バージョンにアクセスしてクエリできるため、データの過去の傾向、変化、異常に関するインサイトを得ることができます。
頻繁なリフレッシュはTime Travelデータの蓄積を増加させ、全体的なストレージ使用量を増加させる可能性があります。詳細については、 Time Travelの理解と使用 をご参照ください。
Fail-safe機能により、動的テーブルをデータの損失や破損から保護します。設定されたFail-safe期間に応じて、追加の保管料が発生する場合があります。
動的テーブルの複製¶
動的テーブルの複製をサポートすることで、プライマリデータベースからセカンダリデータベースにデータをコピーし、障害復旧やデータ共有を実行できます。これは、障害復旧のためのフェールオーバー準備戦略としても、読み取り専用の目的でデプロイメント間でデータを共有する手段としても機能します。動的テーブルで複製を使用する場合、 複製コスト が発生します。詳細については、 複製と動的テーブル をご参照ください。
中断された動的テーブル¶
中断された動的テーブルは、標準的なストレージ料金以上の追加コストは発生せず、コンピューティングリソースも消費しません。一時停止されたテーブルを操作する継続的なメンテナンスタスクやスケジュールされたジョブがある場合、動的テーブルがコンピューティングリソースを消費する可能性があります。
一時動的テーブル¶
Snowflakeは、明示的に削除されるまで持続し、Fail-Safe期間なしで適切な権限を持つすべてのユーザーが使用できる 一時 動的テーブル（通常テーブルと同様）の作成をサポートしています。一時動的テーブルは、永続的なテーブルが提供するのと同じレベルのデータ保護やリカバリを必要としない一時的なデータに使用するのが最適です。これらを使用すると、フェイルセーフストレージのストレージ料金を節約できます。
増分リフレッシュ操作のための追加ストレージ¶
増分リフレッシュ操作のために、動的テーブルはテーブル内の各行を識別子とする内部メタデータ列を追加保持します。内部行識別子は、行ごとに一定量のストレージを消費し、テーブルの行数に対して線形にストレージコストが増加します（列数には依存しません）。
列数が非常に少ないテーブルの場合、 CTAS と同等のテーブルと比較してストレージが大幅に増加する可能性があります。より広い動的テーブルでは、この効果はあまり顕著ではありません。
リフレッシュスケジュールコスト¶
動的テーブルがリフレッシュされるスケジュールは、 フルまたは増分 のいずれであっても、その全体的なコストに影響を与えます。このセクションでは、リフレッシュスケジュールを決定する際に考慮すべき要素について説明します（リフレッシュは毎回空でないという前提）。
注釈
ソースが変わっていなければ、リフレッシュは比較的安価です。詳細については、 コンピューティングコスト （このトピック内）をご参照ください。
フルリフレッシュスケジュール¶
フルリフレッシュのコストは通常、動的テーブルがスキャンするデータの量とリフレッシュの頻度に応じて異なります。コストを削減するために、必要なときだけ動的テーブルをリフレッシュできます。たとえば、営業時間外は動的テーブルを一時停止できます。正確なタイミング制御のために、 下流ターゲットラグ を動的テーブルに設定し、 手動リフレッシュ を タスク から使用して、カスタムスケジュールを自動化します。
増分リフレッシュスケジュール¶
増分リフレッシュのコストは通常、ソースオブジェクトの変更量に比例し、さらに固定オーバーヘッドがかかります。
オーバーヘッドが少なければ、リフレッシュ頻度を高く設定してもそれほど不都合はありません。つまり、頻繁にリフレッシュすればするほど最高の結果を得ることができます。たとえば、単純な SELECT ... FROM ... WHERE 動的テーブルでは、リフレッシュの間に変更された行を処理するだけなので、オーバーヘッドが最小で、少ない追加コストで動的テーブルを頻繁に実行できます。
オーバーヘッドが高い場合は、高いリフレッシュ頻度によるクレジット消費と、鮮度によるビジネス上のメリットのバランスを取る必要があります。たとえば、結合を持つ動的テーブルでは、一方のテーブルの変更をもう一方のテーブルと結合する必要があります。どんなに小さな変更であっても、この結合は通常、最小限のコストで実行されます。このオーバーヘッドが顕著な場合、リフレッシュ頻度が上がるにつれて蓄積される可能性があります。
オーバーヘッドを削減し、インクリメンタルリフレッシュのパフォーマンスを最適化するには、 インクリメンタルリフレッシュ向けにクエリを最適化する をご参照ください。