Snowflakeインタラクティブテーブルとインタラクティブウェアハウス¶

インタラクティブテーブルの作成¶

テーブル作成は、標準 CTAS （ CREATE TABLE AS SELECT ）構文と、テーブルタイプを定義する追加の INTERACTIVE キーワードに従います。

CREATE INTERACTIVE TABLE コマンドには CLUSTER BY 句も必要です。CLUSTER BY 句で1つ以上の列を指定して、最もタイムクリティカルなクエリで WHERE 句と一致させます。CLUSTER BY 句で指定する列は、インタラクティブテーブルでのクエリのパフォーマンスに大きな影響を与える可能性があります。したがって、クラスタリング列を慎重に選択してください。最適なクラスタリング列の選択の詳細については、 クラスタリングキーとクラスタ化されたテーブル を参照してください。

次のコマンドは、標準テーブルと同じ列とデータを含むインタラクティブテーブルを作成します。CLUSTER BY 句は、ソーステーブルから id という列を参照します。

CREATE INTERACTIVE TABLE
  IF NOT EXISTS orders
  CLUSTER BY (id)
AS
  SELECT * FROM demoSource;

TARGET_LAG = '<num> { seconds | minutes | hours | days }'

CREATE INTERACTIVE TABLE my_dynamic_interactive_table
  CLUSTER BY (c1, c2)
  TARGET_LAG = '20 minutes'
  WAREHOUSE = s_maintenance_wh
  INITIALIZATION_WAREHOUSE = xl_initial_wh
AS SELECT c1, SUM(c2) FROM my_source_table GROUP BY c1;

ALTER INTERACTIVE TABLE ``my_dynamic_interactive_table`` REFRESH.

インタラクティブウェアハウスの作成¶

インタラクティブテーブルを作成した後、そのテーブルを最適なパフォーマンスでクエリするには、インタラクティブウェアハウスが必要です。CREATE WAREHOUSE で INTERACTIVE キーワードを指定するか、 CREATE OR REPLACE WAREHOUSE コマンドを指定します。

オプションで、インタラクティブテーブル名のコンマ区切りリストで TABLES 句を指定できます。その句を使用すると、これらのインタラクティブテーブルがインタラクティブウェアハウスにすぐに関連付けられます。

次のコマンドは、 orders というインタラクティブテーブル名と関連付けられているインタラクティブウェアハウスを作成します。この場合、すぐにインタラクティブウェアハウスの USE WAREHOUSE コマンドを実行でき、インタラクティブテーブルのクエリの実行を開始できます。

CREATE OR REPLACE INTERACTIVE WAREHOUSE interactive_demo
  TABLES (orders)
  WAREHOUSE_SIZE = 'XSMALL';

次のコマンドは、関連付けられたインタラクティブテーブルのないインタラクティブウェアハウスを作成します。この場合、後で ALTER WAREHOUSE コマンドを実行して、インタラクティブテーブルをインタラクティブウェアハウスに関連付けます。

CREATE OR REPLACE INTERACTIVE WAREHOUSE interactive_demo
  WAREHOUSE_SIZE = 'XSMALL';

インタラクティブウェアハウスを作成すると、再開するまで一時停止状態が維持されます。インタラクティブウェアハウスの自動一時停止と自動再開を構成できます。インタラクティブウェアハウスの最小自動一時停止間隔は24時間（86400秒）です。詳細については、 インタラクティブウェアハウスの再開と一時停止 をご参照ください。

インタラクティブウェアハウスのクエリのベストプラクティス¶

インタラクティブウェアハウスは、 選択的なワークロード を使用するクエリに最適化されています。つまり、選択性の高いクエリでは、他のクエリタイプよりもパフォーマンスが大幅に向上します。

SELECT col1, col4, AVG(col_x)
  FROM my_table
  GROUP BY col1, col4;

SELECT * FROM my_table;

SELECT col1, col2
  FROM my_table
  WHERE
    col_x IN (1,4,7,8)
    AND event_time >=
      DATEADD(hour, -1, CURRENT_TIMESTAMP());

SELECT col1, col2
  FROM my_table
  WHERE
    event_time >=
      DATEADD(day, -365, CURRENT_TIMESTAMP());

大規模な結合（例：2つのファクトテーブルを結合する）や正規表現などの計算負荷の高い式など、その他の複雑な状況では、コンピューティングリソースの使用量が多くなるため、同時実行性が低下する可能性があります。このような状況での最適化については、 インタラクティブウェアハウスのサイズの選択 をご参照ください。

インタラクティブテーブルのデータレイアウトのベストプラクティス¶

インタラクティブテーブルは、パフォーマンスのための標準的なSnowflakeベストプラクティスに従います。特に、インタラクティブテーブルは、 適切にクラスター化されたテーブル を活用します。これは、フィルタリングする同じ列に基づいてソートされるテーブルです。たとえば、クエリが sale_date などの TIMESTAMP 列で頻繁にフィルタリングする場合、インタラクティブテーブルを作成するときにその列をクラスタリングキーとして使用することは理にかなっています。たとえば、インタラクティブテーブルは次のように作成することができます。

CREATE INTERACTIVE TABLE product_sales (<column definitions>) CLUSTER BY (sale_date);

そうすると、 sale_date でフィルタリングする SELECT クエリは、関係のないすべてのデータをすばやくスキップして結果を返すことができます。たとえば、次のクエリは sale_date 列をテストすることにより、日付範囲でフィルターします。

SELECT ... WHERE sale_date > '2025-10-24' AND ...

最適なクラスタリングキーの選択の詳細については、 クラスタリングキーとクラスタ化されたテーブル をご参照ください。

インタラクティブウェアハウスのサイズの選択¶

すべてのクエリとレイアウトの最適化を完了したら、需要を満たすために ウェアハウスのスケーリング を検討します。インタラクティブウェアハウスには、 XSMALL から 3XLARGE までさまざまなサイズがあり、 マルチクラスターウェアハウス にも対応しています。

インタラクティブテーブルの 作業データセット のおおよそのサイズに基づいて、ウェアハウスのサイズを設定することから始めることをお勧めします。作業データセットとは、頻繁にクエリされるデータの部分を指します。たとえば、クエリが通常、過去7日間の売上データのみをクエリする場合、作業セットはその7日間に対応するインタラクティブテーブルの一部です。

これは、インタラクティブウェアハウスが ローカルストレージキャッシュ を利用するためです。データセット（テーブル）全体のデータには常にアクセスできますが、キャッシュされていないデータにアクセスすると、最初の読み込み時に高い読み込みレイテンシが発生します。

ワークロードのニーズに合わせてウェアハウスのサイズを選択します。特定のデータとワークロードを試して、インタラクティブウェアハウスの最適なサイズを決定します。

作業データセットのサイズに基づいて、次のウェアハウスサイズから始めることをお勧めします（クラウドプロバイダーとリージョンに応じて変更になる場合や、ハードウェアが異なる場合があります）。

インタラクティブウェアハウスへのインタラクティブテーブルの追加¶

インタラクティブテーブルで最適なクエリパフォーマンスを得るには、インタラクティブウェアハウスを使用する必要があります。

インタラクティブウェアハウスからインタラクティブテーブルをクエリするには、1回限りの操作を実行してインタラクティブテーブルをインタラクティブウェアハウスに追加する必要があります。そうしないと、インタラクティブウェアハウスからそのようなテーブルに対してクエリを実行すると、object not found`というエラーが表示されます。CREATE INTERACTIVE WAREHOUSE コマンドで TABLES 句を使用してインタラクティブウェアハウスに関連付けるインタラクティブテーブルを指定しなかった場合は、後で :doc:/sql-reference/sql/alter-warehouse` コマンドを使用して指定できます。

次のコマンドは orders テーブルを interactive_demo ウェアハウスに関連付けます。ADD TABLES 句を使用して、コンマで区切って複数のテーブル名を指定できます。

ALTER WAREHOUSE interactive_demo ADD TABLES (orders);

インタラクティブテーブルがインタラクティブウェアハウスに既に関連付けられている場合、コマンドは成功しますが、効果は反映されません。インタラクティブテーブルは、複数のインタラクティブウェアハウスに関連付けることができます。

このアクションにより、キャッシュのウォームアッププロセスが開始されます。キャッシュのウォームアップ時間は、データのサイズとウェアハウスのサイズに基づいています。XSウェアハウスは、約300～350MB/秒でウォームアップします。テーブルが大きいほど、キャッシュのウォームアップ時間は長くなります。ウェアハウスが大きいほど、より速くウォームアップします。

ウォームアッププロセスは、ウェアハウスが新しいクエリを受け入れることをブロックしません。ウォームアップの優先順位は、1.ユーザーが発行したクエリ、2.自動リフレッシュまたはその他のデータインジェスション手段によって新しく追加されたマイクロパーティション、3.既存のデータです。

キャッシュのウォームアップはクエリに依存するため、キャッシュがウォームアップされているかどうかを監視する最適な方法は、:ref:`Snowsightクエリプロファイル<label-snowsight_query_profile>`でリモートの読み取り率を確認することです。クエリ演算子の統計へのプログラムによるアクセスについては、:doc:`GET_QUERY_OPERATOR_STATS </sql-reference/functions/get_query_operator_stats>`を参照してください。理想的な実行シナリオでは、低レイテンシクエリのリモート読み取り率は0%である必要があります。

インタラクティブウェアハウスからのインタラクティブテーブルの削除¶

インタラクティブウェアハウスから1つ以上のインタラクティブテーブルをデタッチするには、 DROP TABLES 句を使用して ALTER WAREHOUSE コマンドを実行します。

ALTER WAREHOUSE interactive_demo DROP TABLES (orders, customers);

ポイントルックアップでの検索最適化の使用¶

インタラクティブテーブルでポイントルックアップクエリを実行する場合は、検索最適化</user-guide/search-optimization/enabling>`を追加することをお勧めします。ポイントルックアップは、1つまたは数行のデータを取得するために単一の列でフィルタリングするクエリです。良い例として ``WHERE some_id = some_UUID` があります。

インタラクティブマテリアライズドビューのベストプラクティス¶

インタラクティブテーブルを使用してマテリアライズドビューを作成する場合は、以下のガイドラインに従ってください。

• インタラクティブマテリアライズドビューは、通常のマテリアライズドビューと同様に機能します。インタラクティブテーブルに基づいている必要があります。

• インタラクティブマテリアライズドビューとその基になるソースインタラクティブテーブルは、同じインタラクティブウェアハウスに追加する必要があります。そうしないと、インタラクティブウェアハウスからそのようなマテリアライズドビューに対してクエリを実行すると、:code:`object not found`というエラーが表示されます。

• 結合は、インタラクティブまたは標準のいずれのマテリアライズドビューでもサポートされません。単一のベーステーブルから集計またはフィルタリングを行うようにクエリを構成してください。

• インタラクティブテーブルやインタラクティブマテリアライズドビューを、:doc:`動的テーブル</user-guide/dynamic-tables-about>`のソースとして使用することはできません。

• インタラクティブマテリアライズドビューの候補を検討する際は、頻繁に実行され、計算コストが高い集計クエリを選択してください。

インタラクティブウェアハウスの再開と一時停止¶

次のコマンドは、インタラクティブウェアハウスを再開します。ウェアハウスは一時停止状態で作成されるため、作成後にこれを行う必要があります。

ALTER WAREHOUSE interactive_demo RESUME;

また、ウェアハウスを手動で一時停止した場合は、同じようにしてウェアハウスを介してクエリの実行を開始します。

再開後のキャッシュのウォームアップ中、クエリは遅くなります。そのテーブルにあるデータの量によっては、数分から1時間ほどかかる場合があります。

次のコマンドは、インタラクティブウェアハウスを一時停止します。

ALTER WAREHOUSE interactive_demo SUSPEND;

CREATE INTERACTIVE WAREHOUSE interactive_demo
  WAREHOUSE_SIZE = 'XSMALL'
  AUTO_SUSPEND = 86400
  AUTO_RESUME = TRUE;

ALTER WAREHOUSE interactive_demo SET
  AUTO_SUSPEND = 86400
  AUTO_RESUME = TRUE;

タスクベースのマルチクラスターのサイズ設定¶

スケジュールされたタスクを使用してMIN_CLUSTER_COUNTパラメーターを調整できます。

-- 1) Task to scale OUT during business hours
CREATE OR REPLACE TASK mcw_scale_out_morning
  WAREHOUSE = my_wh          -- the warehouse that *executes the task*
  SCHEDULE = 'USING CRON 0 8 * * * UTC'   -- 08:00 UTC daily
AS
  ALTER WAREHOUSE my_wh      -- the warehouse you want to change (can be same or different)
    SET
      MIN_CLUSTER_COUNT = 10;  -- optional: ECONOMY or STANDARD

-- 2) Task to scale IN after hours
CREATE OR REPLACE TASK mcw_scale_in_evening
  WAREHOUSE = my_wh
  SCHEDULE = 'USING CRON 0 20 * * * UTC'  -- 20:00 UTC daily
AS
  ALTER WAREHOUSE my_wh
    SET
      MIN_CLUSTER_COUNT = 2;

自動スケーリングポリシーを使用して、ワークロードの同時実行のピークに対応するようにMAX_CLUSTER_COUNTを設定することをお勧めします。

インタラクティブウェアハウスのドロップ¶

DROP WAREHOUSE コマンドを実行して、インタラクティブウェアハウスを完全に削除することができます。インタラクティブウェアハウスをドロップすると、そのウェアハウスとインタラクティブテーブルとの関連付けが削除されます。ただし、他のインタラクティブウェアハウスを使用して、それらの同じインタラクティブテーブルをクエリすることはできます。

インタラクティブテーブルのクエリ¶

クエリセッションでは、現在のセッションのウェアハウスがインタラクティブウェアハウスであることを確認してください。

USE WAREHOUSE interactive_demo;

確認後、インタラクティブテーブルを通常通りにクエリできます。

ベンチマークのベストプラクティス¶

テスト環境でインタラクティブテーブルのパフォーマンスを評価する場合は、一貫性のない、または誤解を招く結果を避けるために、次のベストプラクティスに従ってください。

• クエリ結果キャッシュをオフにして、複数のベンチマーク実行間でベンチマーク結果の一貫性を確保します。USE_CACHED_RESULT セッションパラメーターを設定すると、アカウント、ユーザー、セッションレベルでクエリ結果キャッシュをオフにできます。そうすることで、クエリはインタラクティブウェアハウスのテーブルデータキャッシュのみを使用します。実稼働環境で結果キャッシュをオンにすると、ベンチマークテストと同等以上のパフォーマンスが期待できます。

• インタラクティブなウェアハウスはテーブルデータキャッシュを準備するのに時間がかかるため、インタラクティブなウェアハウスを作成または再開してからクエリのパフォーマンスをテストするまでしばらく待ってください。これは、ウェアハウスが長期間アクティブであり続ける典型的な本番構成をシミュレートします。Snowflakeは、キャッシュの警告プロセスに最適化を適用します。したがって、サンプルクエリを実行してキャッシュを自分で準備するよりも、Snowflakeがこのプロセスを完了させる方が効率的です。

• インタラクティブテーブルのパフォーマンスを標準的なSnowflakeテーブルと比較する場合は、標準テーブルとインタラクティブテーブルの間でクエリをインターリーブしないでください。代わりに、標準テーブルで完全なベンチマークを実行してから、インタラクティブテーブルで同じテストを実行します。

• 他のデータベースシステムと比較してベンチマークを行う場合は、インタラクティブテーブルのクラスタリング列がクエリのWHERE句の述語と一致していることを確認してください。最適なクラスタリング列の選択の詳細については、 クラスタリングキーとクラスタ化されたテーブル を参照してください。特に、一意のIDsまたはタイムスタンプなど、カーディナリティの高い列でクラスター化しないでください。

• クエリが短く単純な場合は、インタラクティブウェアハウス向けの MAX_CONCURRENCY_LEVEL パラメーターをより高い値に設定すると、より高い同時実行性を実現できます。

インタラクティブウェアハウスの制限¶

• Snowflakeインタラクティブウェアハウスは、短時間実行されるクエリに合わせて最適化されています。SELECT コマンドのクエリのタイムアウトは、デフォルトで5秒です。5秒後、クエリはキャンセルされます。クエリのタイムアウト値を減らすことはできますが、増やすことはできません。これは、長時間実行されるクエリがインタラクティブウェアハウスのリソースを枯渇させ、低レイテンシクエリのパフォーマンスを低下させることを防ぐための仕様です。SHOWやINSERT OVERWRITEなどの特定の種類のコマンドは、5秒間のタイムアウト間隔の対象外です。

• クエリが常にタイムアウトする場合は、インタラクティブウェアハウスでの使用に適していない可能性があることを示しています。一般に、パフォーマンスチューニングテクニックのいくつかを適用すると、クエリのレイテンシを短縮できます。詳細については、:ref:`label-interactive_performance_considerations`を参照してください。

• インタラクティブウェアハウスは、24時間（86400秒）の最小自動一時停止間隔で、自動一時停止と自動再開をサポートします。インタラクティブウェアハウスを再開すると、データキャッシュの再ウォームアップが必要になるため、クエリに大幅なレイテンシが生じることが予想されます。詳細については、 インタラクティブウェアハウスの再開と一時停止 をご参照ください。

• インタラクティブウェアハウスから標準のSnowflakeテーブルをクエリすることはできません。同じセッションで標準テーブルとインタラクティブテーブルの両方をクエリするには、:doc:`USE WAREHOUSE </sql-reference/sql/use-warehouse>`を実行して適切なウェアハウスタイプに切り替えます。

• インタラクティブウェアハウスには最大10個のインタラクティブテーブルを追加できます。これは、システムの過負荷を防ぐための一時的な制限です。この制限は将来引き上げられる予定です。10個を超えるインタラクティブテーブルを追加する必要がある場合は、Snowflakeサポートにお問い合わせください。

• CALLコマンド を実行して、インタラクティブウェアハウスでストアドプロシージャを呼び出すことはできません。

• ->> :doc:`パイプ演算子</sql-reference/operators-flow>`は使用できません。その演算子は、バックグラウンドでストアドプロシージャを使用します。

インタラクティブテーブルの制限¶

• インタラクティブテーブルは以下の機能をサポートしていません。

  • UPDATEおよびDELETEなどの データ操作言語（DML）コマンド 。推奨されるワークフローは、自動リフレッシュインタラクティブテーブルを使用し（つまり、TARGET_LAGを設定する）、代わりにソーステーブルにDMLを適用することです。自動リフレッシュメカニズムは、インタラクティブテーブルでDMLを使用するよりも効率的で費用対効果が高くなります。実行できる DML は INSERT OVERWRITE だけです。

  • Fail-safe。このデータ復旧メカニズムはインタラクティブテーブルでは使用できません。ただし、インタラクティブテーブルではTime Travelを引き続き使用できます。

  • 行のタイムスタンプ。インタラクティブテーブルで行タイムスタンプを有効にすることはできません。これは一時的な制限です。

  • クエリインサイト。現在のところ、クエリ実行のレイテンシを短縮するために、インタラクティブテーブルで実行されるクエリに対してクエリインサイトは収集されず、利用することもできません。

• 以下の操作は実行できません。

  • 標準（非インタラクティブ）マテリアライズドビューのソースとして、インタラクティブテーブルを使用する。インタラクティブテーブルでマテリアライズドビューを作成するには、INTERACTIVEキーワードを使用します。インタラクティブテーブルのマテリアライズドビューのサポート をご参照ください。

  • ADD COLUMNまたはREMOVE COLUMNなどの ALTER TABLE 句を使用して、インタラクティブテーブルのプロパティを変更します。実行 できる ALTER TABLE 操作は以下の通りです。

    • テーブルの名前を変更する。

    • コメントを設定または設定解除するために列を変更する。

    • 列のマスキングポリシーを設定または設定解除する。

    • テーブルに対する マスキングポリシー 、 結合ポリシー 、 集約ポリシー 、または 行アクセスポリシー を追加または設定解除する。

    • テーブルに ストレージライフサイクルポリシー を追加、またはテーブルからストレージライフサイクルポリシーにドロップする。

  • インタラクティブテーブルで ストリーム を使用する。

  • ベーステーブルとしてインタラクティブテーブルを使用して 動的テーブル を作成する。

  • インタラクティブテーブルのクエリに RESAMPLE句 を使用する。

  • CREATE INTERACTIVE TABLEまたはALTER TABLEを使用してTime Travel保持期間を設定する。インタラクティブなテーブルは、親スキーマ、データベース、またはアカウントからDATA_RETENTION_TIME_IN_DAYS値を継承します。