メインコンテンツまでスキップ
メインコンテンツまでスキップ

Materialized View

ClickHouseは2種類のマテリアライズドビューをサポートしています: インクリメンタル と リフレッシュ可能。どちらも結果を事前に計算して保存することでクエリを加速するように設計されていますが、基本となるクエリがどのように、またはいつ実行されるか、どのワークロードに適しているか、データの新鮮さがどのように扱われるかにおいて重要な違いがあります。

ユーザーは、前のベストプラクティス タイプに関する と 主キーの最適化 が実施されたと仮定して、加速する必要のある特定のクエリパターンについてマテリアライズドビューを検討する必要があります。

インクリメンタルマテリアライズドビューはリアルタイムで更新されます。新しいデータがソーステーブルに挿入されると、ClickHouseは自動的にマテリアライズドビューのクエリを新しいデータブロックに適用し、結果を別のターゲットテーブルに書き込みます。時間が経つにつれて、ClickHouseはこれらの部分的な結果をマージして完全で最新のビューを生成します。このアプローチは、計算コストを挿入時間にシフトし、新しいデータのみを処理するため非常に効率的です。その結果、ターゲットテーブルに対するSELECTクエリは高速で軽量です。インクリメンタルビューはすべての集約関数をサポートし、挿入されるデータセットの小さく最近のサブセットに対して各クエリが操作を行うため、ペタバイトのデータにもスケールします。

リフレッシュ可能なマテリアライズドビューは、対照的に、スケジュールで更新されます。これらのビューは定期的にフルクエリを再実行し、ターゲットテーブルの結果を上書きします。これは、Postgresのような従来のOLTPデータベースのマテリアライズドビューに似ています。

インクリメンタルとリフレッシュ可能なマテリアライズドビューの選択は、クエリの性質、データの変更頻度、ビューの更新が挿入されるたびにすべての行を反映する必要があるか、定期的なリフレッシュが許容されるかどうかに大きく依存します。これらのトレードオフを理解することが、ClickHouseでパフォーマンスが高くスケーラブルなマテリアライズドビューを設計するための鍵となります。

インクリメンタルマテリアライズドビューの使用時期​

インクリメンタルマテリアライズドビューは一般的に好まれます。これは、ソーステーブルに新しいデータが受け取られるたびにリアルタイムで自動的に更新されるからです。すべての集約関数をサポートしており、単一テーブルに対する集約に特に効果的です。挿入時に結果をインクリメンタルに計算することにより、クエリは大幅に小さなデータサブセットに対して実行され、これによりペタバイトのデータにもストレスなくスケールします。ほとんどの場合、全体的なクラスターのパフォーマンスに対して顕著な影響はありません。

インクリメンタルマテリアライズドビューは次の場合に使用すべきです:

  • 挿入のたびに更新されるリアルタイムのクエリ結果が必要な場合。
  • 大量のデータを頻繁に集約またはフィルタリングしている場合。
  • クエリが単一テーブルに対する簡単な変換または集約を含む場合。

インクリメンタルマテリアライズドビューの例については、こちらを参照してください。

リフレッシュ可能なマテリアライズドビューの使用時期​

リフレッシュ可能なマテリアライズドビューは、クエリをインクリメンタルではなく定期的に実行し、クエリ結果セットを高速に取得するために保存します。

これらは、クエリのパフォーマンスが重要で（例えば、サブミリ秒の待機時間）、わずかに古い結果が許容される場合に最も便利です。クエリが完全に再実行されるため、リフレッシュ可能なビューは、比較的高速に計算できるクエリや、頻繁には計算できないクエリ（例えば、毎時）、キャッシングされた「トップN」結果やルックアップテーブルなどに最も適しています。

実行頻度は、システムに過度の負荷がかからないように慎重に調整する必要があります。リソースを消費する非常に複雑なクエリは、慎重にスケジュールする必要があります - これらは、キャッシュに影響を与えたり、CPUとメモリを消費したりすることによって、全体のクラスターのパフォーマンスを悪化させる可能性があります。クエリは、リフレッシュ間隔に対して相対的に迅速に実行され、クラスターに負荷をかけないようにする必要があります。例えば、クエリ自体が計算に少なくとも10秒かかる場合、10秒ごとにビューを更新するようにスケジュールしないでください。

概要​

要約すると、リフレッシュ可能なマテリアライズドビューを使用するのは次の場合です:

  • 即時に利用できるキャッシュされたクエリ結果が必要であり、新鮮さのわずかな遅延が許容される場合。
  • クエリ結果セットのトップNが必要な場合。
  • 結果セットのサイズが時間とともに無制限に増加することがない場合。これにより、ターゲットビューのパフォーマンスが低下します。
  • 複数のテーブルを含む複雑な結合や非正規化を行い、ソーステーブルが変更されるたびに更新が必要な場合。
  • バッチワークフロー、非正規化タスク、DBT DAGsに似たビュー依存関係を構築している場合。

リフレッシュ可能なマテリアライズドビューの例については、こちらを参照してください。

APPENDとREPLACEモード​

リフレッシュ可能なマテリアライズドビューは、ターゲットテーブルにデータを書き込むための2つのモードをサポートします: APPENDとREPLACE。これらのモードは、ビューがリフレッシュされたときにクエリの結果がどのように書き込まれるかを定義します。

REPLACEはデフォルトの動作です。ビューがリフレッシュされるたびに、ターゲットテーブルの以前の内容は最新のクエリ結果で完全に上書きされます。これは、ビューが常に最新の状態を反映する必要がある場合に適しています。例えば、結果セットをキャッシュする場合などです。

対照的に、APPENDは、ターゲットテーブルの内容を置き換えるのではなく、新しい行をテーブルの末尾に追加することを許可します。これにより、定期的なスナップショットをキャプチャするなどの追加のユースケースが可能になります。APPENDは、各リフレッシュが異なる時点を示す場合や、結果の履歴蓄積が望ましい場合に特に便利です。

APPENDモードを選択する場合:

  • 過去のリフレッシュの履歴を保持したい場合。
  • 定期的なスナップショットやレポートを構築している場合。
  • 時間の経過とともにリフレッシュされた結果を段階的に収集する必要がある場合。

REPLACEモードを選択する場合:

  • 最も最近の結果のみが必要な場合。
  • 古いデータを完全に破棄する必要がある場合。
  • ビューが現在の状態またはルックアップを表している場合。

ユーザーは、メダリオンアーキテクチャを構築する際にAPPEND機能を適用することができます。