> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Vues matérialisées versus projections
> Article comparant les vues matérialisées et les projections dans ClickHouse, notamment leurs cas d’usage, leurs performances et leurs limites.
> 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.
## 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 un full refresh 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`](/docs/fr/reference/settings/session-settings#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 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](/docs/fr/products/cloud/features/infrastructure/parallel-replicas), 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.