動的テーブルのコストを理解する¶
このトピックでは、動的テーブルに関連する計算コストとストレージコストの概要を説明します。Snowflakeコストに関する一般的な情報については、 総コストについて をご参照ください。
コンピューティングコスト¶
動的テーブルには、仮想ウェアハウスとクラウドサービスのコンピューティングという2つのコンピューティングコストがあります。
動的テーブルのリフレッシュには、 仮想ウェアハウス が必要です。つまり、スケジュールされたリフレッシュと手動によるリフレッシュの両方を含め、初期化およびリフレッシュ時にベースオブジェクトに対してクエリを実行します。これらのオペレーションはコンピューティングリソースを使用しますが、これが クレジット を消費します。
動的テーブルは、 クラウドサービスのコンピューティング、基礎となるベースオブジェクトの変更を識別し、仮想ウェアハウスを呼び出す必要があるかどうかを確認する必要があります。変更が識別されなければ、リフレッシュする新しいデータがないため、仮想ウェアハウスのクレジットは消費されません。ベースオブジェクトの変更が動的テーブルクエリでフィルタリングされる場合があることに注意してください。このようなシナリオでは、変更が適用可能かどうかを判断するために動的テーブルがリフレッシュされるため、仮想ウェアハウスのクレジットが消費されます。
関連する仮想ウェアハウスが中断され、ベースオブジェクトの変更が識別子で確認されない場合、中断された仮想ウェアハウスは呼び出されず、クレジットは消費されません。逆に、変更が識別されると、仮想ウェアハウスは更新を処理するために自動的に再開されます。
動的テーブルリフレッシュは、設定された ターゲットラグ によって駆動されます。ターゲットラグが小さい動的テーブルパイプラインでは、リフレッシュの頻度が高くなるため、コンピューティングコストが高くなります。
Snowsight の Refresh History タブを使用して、仮想ウェアハウスのクレジットが消費されたかどうかを確認できます。
ナビゲーションメニューで Monitoring » Dynamic Tables を選択します。
動的テーブルを選択し、 Refresh History タブを開きます。 Warehouse used only チェックボックスをチェックして、ウェアハウスを使用してリフレッシュされたリフレッシュを表示します。
Tip
動的テーブルパイプラインに関連するコストを明確に把握するために、Snowflakeでは専用ウェアハウスを使用して動的テーブルをテストし、動的テーブルに起因する仮想ウェアハウスの消費を分離できるようにすることを推奨しています。動的テーブルを共有ウェアハウスに移動するのは、コストベースラインを確立した後です。
ストレージコスト¶
動的テーブルには、マテリアライズされた結果を格納するためのストレージが必要です。通常のテーブルと同様に、Time Travel、Fail-safeストレージ、クローン作成機能のために追加のストレージコストが発生する場合があります。
このセクションでは、動的テーブルのストレージに関する以下の考慮事項について説明します。
このストレージがどのようにコストを発生させるかについての詳細については、 ストレージコストについて および データストレージに関する考慮事項 をご参照ください。
Time TravelおよびFail-safeストレージ¶
Snowflake Time Travelを使用すると、特定の時点における動的テーブルの履歴バージョンにアクセスしてクエリできるため、データの過去の傾向、変化、異常に関するインサイトを得ることができます。頻繁なリフレッシュはTime Travelデータの蓄積を増加させ、全体的なストレージ使用量を増加させる可能性があることに注意してください。詳細については、 Time Travelの理解と使用 をご参照ください。
Fail-safe機能により、動的テーブルをデータの損失や破損から保護します。設定されたFail-safe期間に応じて、追加の保管料が発生する場合があります。
動的テーブルの複製¶
動的テーブルの複製をサポートすることで、プライマリデータベースからセカンダリデータベースにデータをコピーし、障害復旧やデータ共有を実行できます。これは、障害復旧のためのフェールオーバー準備戦略としても、読み取り専用の目的でデプロイメント間でデータを共有する手段としても機能します。動的テーブルで複製を使用する場合、 複製コスト が発生します。詳細については、 複製と動的テーブル をご参照ください。
中断された動的テーブル¶
中断された動的テーブルは、標準的なストレージ料金以上の追加コストは発生せず、コンピューティングリソースも消費しません。中断されたテーブルを操作する継続的なメンテナンスタスクやスケジュールされたジョブがある場合、コンピューティングリソースが消費される可能性があります。
一時動的テーブル¶
Snowflakeは、明示的に削除されるまで持続し、Fail-Safe期間なしで適切な権限を持つすべてのユーザーが使用できる 一時 動的テーブル（通常テーブルと同様）の作成をサポートしています。一時動的テーブルは、永続的なテーブルが提供するのと同レベルのデータ保護とリカバリを必要としない一時的なデータに最適で、Fail-Safeストレージのストレージ料金を節約できます。
増分リフレッシュ操作のための追加ストレージ¶
増分リフレッシュ操作のために、動的テーブルはテーブル内の各行を識別子とする内部メタデータ列を追加保持します。内部行識別子は、行ごとに一定量のストレージを消費し、テーブルの行数に対して線形にストレージコストが増加します（列数には依存しません）。列数が非常に少ないテーブルの場合、 CTAS と同等のテーブルと比較してストレージが大幅に増加する可能性があります。より広い動的テーブルでは、この効果はあまり顕著ではありません。
リフレッシュスケジュールコスト¶
動的テーブルがリフレッシュされるスケジュールは、 フルまたは増分 のいずれであっても、その全体的なコストに影響を与えます。このセクションでは、リフレッシュスケジュールを決定する際に考慮すべき要素について説明します（リフレッシュは毎回空でないという前提）：
注釈
ソースが変わっていなければ、リフレッシュは比較的安価です。詳細については、 コンピューティングコスト （このトピック内）をご参照ください。
フルリフレッシュスケジュール¶
フルリフレッシュのコストは通常、スキャンされるデータとリフレッシュ頻度に依存します。コストを削減するために、必要なときだけ動的テーブルをリフレッシュできます。たとえば、営業時間外は動的テーブルを中断します。正確なタイミング制御のために、 下流ターゲットラグ を動的テーブルに設定し、 手動リフレッシュ を タスク から使用して、カスタムスケジュールを自動化します。
増分リフレッシュスケジュール¶
増分リフレッシュのコストは通常、ソースオブジェクトの変更量に比例し、さらに固定オーバーヘッドがかかります。
オーバーヘッドが少なければ、リフレッシュ頻度を高く設定してもそれほど不都合はありません。つまり、頻繁にリフレッシュすればするほど最高の結果を得ることができます。例えば、単純な SELECT ... FROM ... WHERE 動的テーブルでは、リフレッシュの間に変更された行を処理するだけなので、オーバーヘッドが最小で、追加コストも少なく頻繁に実行できます。
オーバーヘッドが高い場合は、高いリフレッシュ頻度によるクレジット消費と、鮮度によるビジネス上のメリットのバランスを取る必要があります。例えば、結合を持つ動的テーブルでは、一方のテーブルの変更はもう一方のテーブルと結合されなければなりません。どんなに小さな変更であっても、この結合は通常、最小限のコストで実行されます。このオーバーヘッドが顕著な場合、リフレッシュ頻度が上がるにつれて蓄積される可能性があります。