[go: up one dir, main page]
メインコンテンツまでスキップ
メインコンテンツまでスキップ

使用 Materialized Views

ClickHouseは、増分 と リフレッシュ可能 の2種類のマテリアライズドビューをサポートしています。どちらも結果を事前に計算して保存することでクエリを加速するように設計されていますが、基底クエリが実行される方法やタイミング、適しているワークロード、データの新鮮さの処理方法において大きな違いがあります。

ユーザーは、型に関する以前のベストプラクティス に従い、および 主キーの最適化 が実施されていることを前提に、特定のクエリパターンの加速にマテリアライズドビューを考慮する必要があります。

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

Materialized Views

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

Refreshable materialized view diagram

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

増分マテリアライズドビューを使用するタイミング​

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

増分マテリアライズドビューを使用する場合：

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

増分マテリアライズドビューの例は、こちらをご覧ください。

リフレッシュ可能なマテリアライズドビューを使用するタイミング​

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

これらは、クエリのパフォーマンスが重要であり（例：ミリ秒未満のレイテンシ）、わずかに古い結果が受け入れられる場合に最も有用です。クエリが完全に再実行されるため、リフレッシュ可能なビューは、比較的速く計算できるクエリか、時間間隔が長く計算できるクエリ（例：毎時）に最も適しています。これには「トップN」結果をキャッシュすることやルックアップテーブルが含まれます。

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

要約​

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

  • キャッシュされたクエリ結果を即座に利用したいが、新鮮さにおいて小さな遅延が許容されます。
  • クエリ結果セットのトップNが必要です。
  • 結果セットのサイズが時間の経過とともに無限に成長しないことを確認してください。これはターゲットビューのパフォーマンスを低下させる可能性があります。
  • 複数のテーブルを含む複雑な結合や非正規化を実行しており、いずれかのソーステーブルが変更されるたびに更新が必要です。
  • バッチワークフロー、非正規化タスク、またはDBT DAGに類似したビューの依存関係を構築しています。

リフレッシュ可能なマテリアライズドビューの例は、こちらをご覧ください。

APPEND vs REPLACE モード​

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

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

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

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

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

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

  • 最新の結果だけが必要です。
  • 古いデータは完全に破棄されるべきです。
  • ビューが現在の状態やルックアップを表している。

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