31 KiB
| slug | sidebar_position | sidebar_label |
|---|---|---|
| /ja/sql-reference/statements/create/view | 37 | VIEW |
CREATE VIEW
新しいビューを作成します。ビューは通常のビュー、Materialized View、リフレッシュ可能なMaterialized View、およびウィンドウビュー（リフレッシュ可能なMaterialized Viewとウィンドウビューはエクスペリメンタル機能です）であることができます。
通常のビュー
構文:
CREATE [OR REPLACE] VIEW [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster_name]
[DEFINER = { user | CURRENT_USER }] [SQL SECURITY { DEFINER | INVOKER | NONE }]
AS SELECT ...
[COMMENT 'comment']
通常のビューはデータを保存しません。アクセスするたびに他のテーブルからの読み取りを実行します。つまり、通常のビューは保存されたクエリにすぎません。ビューから読み取ると、この保存されたクエリがFROM句内のサブクエリとして使用されます。
例として、次のビューを作成したとします。
CREATE VIEW view AS SELECT ...
そして、クエリを記述しました。
SELECT a, b, c FROM view
このクエリは、次のサブクエリを使用するのと完全に同等です。
SELECT a, b, c FROM (SELECT ...)
パラメータ化ビュー
パラメータ化ビューは通常のビューに似ていますが、すぐには解決されないパラメータを持って作成することができます。これらのビューは、ビューの名前を関数名として、パラメータの値を引数として指定するテーブル関数で使用できます。
CREATE VIEW view AS SELECT * FROM TABLE WHERE Column1={column1:datatype1} and Column2={column2:datatype2} ...
上記は、下記のようにパラメータを代入することでテーブル関数として使用できるテーブルのビューを作成します。
SELECT * FROM view(column1=value1, column2=value2 ...)
マテリアライズドビュー
CREATE MATERIALIZED VIEW [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster_name] [TO[db.]name] [ENGINE = engine] [POPULATE]
[DEFINER = { user | CURRENT_USER }] [SQL SECURITY { DEFINER | INVOKER | NONE }]
AS SELECT ...
[COMMENT 'comment']
:::tip Materialized Viewを使用するステップバイステップガイドはこちらです。 :::
Materialized Viewは、対応するSELECTクエリによって変換されたデータを保存します。
TO [db].[table]なしでMaterialized Viewを作成する場合は、データ格納のためのテーブルエンジンENGINEを指定しなければなりません。
TO [db].[table]でMaterialized Viewを作成する場合、POPULATEを同時に使用することはできません。
Materialized Viewは次のように実装されています: SELECTで指定されたテーブルにデータを挿入すると、挿入されたデータの一部がこのSELECTクエリによって変換され、その結果がビューに挿入されます。
:::note
ClickHouseのMaterialized Viewは挿入先テーブルへのデータ挿入時にカラム名を使用します。SELECTクエリ結果に存在しないカラム名がある場合、たとえカラムがNullableでなくても、ClickHouseはデフォルト値を使用します。Materialized Viewを使用する際には、全てのカラムに別名を付けることが安全なプラクティスとされます。
ClickHouseのMaterialized Viewは、主に挿入トリガーのように実装されています。ビュークエリに集約がある場合、それは新しく挿入されたデータバッチにのみ適用されます。ソーステーブルの既存データへの変更（例えば、更新、削除、パーティション削除など）は、Materialized Viewを変更しません。
エラー発生時にClickHouseのMaterialized Viewは決定的な振る舞いを持ちません。つまり、すでに書き込まれたブロックは保存されますが、エラー後の全てのブロックは保存されません。
デフォルトでは一つのビューへのプッシュが失敗した場合、INSERTクエリも失敗し、いくつかのブロックはデータ格納先テーブルに書き込まれないかもしれません。これはmaterialized_views_ignore_errors設定を使用して変更できます（これはINSERTクエリのために設定する必要があります）。materialized_views_ignore_errors=trueに設定すると、ビューへのプッシュ時の全てのエラーは無視され、全てのブロックはデータ格納先テーブルに書き込まれます。
また、デフォルトでsystem.*_logテーブルにはmaterialized_views_ignore_errorsがtrueに設定されています。
:::
POPULATEを指定すると、既存のテーブルデータがビュー作成時にビューに挿入されます。それはちょうどCREATE TABLE ... AS SELECT ...を実行するようなものです。それ以外の場合、ビューが作成された後にテーブルに挿入されたデータのみをクエリします。ビュー作成中にテーブルに挿入されたデータがビューに挿入されないため、POPULATEの使用をおすすめしません。
:::note
POPULATEがCREATE TABLE ... AS SELECT ...のように機能することを考えると、いくつかの制限があります:
- レプリケートされたデータベースでのサポートはありません
- ClickHouseクラウドでのサポートはありません
代わりに個別のINSERT ... SELECTを使用できます。
:::
SELECTクエリにはDISTINCT、GROUP BY、ORDER BY、LIMITを含めることができます。但し、対応する変換は挿入されたデータの各ブロックごとに独立して実行されることに注意してください。例えば、GROUP BYが設定されている場合、データは挿入中に集約されますが、挿入されたデータのパケット内でのみ適用されます。データはそれ以上集約されません。ただし、独立してデータ集約を行うSummingMergeTreeのようなエンジンを使用する場合は例外です。
ALTERクエリをMaterialized Viewに対して実行することには限界があります。例えば、SELECTクエリを更新することはできませんので、これが不便になる可能性があります。Materialized ViewがTO [db.]nameの構文を使用している場合、ビューをDETACHしてからターゲットテーブルに対してALTERを実行し、その後に以前にDETACHしたビューをATTACHできます。
Materialized Viewはoptimize_on_insert設定によって影響を受けます。データはビューへの挿入前にマージされます。
ビューは通常のテーブルと同様に見えます。例えば、SHOW TABLESクエリの結果にリストされます。
ビューを削除するには、DROP VIEWを使用します。ただし、DROP TABLEもビューに対して機能します。
SQLセキュリティ
DEFINERとSQL SECURITYにより、ビューの基礎となるクエリを実行するときに使用するClickHouseユーザーを指定できます。SQL SECURITYには、DEFINER、INVOKER、NONEの3つの合法な値があります。DEFINER句には、任意の既存のユーザーまたはCURRENT_USERを指定できます。
以下の表は、どのユーザーがビューから選択する権限が必要かを説明します。SQLセキュリティオプションに関係なく、ビューから読み取るためにはGRANT SELECT ON <view>が必要であることに注意してください。
| SQLセキュリティオプション | ビュー | マテリアライズドビュー |
|---|---|---|
DEFINER alice |
aliceはビューのソーステーブルに対するSELECT権限が必要です。 |
aliceはビューのソーステーブルに対するSELECT権限とビューのターゲットテーブルに対するINSERT権限が必要です。 |
INVOKER |
ユーザーはビューのソーステーブルに対するSELECT権限が必要です。 |
Materialized ViewにはSQL SECURITY INVOKERを指定できません。 |
NONE |
- | - |
:::note
SQL SECURITY NONEは廃止予定のオプションです。このオプションでビューを作成する権限を持つユーザーは、任意のクエリを実行することができます。したがって、このオプションでビューを作成するためには、GRANT ALLOW SQL SECURITY NONE TO <user>が必要です。
:::
DEFINER/SQL SECURITYが指定されていない場合、デフォルト値が使用されます:
DEFINER/SQL SECURITYが指定されずにビューがアタッチされた場合、Materialized Viewにはデフォルト値としてSQL SECURITY NONE、通常のビューにはSQL SECURITY INVOKERが使用されます。
既存のビューのSQLセキュリティを変更するには、以下を使用します。
ALTER TABLE MODIFY SQL SECURITY { DEFINER | INVOKER | NONE } [DEFINER = { user | CURRENT_USER }]
例
CREATE VIEW test_view
DEFINER = alice SQL SECURITY DEFINER
AS SELECT ...
CREATE VIEW test_view
SQL SECURITY INVOKER
AS SELECT ...
ライブビュー [廃止予定]
この機能は廃止予定であり、将来的に削除される予定です。
利便性のため、古いドキュメントはこちらにあります。
リフレッシュ可能なMaterialized View [エクスペリメンタル]
CREATE MATERIALIZED VIEW [IF NOT EXISTS] [db.]table_name
REFRESH EVERY|AFTER interval [OFFSET interval]
RANDOMIZE FOR interval
DEPENDS ON [db.]name [, [db.]name [, ...]]
SETTINGS name = value [, name = value [, ...]]
[APPEND]
[TO[db.]name] [(columns)] [ENGINE = engine] [EMPTY]
AS SELECT ...
[COMMENT 'comment']
ここでintervalは単純な間隔のシーケンスです:
number SECOND|MINUTE|HOUR|DAY|WEEK|MONTH|YEAR
定期的に対応するクエリを実行し、その結果をテーブルに格納します。
- クエリに
APPENDが書かれている場合、各リフレッシュでは既存の行を削除せずに行をテーブルに挿入します。通常のINSERT SELECTと同様、挿入はアトミックではありません。 - それ以外の場合、各リフレッシュはテーブルの以前の内容をアトミックに置き換えます。
通常の非リフレッシュ可能なMaterialized Viewとの違い:
- 挿入トリガーがありません。すなわち、SELECTで指定されたテーブルに新しいデータが挿入されても、リフレッシュ可能なMaterialized Viewには自動的にはプッシュされません。定期的なリフレッシュがクエリ全体を実行します。
- SELECTクエリに制限がありません。テーブル関数（例えば
url()）、ビュー、UNION、JOINがすべて許可されます。
:::note
クエリのREFRESH ... SETTINGS部分にある設定はリフレッシュ設定（例: refresh_retries）であり、通常の設定（例: max_threads）とは異なります。通常の設定は、クエリの終了部分にあるSETTINGSを使用して指定できます。
:::
リフレッシュスケジュール
リフレッシュスケジュールの例:
REFRESH EVERY 1 DAY -- 毎日、午前0時（UTC）
REFRESH EVERY 1 MONTH -- 毎月1日、午前0時に
REFRESH EVERY 1 MONTH OFFSET 5 DAY 2 HOUR -- 毎月6日、午前2時に
REFRESH EVERY 2 WEEK OFFSET 5 DAY 15 HOUR 10 MINUTE -- 2週間ごとに土曜日、午後3:10に
REFRESH EVERY 30 MINUTE -- 00:00、00:30、01:00、01:30、などで
REFRESH AFTER 30 MINUTE -- 前のリフレッシュが完了してから30分後、日付に合わせて調整されません
-- REFRESH AFTER 1 HOUR OFFSET 1 MINUTE -- AFTERではOFFSETは許可されていないため、構文エラー
REFRESH EVERY 1 WEEK 2 DAYS -- 9日ごと、特定の曜日や月に制約なし;
-- 特に、1969-12-29以降の日数が9で割り切れるとき
REFRESH EVERY 5 MONTHS -- 毎5ヶ月、毎年異なる月（12は5で割り切れないため）;
-- 特に、1970-01以降の月数が5で割り切れるとき
RANDOMIZE FORは各リフレッシュの時間をランダムに調整します。例:
REFRESH EVERY 1 DAY OFFSET 2 HOUR RANDOMIZE FOR 1 HOUR -- 毎日午前1:30から2:30の間のランダムな時間
特定のビューについて、同時に一つのみのリフレッシュを実行可能です。例: REFRESH EVERY 1 MINUTEのビューがリフレッシュに2分かかる場合、2分ごとにリフレッシュします。その後、10秒でリフレッシュが完了する場合、1分ごとに戻ります。（特に、バックログのすべてをカバーするために10秒ごとにリフレッシュされることはありません - そのようなバックログはありません。）
さらに、CREATEクエリで作成されるとリフレッシュは直ちに開始されますが、EMPTYが指定されている場合は最初のリフレッシュはスケジュールに従って行われます。
レプリケートデータベースでの動作
リフレッシュ可能なMaterialized Viewがレプリケートデータベースにある場合、レプリカ同士で調整して、スケジュールされた時間に1つのレプリカのみがリフレッシュを実行するようになります。ReplicatedMergeTreeテーブルエンジンが必要ですので、全てのレプリカがリフレッシュによって生成されたデータを参照できます。
APPENDモードでは、SETTINGS全てのレプリカ=1を使用して調整を無効にできます。これにより、レプリカは互いに独立してリフレッシュを実行します。この場合、ReplicatedMergeTreeは必要ありません。
非APPENDモードでは、調整されたリフレッシュのみがサポートされています。非調整されたリフレッシュには、AtomicデータベースとCREATE ... ON CLUSTERクエリを使用して、すべてのレプリカでリフレッシュ可能なMaterialized Viewを作成します。
調整はKeeperによって行われます。znodeパスはdefault_replica_pathサーバー設定によって決定されます。
依存関係
DEPENDS ONは異なるテーブルのリフレッシュを同期します。たとえば、次のような2つのリフレッシュ可能なMaterialized Viewのチェーンがあるとします:
CREATE MATERIALIZED VIEW source REFRESH EVERY 1 DAY AS SELECT * FROM url(...)
CREATE MATERIALIZED VIEW destination REFRESH EVERY 1 DAY AS SELECT ... FROM source
DEPENDS ONなしでは、両方のビューが真夜中にリフレッシュを開始し、destinationは通常、sourceの昨日のデータを参照します。依存関係を追加すると:
CREATE MATERIALIZED VIEW destination REFRESH EVERY 1 DAY DEPENDS ON source AS SELECT ... FROM source
destinationのリフレッシュは、sourceの同日のリフレッシュが完了した後にのみ開始されるので、destinationは新鮮なデータに基づくことになります。
または、同じ結果を以下で達成できます:
CREATE MATERIALIZED VIEW destination REFRESH AFTER 1 HOUR DEPENDS ON source AS SELECT ... FROM source
ここでの1 HOURはsourceのリフレッシュ期間より短ければ任意の長さに設定できます。依存するテーブルは、依存するテーブルのリフレッシュ率より頻繁にリフレッシュされることはありません。これは、リフレッシュ可能なビューのチェーンを実際のリフレッシュ期間を指定することなく設定するための有効な方法です。
いくつかのさらなる例:
REFRESH EVERY 1 DAY OFFSET 10 MINUTE（destination）がREFRESH EVERY 1 DAY（source）に依存
sourceのリフレッシュが10分以上かかる場合、destinationは待機します。REFRESH EVERY 1 DAY OFFSET 1 HOURがREFRESH EVERY 1 DAY OFFSET 23 HOURに依存
上記と同様に、対応するリフレッシュが異なるカレンダー日に起こるにもかかわらず。destinationのリフレッシュは日X+1の日に始まり、sourceの日Xのリフレッシュを（それが2時間以上かかる場合）待機します。REFRESH EVERY 2 HOURがREFRESH EVERY 1 HOURに依存
2時間ごとのリフレッシュは、一時間ごとのリフレッシュの後に行われます。例えば、真夜中のリフレッシュの後、次に午前2時のリフレッシュの後等。REFRESH EVERY 1 MINUTEがREFRESH EVERY 2 HOURに依存
REFRESH AFTER 1 MINUTEがREFRESH EVERY 2 HOURに依存
REFRESH AFTER 1 MINUTEがREFRESH AFTER 2 HOURに依存
destinationはsourceの各リフレッシュ後に一度リフレッシュされます。すなわち、2時間ごと。1 MINUTEは実質的に無視されます。REFRESH AFTER 1 HOURがREFRESH AFTER 1 HOURに依存
現在、これは推奨されていません。
:::note
DEPENDS ONはリフレッシュ可能なMaterialized View間でのみ機能します。通常のテーブルをDEPENDS ONリストに記載すると、ビューが一切リフレッシュされなくなります（依存関係はALTERで削除できます、下記参照）。
:::
設定
利用可能なリフレッシュ設定:
refresh_retries- リフレッシュクエリが例外を伴って失敗した場合に再試行する回数。すべての再試行に失敗した場合、次のスケジュールされたリフレッシュ時間にスキップします。0は再試行なしを意味し、-1は無限の再試行を意味します。デフォルト: 0。refresh_retry_initial_backoff_ms-refresh_retriesがゼロでない場合、最初の再試行前の遅延。各再試行ごとに遅延が倍増し、refresh_retry_max_backoff_msまで続きます。デフォルト: 100 ms。refresh_retry_max_backoff_ms- リフレッシュ試行間の遅延の指数増加の限界。デフォルト: 60000 ms（1分）。
リフレッシュパラメータの変更
リフレッシュパラメータを変更するには:
ALTER TABLE [db.]name MODIFY REFRESH EVERY|AFTER ... [RANDOMIZE FOR ...] [DEPENDS ON ...] [SETTINGS ...]
:::note
これは全リフレッシュパラメータ、スケジュール、依存関係、設定、およびAPPEND性を一度に置き換えます。例: テーブルにDEPENDS ONがあった場合、MODIFY REFRESHをDEPENDS ONなしで実行すると依存関係が削除されます。
:::
その他の操作
すべてのリフレッシュ可能なMaterialized Viewのステータスは、system.view_refreshesテーブルで利用可能です。具体的には、リフレッシュの進行状況（実行中の場合）、最後と次回のリフレッシュ時間、失敗した場合の例外メッセージが含まれています。
リフレッシュを手動で停止、開始、トリガー、またはキャンセルするには、SYSTEM STOP|START|REFRESH|CANCEL VIEWを使用します。
リフレッシュが完了するのを待つには、SYSTEM WAIT VIEWを使用します。特に、リフレッシュ可能なMaterialized Viewを作成した後の初期リフレッシュを待機するのに便利です。
:::note 豆知識: リフレッシュされているビューから前のバージョンのデータを読み取ることが許可されています。これで、コンウェイのライフゲームを実装できます: https://pastila.nl/?00021a4b/d6156ff819c83d490ad2dcec05676865#O0LGWTO7maUQIA4AcGUtlA== :::
ウィンドウビュー [エクスペリメンタル]
:::info
これは将来のリリースで後方互換性がない形で変更される可能性があるエクスペリメンタルな機能です。ウィンドウビューとWATCHクエリの使用を許可するには、allow_experimental_window_view設定を使用してset allow_experimental_window_view = 1を入力してください。
:::
CREATE WINDOW VIEW [IF NOT EXISTS] [db.]table_name [TO [db.]table_name] [INNER ENGINE engine] [ENGINE engine] [WATERMARK strategy] [ALLOWED_LATENESS interval_function] [POPULATE]
AS SELECT ...
GROUP BY time_window_function
[COMMENT 'comment']
ウィンドウビューはデータを時間ウィンドウ別に集約し、ウィンドウが準備が整ったときに結果を出力できます。中間集計結果を内部 (もしくは指定した) テーブルに保存してレイテンシを削減し、指定されたテーブルへのプッシュやWATCHクエリを使用して通知をプッシュすることができます。
ウィンドウビューの作成はMATERIALIZED VIEWの作成に似ています。ウィンドウビューは中間データを保存するために内部ストレージエンジンを必要とします。内部ストレージはINNER ENGINE句を使用して指定できます。ウィンドウビューはデフォルトの内部エンジンとしてAggregatingMergeTreeを使用します。
TO [db].[table]なしでウィンドウビューを作成する場合、データを保存するテーブルエンジンENGINEを指定しなければなりません。
時間ウィンドウ関数
時間ウィンドウ関数は、レコードの下限と上限ウィンドウを取得するために使用されます。ウィンドウビューは時間ウィンドウ関数と一緒に使用する必要があります。
タイムアトリビュート
ウィンドウビューは処理時間とイベント時間のプロセスをサポートします。
処理時間は、ウィンドウビューがローカルのマシンの時間に基づいて結果を生成できるようにします。これはデフォルトで使用され、最も基本的な時間概念ですが、決定性を提供しません。処理時間アトリビュートは、時間ウィンドウ関数のtime_attrをテーブルカラムに設定するか、または関数now()を使用して定義できます。次のクエリは処理時間を使用したウィンドウビューを作成します。
CREATE WINDOW VIEW wv AS SELECT count(number), tumbleStart(w_id) as w_start from date GROUP BY tumble(now(), INTERVAL '5' SECOND) as w_id
イベント時間は、各イベントがその制作装置で発生した時間です。この時間は、通常、レコードが生成されたときにその中に埋め込まれています。イベント時間処理は、順序が乱れたイベントや遅延イベントでも一貫した結果を得ることができます。ウィンドウビューは、WATERMARK構文を使用してイベント時間処理をサポートしています。
ウィンドウビューは、3つのウォーターマーク戦略を提供します:
STRICTLY_ASCENDING: これまでに観察された最大のタイムスタンプのウォーターマークを発行します。最大タイムスタンプより小さいタイムスタンプを持つ行は遅れていません。ASCENDING: これまでに観察された最大のタイムスタンプから1を引いたウォーターマークを発行します。最大タイムスタンプと等しいか小さいタイムスタンプを持つ行は遅れていません。BOUNDED: WATERMARK=INTERVAL。指定された遅延を引いた最大のタイムスタンプのウォーターマークを発行します。
以下のクエリは、WATERMARKを使用してウィンドウビューを作成する例です:
CREATE WINDOW VIEW wv WATERMARK=STRICTLY_ASCENDING AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
CREATE WINDOW VIEW wv WATERMARK=ASCENDING AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
CREATE WINDOW VIEW wv WATERMARK=INTERVAL '3' SECOND AS SELECT count(number) FROM date GROUP BY tumble(timestamp, INTERVAL '5' SECOND);
デフォルトでは、ウォーターマークが到達するとウィンドウが発生しますが、ウォーターマークを過ぎて到着した要素は削除されます。ウィンドウビューはALLOWED_LATENESS=INTERVALを設定して遅れたイベントの処理をサポートします。遅延処理の例は次のとおりです:
CREATE WINDOW VIEW test.wv TO test.dst WATERMARK=ASCENDING ALLOWED_LATENESS=INTERVAL '2' SECOND AS SELECT count(a) AS count, tumbleEnd(wid) AS w_end FROM test.mt GROUP BY tumble(timestamp, INTERVAL '5' SECOND) AS wid;
遅延で発行された要素は、以前の計算の更新結果として扱われるべきであることに注意してください。ウィンドウが終了したときではなく、遅延したイベントが到着したときにすぐにウィンドウが発生します。したがって、同じウィンドウに対して複数の出力が生じます。ユーザーはこれらの重複した結果を考慮するか、重複を排除する必要があります。
ウィンドウビューで指定されたSELECTクエリをALTER TABLE ... MODIFY QUERY文を使用して変更できます。ビューをウィンドウビューとともに使用する場合、またはTO [db.]name句とともに使用する場合、新しいSELECTクエリの結果となるデータ構造は元のSELECTクエリと同じでなければなりません。現在のウィンドウ内のデータは失われます。これは中間状態を再利用できないためです。
新しいウィンドウの監視
ウィンドウビューは、WATCHクエリをサポートして変更を監視するか、TO構文を使用して結果をテーブルに出力します。
WATCH [db.]window_view
[EVENTS]
[LIMIT n]
[FORMAT format]
WATCHクエリはLIVE VIEWと同様に動作します。LIMITを指定することで、クエリを終了する前に受信する更新の数を設定できます。EVENTS句を使用してWATCHクエリの短い形式を取得することができ、クエリ結果の代わりに最新のクエリウォーターマークを取得します。
設定
window_view_clean_interval: 古くなったデータを解放するためのウィンドウビューのクリーニング間隔（秒）。システムはシステム時間やWATERMARK設定に従って完全にトリガーされていないウィンドウを保持し、他のデータは削除されます。window_view_heartbeat_interval: ウォッチクエリがアクティブであることを示す心拍間隔（秒）。wait_for_window_view_fire_signal_timeout: イベント時間処理中にウィンドウビューの発火シグナルを待機するタイムアウト。
例
例えば、dataというログテーブルで10秒ごとにクリックログの数をカウントする必要があるとします。そのテーブル構造は以下の通りです。
CREATE TABLE data ( `id` UInt64, `timestamp` DateTime) ENGINE = Memory;
まず、10秒間隔のウィンドウを持つウィンドウビューを作成します。
CREATE WINDOW VIEW wv as select count(id), tumbleStart(w_id) as window_start from data group by tumble(timestamp, INTERVAL '10' SECOND) as w_id
次に、WATCHクエリを使って結果を取得します。
WATCH wv
ログがテーブルdataに挿入されると、
INSERT INTO data VALUES(1,now())
WATCHクエリは次のように結果を表示するはずです。
┌─count(id)─┬────────window_start─┐
│ 1 │ 2020-01-14 16:56:40 │
└───────────┴─────────────────────┘
または、TO構文を使用して出力を別のテーブルに関連付けることができます。
CREATE WINDOW VIEW wv TO dst AS SELECT count(id), tumbleStart(w_id) as window_start FROM data GROUP BY tumble(timestamp, INTERVAL '10' SECOND) as w_id
追加の例は、ClickHouseのステートフルテストの中で見つけることができます（それらは*window_view*とされています）。
ウィンドウビューの使用
ウィンドウビューは以下のシナリオで便利です:
- 監視: 時間単位でメトリクスログを集約・計算し、結果をターゲットテーブルに出力します。ダッシュボードはターゲットテーブルをソーステーブルとして使用できます。
- 分析: 時間ウィンドウでデータを自動的に集約し、前処理する。この処理は大量のログを分析する際に役立ちます。前処理によって複数のクエリでの反復計算が排除され、クエリの遅延が減少します。