GROUP BY lent ? La faute à la RAM
Original : It's the memory latency, stupid
Pourquoi c'est important
Comprendre la latence mémoire est clé pour optimiser les moteurs analytiques modernes.
Un article technique de Pivotlake explique pourquoi un CPU à 100% peut rester quasi-inactif : les accès mémoire RAM (50-100ns) coûtent jusqu'à 800 instructions CPU, plombant les agrégations GROUP BY à grande échelle.
Quand un CPU affiche 100% d'utilisation, il ne travaille pas forcément à plein régime. La raison : la latence mémoire. Un accès à la RAM prend entre 50 et 100 nanosecondes, contre 1 ns pour le cache L1 intégré au processeur. Concrètement, un CPU moderne peut exécuter 400 à 800 instructions pendant qu'il attend une seule réponse de la RAM.
Les caches CPU (L1 à ~64 Ko, L2 à ~1 Mo, L3 à quelques centaines de Mo) existent précisément pour contourner ce goulot d'étranglement. Mais dès qu'une opération déborde ces caches, les performances s'effondrent.
L'article illustre le problème avec les agrégations GROUP BY. L'approche naïve — une HashTable qui grossit avec chaque groupe unique — fonctionne bien sur de petits jeux de données. Sur les 99 millions de lignes du benchmark ClickBench, avec environ 17 millions de UserID distincts, chaque accès à la table devient un « cold hit » vers la RAM. Le CPU attend, sans avancer. L'auteur, Maor Kern, démonte le moteur Pivot pour le remplacer par cette logique simple, puis mesure l'impact réel sur la requête `SELECT count(*), UserID FROM hits GROUP BY UserID`. La conclusion : faire plus de travail côté CPU (calculs supplémentaires, partitionnement) peut paradoxalement accélérer l'ensemble en maintenant les données dans les caches.