Vues matérialisées versus projections

Une question fréquemment posée par les utilisateurs est de savoir à quel moment il convient d’utiliser des vues matérialisées plutôt que des projections. Dans cet article, nous allons passer en revue les principales différences entre les deux et expliquer pourquoi, selon les cas, vous pouvez préférer l’une à l’autre.

• Vous travaillez avec des pipelines de données ETL en temps réel et en plusieurs étapes : vous devez effectuer des transformations complexes, des agrégations, ou acheminer les données à mesure qu’elles arrivent, éventuellement sur plusieurs étapes en chaînant des vues.
• Vous avez besoin d’une dénormalisation complexe : vous devez effectuer à l’avance des jointures entre des données provenant de plusieurs sources (tables, sous-requêtes ou dictionnaires) dans une seule table optimisée pour les requêtes, en particulier si des reconstructions complètes périodiques à l’aide de vues matérialisées actualisables sont acceptables.
• Vous souhaitez un contrôle explicite du schéma : vous avez besoin d’une table cible distincte avec son propre schéma et son propre moteur pour les résultats précalculés, offrant une plus grande souplesse pour la modélisation des données.
• Vous souhaitez filtrer à l’ingestion : vous devez filtrer les données avant qu’elles ne soient matérialisées, ce qui réduit le volume de données écrites dans la table cible.

• Les données source sont fréquemment mises à jour ou supprimées : sans stratégies supplémentaires pour gérer la cohérence entre la table source et la table cible, les vues matérialisées incrémentales peuvent devenir obsolètes et incohérentes.
• Vous privilégiez la simplicité et l’optimisation automatique : si vous voulez éviter de gérer des tables cibles distinctes.

• Optimiser les requêtes sur une seule table : votre objectif principal est d’accélérer les requêtes sur une seule table de base en proposant d’autres ordres de tri, en optimisant les filtres sur des colonnes qui ne font pas partie de la clé primaire, ou en précalculant des agrégations pour une seule table.
• Vous recherchez la transparence des requêtes : vous voulez que les requêtes ciblent la table d’origine sans modification, en laissant ClickHouse choisir la meilleure organisation des données pour une requête donnée.

• Des transformations de données complexes ou un ETL en plusieurs étapes sont nécessaires : les définitions de projection ne prennent pas en charge les opérations JOIN, ne peuvent pas être enchaînées pour construire des pipelines en plusieurs étapes et ne peuvent pas gérer certaines fonctionnalités SQL, comme les fonctions de fenêtre ou les instructions CASE complexes. Bien que les requêtes sur des tables avec projections puissent effectuer librement des jointures, les projections elles-mêmes ne sont pas adaptées aux transformations de données complexes.
• Un filtrage explicite des données matérialisées est nécessaire : les projections ne prennent pas en charge les clauses WHERE dans leur définition pour filtrer les données matérialisées dans la projection elle-même.
• Des moteurs de table autres que MergeTree sont utilisés : les projections sont exclusivement disponibles pour les tables utilisant la famille de moteurs MergeTree.
• Les requêtes FINAL sont essentielles : les projections ne fonctionnent pas avec les requêtes FINAL, qui sont parfois utilisées pour la déduplication.
• Vous avez besoin de répliques parallèles, car elles ne sont pas prises en charge avec les projections.