ClickHouse devient plus paresseux et plus rapide : introduction de l’optimisation par chargement différé

(clickhouse.com)

6 points par GN⁺ 2025-04-24 | 2 commentaires | Partager sur WhatsApp

ClickHouse introduit une nouvelle technique d’optimisation, la lazy materialization, qui améliore les performances des requêtes Top N jusqu’à 1 500 fois
Une stratégie qui ne lit les données de colonnes qu’au moment nécessaire permet de minimiser les E/S disque
Avec les techniques existantes de stockage en colonnes, index et PREWHERE, cela forme une pile hiérarchique d’optimisation des E/S
En différant le chargement des données de colonnes selon le plan d’exécution de la requête, l’effet est particulièrement marqué pour les requêtes avec clause LIMIT
Activée par défaut, cette optimisation apporte un gain de performance sans modification du code

La stratégie d’optimisation différée de ClickHouse : Lazy Materialization

Concept clé

ClickHouse maximise les performances en évitant de lire les données inutiles
La lazy materialization consiste à charger les données de colonnes uniquement au moment où elles sont réellement nécessaires pendant l’exécution de la requête
Elle fonctionne indépendamment des techniques existantes d’optimisation des E/S, tout en apportant des gains de performance complémentaires

Techniques existantes d’optimisation des E/S

Stockage orienté colonnes : lecture des seules colonnes nécessaires
Sparse Index / Skipping Index / Projections : lecture uniquement des granules correspondant aux conditions de filtrage
PREWHERE : filtrage précoce des colonnes non indexées
Query Condition Cache : mise en cache des résultats des requêtes répétées pour éviter de retraiter les mêmes granules

Principe de la Lazy Materialization

Là où les techniques existantes se concentraient sur la réduction des E/S par le filtrage, la lazy materialization repousse la lecture jusqu’au moment du calcul
Les colonnes nécessaires à l’étape suivante de la requête sont lues immédiatement, tandis que les autres ne sont lues qu’après LIMIT, lorsqu’elles deviennent nécessaires
Cela est particulièrement efficace pour les requêtes Top N, où seule une partie des colonnes est consultée, ce qui évite presque totalement la lecture de grosses colonnes texte, par exemple

Cette optimisation est possible grâce au stockage indépendant des colonnes, une approche impossible dans une base de données orientée lignes

Exemple concret : jeu de données d’avis Amazon

150M rows, 70GB non compressés, 30GB compressés
Exemple de requête Top N :
```
SELECT helpful_votes  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;  
```
- Temps d’exécution : 0,07 seconde
- Traitement rapide grâce à la lecture d’une seule colonne
Exemple de lecture d’une grande colonne texte :
```
SELECT review_body  
FROM amazon.amazon_reviews  
FORMAT Null;  
```
- Temps d’exécution : 176 secondes
- Une seule colonne, mais 56GB, ce qui provoque un goulot d’étranglement d’E/S disque

Comparaison des performances selon les couches d’optimisation appliquées

1. Sans optimisation (baseline)

Temps d’exécution : 219 secondes
Volume traité : 72GB, 150M rows
Toutes les colonnes sont lues et triées

2. Avec l’index de clé primaire

Temps d’exécution : 96 secondes
Volume traité : 28GB, 53M rows
Le filtrage des granules basé sur la PK réduit le temps de plus de 50 %

3. Avec PREWHERE en plus

Temps d’exécution : 61 secondes
Volume traité : 16GB
Réduction supplémentaire des E/S grâce à l’application de conditions de filtre sur des colonnes non indexées

4. Avec Lazy Materialization activée

Temps d’exécution : 0,18 seconde
Volume traité : 807MB
Seules les 3 rows finalement nécessaires sont chargées depuis les grandes colonnes

Au total, plus de 1 200 fois plus rapide et plus de 150 fois moins de mémoire utilisée

Efficace aussi pour les requêtes Top N sans filtre

Dans une requête de tri global sans filtre :

SELECT helpful_votes, product_title, review_headline, review_body  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3;

Avant la lazy materialization : 219 secondes
Après la lazy materialization : 0,139 seconde
Accélération de 1 576 fois, 40 fois moins d’E/S, 300 fois moins de mémoire utilisée

Vérification du plan d’exécution

EXPLAIN actions = 1  
SELECT helpful_votes, product_title, review_headline, review_body  
FROM amazon.amazon_reviews  
ORDER BY helpful_votes DESC  
LIMIT 3  
SETTINGS query_plan_optimize_lazy_materialization = true;

Résultat :

Lazily read columns: review_headline, review_body, product_title   
  Limit                    
    Sorting                             
      ReadFromMergeTree

Les grandes colonnes ne sont chargées qu’après le tri et LIMIT

Conclusion

La pile d’optimisation des E/S de ClickHouse est désormais complète : Index → PREWHERE → Lazy Materialization
Sans modification du code, les performances peuvent être multipliées par plusieurs centaines ou milliers uniquement grâce à l’exécution des requêtes
Solution idéale notamment pour les patterns Top N, les colonnes volumineuses et les requêtes avec LIMIT
Activée par défaut, elle s’applique automatiquement sans configuration manuelle

Même SQL, même machine, résultat différent
Plus rapide = moins de lecture = ClickHouse

2 commentaires

zihado 2025-04-24

> Je me demande si quelqu’un a comparé ClickHouse et StarRocks ; il y a quelques mois, les performances de jointure de StarRocks semblaient meilleures.
https://d2.naver.com/helloworld/1168674

GN⁺ 2025-04-24

Avis Hacker News

Cette optimisation devrait offrir des gains de vitesse spectaculaires, en particulier lors de l’extraction d’échantillons aléatoires à partir de grands jeux de données lorsque les colonnes visées peuvent contenir de grosses valeurs
- La recette SQL de base utilise la clause LIMIT pour déterminer quelles lignes seront incluses dans l’échantillon
- La nouvelle optimisation promet de retarder la lecture des grandes colonnes jusqu’à ce que la clause LIMIT ait filtré le jeu de données à un petit nombre de lignes
- Je me demande si quelqu’un peut vérifier si cette optimisation accélère effectivement ces requêtes dans ClickHouse
J’aime vraiment beaucoup ClickHouse
- Je l’ai découvert récemment, et par rapport aux solutions inefficaces pour l’analytique, c’est une vraie bouffée d’air frais
- C’est extrêmement rapide, et le CLI est aussi agréable à utiliser
Je ne comprends pas les sites web sur lesquels on ne peut pas faire défiler la page
- Dès qu’on fait un peu défiler, ça remonte en haut et ça devient inutilisable
Matérialisation tardive, 19 ans plus tard
- Lien connexe fourni
Sans rapport avec la nouvelle option de matérialisation, mais ce passage a retenu mon attention
- La requête trie 150 millions de valeurs et renvoie les 3 premières en 70 millisecondes
- Il faut mettre à jour son modèle mental de ce qu’est une requête lente sur le matériel et les logiciels modernes
- Trier 150 millions d’entiers en 70 millisecondes n’est pas surprenant
- L’utilisation mémoire de pointe est de 3.59 MiB
- Excellent article, expliqué clairement et accompagné de bons schémas
ClickHouse serait probablement plus populaire que DuckDB s’il existait une version native pour Windows ne nécessitant ni WSL ni machine virtuelle Linux
- L’une des raisons pour lesquelles MySQL était plus populaire que PostgreSQL, c’est que MySQL avait un installateur Windows
Je prévois des vacances à la plage malgré le drame de l’aéroport
- Les informations techniques et les schémas étaient de tout premier niveau, mais la présence d’une histoire les rendait encore meilleurs
ClickHouse est un chef-d’œuvre de l’ingénierie moderne
- Une attention absolue portée aux performances
Je me demande si quelqu’un a comparé ClickHouse et StarRocks
- Il y a quelques mois, les performances de jointure de StarRocks semblaient meilleures
Il est frappant de voir à quel point ces bases de données montrent que toutes les bases orientées lignes se trompaient
- Impossible d’approcher de telles vitesses avec une structure d’index btree
- C’est impressionnant de voir à quel point les machines modernes sont rapides
- J’ai l’impression que le jeu de données n’était probablement pas correctement compressé
- La lecture des données est plus lente que la décompression
- Cela me rappelle l’article de Cloudflare sur l’idée que le chiffrement est gratuit
- Il est impressionnant qu’ils utilisent le moteur de calcul (chdb)