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

Materialized views: how they can become a double edged sword

このガイドは、コミュニティミートアップから得られた知見のコレクションの一部です。現実的なソリューションと洞察については、特定の問題でブラウズすることができます。 データベースのパーツが多すぎて困っていますか？ パーツが多すぎるコミュニティの洞察ガイドをチェックしてください。 より詳細な情報は、Materialized Viewsをご覧ください。

The 10x storage anti-pattern​

実際のプロダクション問題: 「マテリアライズド ビューがありました。生のログテーブルは約20ギガですが、そのログテーブルからのビューは190ギガに膨れ上がり、生のテーブルのサイズの10倍近くになりました。これは、属性ごとに1行を作成していて、各ログには10の属性があるために発生しました。」

ルール: GROUP BY が削除する行よりも多くの行を作成する場合、高価なインデックスを構築しているだけで、マテリアライズドビューを構築しているわけではありません。

Production materialized view health validation​

このクエリは、マテリアライズド ビューを作成する前に、そのビューがデータを圧縮するか、膨張するかを予測するのに役立ちます。実際のテーブルとカラムに対して実行して、「190GBの爆発」を回避してください。

表示内容:

  • 低い集約比 (<10%) = 良いMV、重要な圧縮
  • 高い集約比 (>70%) = 悪いMV、ストレージ爆発のリスク
  • ストレージ倍率 = MVがどれほど大きくまたは小さくなるか
-- Replace with your actual table and columns
SELECT 
    count() as total_rows,
    uniq(your_group_by_columns) as unique_combinations,
    round(uniq(your_group_by_columns) / count() * 100, 2) as aggregation_ratio
FROM your_table
WHERE your_filter_conditions;

-- If aggregation_ratio > 70%, reconsider your MV design
-- If aggregation_ratio < 10%, you'll get good compression

When materialized views become a problem​

監視する警告サイン:

  • 挿入のレイテンシが増加（10msかかっていたクエリが現在は100ms以上かかる）
  • 「パーツが多すぎる」エラーが頻繁に発生
  • 挿入操作中のCPUスパイク
  • 以前は発生しなかった挿入タイムアウト

system.query_log を使用して、MVを追加する前後の挿入パフォーマンスを比較し、クエリの所要時間の傾向を追跡できます。

Video sources​