Passer au contenu principal
Cet article explique le fonctionnement de la matérialisation paresseuse et sa place dans l’ensemble des optimisations d’E/S de ClickHouse. Il présente un exemple concret montrant comment la matérialisation paresseuse améliore les performances des requêtes.
Disponible à partir de la version 25.4La matérialisation paresseuse a été introduite dans la version 25.4 de ClickHouse et est activée par défaut.

​
Vue d’ensemble

Au fil des ans, ClickHouse a introduit une série d’optimisations superposées pour réduire drastiquement les E/S. Ces techniques constituent la base de sa rapidité et de son efficacité : Bien que les optimisations d’E/S mentionnées ci-dessus puissent réduire considérablement le volume de données lu, elles partent toujours du principe que toutes les colonnes des lignes satisfaisant la clause WHERE doivent être chargées avant d’exécuter des opérations comme le tri, l’agrégation ou LIMIT. Mais que se passe-t-il si certaines colonnes ne sont nécessaires que plus tard, ou si certaines données, bien qu’elles satisfassent la clause WHERE, ne sont en fait jamais nécessaires ? C’est là qu’intervient la matérialisation paresseuse. Il s’agit d’une amélioration orthogonale qui complète la pile d’optimisations d’E/S :
  • L’indexation, associée à PREWHERE, garantit que seules les lignes correspondant aux filtres de colonnes de la clause WHERE sont traitées.
  • La matérialisation paresseuse s’appuie sur cela en différant la lecture des colonnes jusqu’au moment où le plan d’exécution de la requête en a réellement besoin. Même après le filtrage, seules les colonnes nécessaires à l’opération suivante — comme le tri — sont chargées immédiatement. Les autres sont différées et, grâce à LIMIT, ne sont souvent lues que partiellement, juste assez pour produire le résultat final. Cela rend la matérialisation paresseuse particulièrement puissante pour les requêtes Top N, où le résultat final peut ne nécessiter qu’une poignée de lignes de certaines colonnes, souvent volumineuses.

​
Un exemple concret

Nous recommandons vivement l’article de blog “ClickHouse gets lazier (and faster): Introducing lazy materialization” pour approfondir la matérialisation paresseuse. L’exemple ci-dessous est tiré de l’article de blog mentionné ci-dessus et reproduit ici pour montrer comment une requête ClickHouse peut passer de 219 secondes à seulement 139 millisecondes (soit une accélération de 1576×) grâce à la matérialisation paresseuse. Pour tirer parti de l’indexation et de PREWHERE, une requête doit comporter des filtres : sur les colonnes de clé primaire pour l’indexation, et sur n’importe quelles colonnes pour PREWHERE. La matérialisation paresseuse s’y superpose naturellement, mais contrairement aux autres optimisations mentionnées précédemment, elle peut aussi accélérer des requêtes sans aucun filtre sur les colonnes. Prenons l’exemple de la requête suivante, qui recherche les avis Amazon ayant reçu le plus grand nombre de votes utiles, quelle que soit la date, le produit, la note ou le statut de vérification, et renvoie les 3 premiers avec leur titre, leur en-tête et leur texte intégral. Commençons par exécuter la requête (avec des caches du système de fichiers à froid) avec la matérialisation paresseuse désactivée (à l’aide de query_plan_optimize_lazy_materialization) :
Query
Response
Ensuite, la requête est réexécutée (à nouveau avec un cache du système de fichiers à froid), mais cette fois avec la matérialisation paresseuse activée :
Query
En règle générale, vous n’avez pas besoin de définir explicitement query_plan_optimize_lazy_materialization = true pour bénéficier de la matérialisation paresseuse. Ce paramètre est activé par défaut.
Response
Comparez les performances avec la matérialisation paresseuse désactivée, puis activée :

​
Comment confirmer la matérialisation paresseuse dans le plan d’exécution de la requête

Vous pouvez constater l’utilisation de la matérialisation paresseuse pour la requête précédente en examinant le plan d’exécution logique de la requête à l’aide de la clause EXPLAIN :
Vous pouvez lire le plan d’opérateurs de bas en haut et constater que ClickHouse reporte la lecture des trois grandes colonnes String après le tri et l’application de la limite.
Dernière modification le 3 juillet 2026