Retours d’expérience - vues matérialisées

Exemples concrets de vues matérialisées, problèmes et solutions

Ce guide fait partie d’une collection d’enseignements issus de rencontres de la communauté. Pour découvrir d’autres solutions et retours d’expérience concrets, vous pouvez parcourir les contenus par problème spécifique. Trop de parts ralentissent votre base de données ? Consultez le guide communautaire Too Many Parts. En savoir plus sur les Vues matérialisées.

​

L’anti-pattern du stockage x10

Problème réel en production : “Nous avions une vue matérialisée. La table brute de logs faisait environ 20 Go, mais la vue créée à partir de cette table de logs est montée à 190 Go, soit presque 10x la taille de la table brute. Cela s’est produit parce que nous créions une ligne par attribut, et chaque log peut avoir 10 attributs.”

Règle : Si votre GROUP BY crée plus de lignes qu’il n’en élimine, vous êtes en train de construire un index coûteux, pas une vue matérialisée.

​

Validation de la santé d’une vue matérialisée en production

Cette requête vous aide à prévoir si une vue matérialisée va compresser vos données ou les faire exploser avant sa création. Exécutez-la sur votre table et vos colonnes réelles pour éviter le scénario de « l’explosion à 190 Go ».

Ce qu’elle montre :

• Faible ratio d’agrégation (<10 %) = Bonne MV, compression significative
• Ratio d’agrégation élevé (>70 %) = Mauvaise MV, risque d’explosion du stockage
• Multiplicateur de stockage = Dans quelle mesure votre MV sera plus grande ou plus petite

-- 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

​

Quand les vues matérialisées deviennent un problème

Signes avant-coureurs à surveiller :

• La latence d’insertion augmente (des requêtes qui prenaient 10 ms prennent désormais plus de 100 ms)
• Les erreurs “Too many parts” apparaissent plus fréquemment
• Des pics de CPU se produisent pendant les opérations d’insertion
• Des timeouts d’insertion surviennent alors qu’ils ne se produisaient pas auparavant

Vous pouvez comparer les performances d’insertion avant et après l’ajout de MV à l’aide de system.query_log pour suivre l’évolution de la durée des requêtes.

​

Sources vidéo

• ClickHouse at CommonRoom - Kirill Sapchuk - Source de l’étude de cas « trop enthousiaste à propos des vues matérialisées » et de « l’explosion de 20GB→190GB »