Understanding costs for dynamic tables¶
このトピックでは、動的テーブルに関連する計算コストとストレージコストの概要を説明します。Snowflakeコストに関する一般的な情報については、 総コストについて をご参照ください。
Compute costs¶
動的テーブルには、仮想ウェアハウスとクラウドサービスのコンピューティングという2つのコンピューティングコストがあります。
動的テーブルは、 リフレッシュ を実行するために少なくとも1つの 仮想ウェアハウス <label-virtual_warehouse_credit_usage>`を必要とします。それぞれの操作にコンピューティングコストを分ける場合は、任意で2番目のウェアハウスを割り当てることができます。詳細については、 :doc:/user-guide/dynamic-tables-warehouses` をご参照ください。
Dynamic table refreshes consume compute credits, and their frequency is determined by the configured target lag: lower target lag values trigger more frequent refreshes and therefore higher compute costs.
Dynamic tables also require Cloud Services compute to identify changes in underlying base objects and determine whether a virtual warehouse must run. If Cloud Services compute finds no changes, no warehouse compute credits are consumed because there's no new data to refresh. If changes do exist, even if the dynamic table query filters them, the virtual warehouse consumes credits because the dynamic table refreshes to evaluate whether those changes apply.
関連する仮想ウェアハウスが一時停止され、クラウドサービスコンピューティングがベーステーブルの変更を検出しない場合、ウェアハウスは停止したままになり、動的テーブルはクレジットを消費しません。クラウドサービスコンピューティングがベーステーブルの変更を識別すると、適切なウェアハウスが自動的に再開します。変更が増分リフレッシュをサポートしている場合、動的テーブルは WAREHOUSE パラメーターを使用してリフレッシュされます。再初期化が必要な場合（ベーステーブルのスキーマ変更など）、動的テーブルは INITIALIZATION_WAREHOUSE を使用して完全な再初期化を実行します。どのように動的テーブルが自動的に一時停止するかについては、 自動動的テーブル一時停止 をご参照ください。
仮想ウェアハウスのクレジットの消費量を確認する¶
動的テーブルのリフレッシュが仮想ウェアハウスのクレジットを消費したかどうかを確認するには、 Snowsight の Refresh History タブを使用します。
ナビゲーションメニューで Transformation » Dynamic tables を選択します。
動的テーブルを選択し、 Refresh History タブを選択します。
ウェアハウスを使用して更新されたリフレッシュを表示するには、 Warehouse used only チェックボックスを選択します。
Tip
To better understand costs related to your dynamic table pipelines, Snowflake recommends that you test dynamic tables by using dedicated warehouses. This way, you can isolate the virtual warehouse consumption that is attributed to dynamic tables. You can move your dynamic tables to a shared warehouse after you establish a cost baseline.
詳細については、 動的テーブルのウェアハウスの使用を理解する をご参照ください。
不変性制約のコンピューティングコスト¶
If you use the IMMUTABLE WHERE constraint, Snowflake recomputes only the rows that don’t match the immutability condition, which helps reduce reinitialization costs. This is useful in situations where reinitialization can occur, such as the following scenarios:
上流のテーブルまたはビューの再作成。
上流のデータガバナンスポリシーの変更。
フェールオーバーグループ内のセカンダリリージョンへのフェールオーバー。
Using the IMMUTABLE WHERE constraint can help you reduce the cost of incremental and full refresh because the constraint ignores changes and data that match its predicate.
Adding immutability constraints to a dynamic table doesn’t trigger extra computation, but removing them does because it causes reinitialization on the next refresh. Modifying the predicate in an IMMUTABLE WHERE constraint might trigger reinitialization depending on whether Snowflake can determine the rows that are returned with the original condition are still returned with the new condition.
たとえば、以下の変更は再初期化をトリガーしません。
(ts < CURRENT_TIMESTAMP() - INTERVAL 「2日」)から(ts < CURRENT_TIMESTAMP() - INTERVAL 「1日」)まで（年<= 2023）から（年<= 2024）まで
以下の変更は再初期化をトリガーします。
（ts < '2025-01-02'）から（ts < '2025-01-01'）まで（年<2024年）から（月< 10）まで
ストレージコスト¶
Dynamic tables require storage to store the materialized results. Similar to regular tables, you might incur additional storage cost for Time Travel, fail-safe storage, and cloning features.
Dynamic Apache Iceberg™ tables don't incur Snowflake storage costs. For more information, see 請求.
このセクションでは、動的テーブルのストレージに関する以下の考慮事項について説明します。
このストレージがどのようにコストを発生させるかについての詳細については、 ストレージコストについて および データストレージに関する考慮事項 をご参照ください。
Time TravelおよびFail-safeストレージ¶
With Snowflake Time Travel, you can access and query historical versions of dynamic tables at specific points in time, which can help provide insights into historical trends, changes, and anomalies in your data.
頻繁なリフレッシュはTime Travelデータの蓄積を増加させ、全体的なストレージ使用量を増加させる可能性があります。詳細については、 Time Travelの理解と使用 をご参照ください。
Fail-safe機能により、動的テーブルをデータの損失や破損から保護します。設定されたFail-safe期間に応じて、追加の保管料が発生する場合があります。
動的テーブルの複製¶
Dynamic tables support cross-account, cross-region replication, which lets you copy data from a primary database to a secondary database for either disaster recovery or data sharing. It can serve as either a failover preparation strategy for disaster recovery or as a means of sharing data across deployments for read-only purposes. Using replication with dynamic tables is subject to replication costs. For more information, see 複製と動的テーブル.
中断された動的テーブル¶
Suspended dynamic tables don't incur additional costs beyond standard storage fees and don't consume compute resources. If you have ongoing maintenance tasks or scheduled jobs that interact with the suspended table, your dynamic tables might consume compute resources.
一時動的テーブル¶
Snowflake supports transient dynamic tables, similar to regular tables, that persist until explicitly dropped, and are available to all users with the appropriate privileges without a fail-safe period. Transient dynamic tables are best used for transitory data that doesn't need the same level of data protection and recovery that permanent tables provide. Using them helps you save on storage charges for fail-safe storage.
増分リフレッシュ操作のための追加ストレージ¶
For incremental refresh operations, dynamic tables maintain an additional internal metadata column for identifying each row within the table. Internal row identifiers consume a constant amount of storage per row and increase storage cost linearly to the number of rows in the table, independent of the number of columns.
列数が非常に少ないテーブルの場合、 CTAS と同等のテーブルと比較してストレージが大幅に増加する可能性があります。より広い動的テーブルでは、この効果はあまり顕著ではありません。
リフレッシュスケジュールコスト¶
The schedule at which a dynamic table refreshes, whether full or incremental, has an effect on its overall cost. This section discusses the factors that you should consider when you decide on a refresh schedule, with the assumption that every refresh is non-empty:
注釈
ソースが変わっていなければ、リフレッシュは比較的安価です。詳細については、 Compute costs （このトピック内）をご参照ください。
フルリフレッシュスケジュール¶
The cost of a full refresh typically depends on how much data your dynamic table scans and how often it refreshes. To save on costs, you can refresh your dynamic tables only when you need to; for example, you can suspend your dynamic tables outside of business hours. For precise timing control, set the downstream target lag for your dynamic tables and use manual refresh from a task to automate your custom schedules.
増分リフレッシュスケジュール¶
The cost of an incremental refresh is typically proportional to the volume of changes in the source objects, plus some fixed overhead.
If the overhead is low, you can set a high refresh frequency without much downside. This means that you can refresh often for best results.
For instance, a simple SELECT ... FROM ... WHERE dynamic table only processes changed rows between refreshes, which has minimal
overhead and the dynamic table can run frequently at low added cost.
If the overhead is high, you must balance the credit consumption of high refresh frequency with the business benefits of freshness. For example, in a dynamic table with a join, you must join the changes in one table with the other table. No matter how small the set of changes, this join usually involves a minimum cost for you to execute. If this overhead is significant, it can accumulate as the refresh frequency increases.