Set up docs MCPUne 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.
Résumé des principales différences
Le tableau ci-dessous résume les principales différences entre les vues matérialisées et les projections selon différents aspects à prendre en compte.
| Aspect | Vues matérialisées | Projections |
|---|---|---|
| Stockage et emplacement des données | Stockent leurs résultats dans une table cible distincte et explicite, en agissant comme des déclencheurs à l'insertion lors d'un INSERT dans une table source. |
Les projections créent des dispositions de données optimisées, physiquement stockées aux côtés des données de la table principale, et invisibles pour l'utilisateur. |
| Mécanisme de mise à jour | Fonctionnent de manière synchrone lors d'un INSERT dans la table source (pour les vues matérialisées incrémentales). Remarque : elles peuvent aussi être planifiées à l'aide de vues matérialisées actualisables. |
Mises à jour asynchrones en arrière-plan après un INSERT dans la table principale. |
| Interaction avec les requêtes | Travailler avec des vues matérialisées nécessite d'interroger directement la table cible, ce qui signifie que vous devez connaître l'existence des vues matérialisées lors de la rédaction des requêtes. | Les projections sont sélectionnées automatiquement par l'optimiseur de requêtes de ClickHouse et sont transparentes, au sens où l'utilisateur n'a pas à modifier ses requêtes sur la table avec projection pour en tirer parti. À partir de la version 25.6, il est également possible de filtrer sur plusieurs projections. |
Gestion de UPDATE / DELETE |
Ne réagissent pas automatiquement aux opérations UPDATE ou DELETE sur la table source, car les vues matérialisées n'ont aucune connaissance de la table source et agissent uniquement comme des déclencheurs à l'insertion sur une table source. Cela peut entraîner une possible obsolescence des données entre les tables source et cible, et nécessite des solutions de contournement ou une reconstruction complète périodique. (via une vue matérialisée actualisable). |
Par défaut, elles sont incompatibles avec les lignes DELETED (en particulier les lightweight deletes). lightweight_mutation_projection_mode (v24.7+) peut activer cette compatibilité. |
Prise en charge de JOIN |
Oui. Les vues matérialisées actualisables peuvent être utilisées pour une dénormalisation complexe. Les vues matérialisées incrémentales ne se déclenchent que lors d'insertions dans la table la plus à gauche. | Non. Les opérations JOIN ne sont pas prises en charge dans les définitions de projections pour filtrer les données matérialisées. En revanche, les requêtes qui joignent des tables avec des projections fonctionnent normalement : les projections optimisent l'accès à chaque table individuellement. |
Clause WHERE dans la définition |
Oui. Des clauses WHERE peuvent être incluses pour filtrer les données avant la matérialisation. |
Non. Les clauses WHERE ne sont pas prises en charge dans les définitions de projections pour filtrer les données matérialisées. |
| Capacités d'enchaînement | Oui, la table cible d'une vue matérialisée peut être la source d'une autre vue matérialisée, ce qui permet des pipelines en plusieurs étapes. | Non. Les projections ne peuvent pas être enchaînées. |
| Moteurs de table applicables | Peuvent être utilisées avec différents moteurs de table de tables source, mais les tables cibles appartiennent généralement à la famille MergeTree. |
Disponibles uniquement pour les moteurs de table de la famille MergeTree. |
| Gestion des défaillances | Une défaillance lors de l'insertion des données signifie que les données sont perdues dans la table cible, ce qui peut entraîner une incohérence potentielle. | Les défaillances sont gérées silencieusement en arrière-plan. Les requêtes peuvent mélanger de manière transparente des parties matérialisées et non matérialisées. |
| Surcharge opérationnelle | Nécessitent la création explicite d'une table cible et souvent un backfill manuel. La gestion de la cohérence avec UPDATE/DELETE accroît la complexité. |
Les projections sont maintenues automatiquement, restent synchronisées et présentent généralement une charge opérationnelle plus faible. |
Compatibilité des requêtes FINAL |
Généralement compatibles, mais nécessitent souvent un GROUP BY sur la table cible. |
Ne fonctionnent pas avec les requêtes FINAL. |
| Lazy materialization | Oui. | Surveillez les problèmes de compatibilité des projections lors de l'utilisation des fonctionnalités de matérialisation. Vous devrez peut-être définir query_plan_optimize_lazy_materialization = false |
| Réplicas parallèles | Oui. | Non. |
optimize_read_in_order |
Oui. | Oui. |
| Mises à jour et suppressions légères | Oui. | Non. |
Comparaison entre les vues matérialisées et les projections
Quand choisir des vues matérialisées
Vous devriez envisager d’utiliser des vues matérialisées lorsque :
- 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.
Quand éviter les vues matérialisées
Il peut être préférable d’éviter d’utiliser des vues matérialisées lorsque :
- 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.
Quand choisir les projections
Vous devriez envisager d'utiliser des projections dans les cas suivants :
- 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.
Quand éviter les projections
Vous devriez envisager d’éviter d’utiliser des projections lorsque :
- 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 instructionsCASEcomplexes. 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
WHEREdans leur définition pour filtrer les données matérialisées dans la projection elle-même. - Des moteurs de table autres que
MergeTreesont utilisés : les projections sont exclusivement disponibles pour les tables utilisant la famille de moteursMergeTree. - Les requêtes
FINALsont essentielles : les projections ne fonctionnent pas avec les requêtesFINAL, 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.
Résumé
Les vues matérialisées et les projections sont deux outils puissants pour optimiser les requêtes et transformer les données. En règle générale, nous vous recommandons de ne pas les considérer comme un choix binaire. Elles peuvent au contraire être utilisées de manière complémentaire afin de tirer le meilleur parti de vos requêtes. Le choix entre les vues matérialisées et les projections dans ClickHouse dépend donc avant tout de votre cas d’usage et de vos schémas d’accès.
En règle générale, il est préférable d’utiliser des vues matérialisées lorsque vous devez agréger des données provenant d’une ou plusieurs tables sources vers une table cible, ou effectuer des transformations complexes à grande échelle. Les vues matérialisées sont particulièrement utiles pour déplacer la charge des agrégations coûteuses du temps de requête vers le moment de l’insert. Elles constituent un excellent choix pour les rollups quotidiens ou mensuels, les tableaux de bord en temps réel ou les résumés de données.
En revanche, privilégiez les projections lorsque vous devez optimiser des requêtes qui filtrent sur des colonnes autres que celles utilisées dans la clé primaire de la table, laquelle détermine l’ordre physique des données sur le disque. Elles sont particulièrement utiles lorsqu’il n’est plus possible de modifier la clé primaire d’une table, ou lorsque vos schémas d’accès sont plus variés que ce que la clé primaire peut couvrir.