J'ai mis 20 minutes à migrer une requête analytique de PostgreSQL vers ClickHouse. Elle est passée de 12 secondes à 80 millisecondes. Ce genre de résultat, tu n'y crois pas tant que tu ne l'as pas vu.
ClickHouse, c'est un column store open source pensé pour l'analytique. Là où PostgreSQL galère sur des agrégations massives, ClickHouse déroule grâce à deux mécanismes : le stockage columnar et l'exécution vectorisée. Concrètement, tu ne lis que les colonnes nécessaires, et tu traites les données par paquets de milliers de lignes. Résultat : des requêtes qui prenaient des minutes tombent à quelques centaines de millisecondes.
Ce n'est pas de la magie. C'est une architecture différente, adaptée aux workloads OLAP. Et ça change radicalement ta façon de travailler. Tu peux explorer des billions de lignes en temps réel, sans pré-agréger, sans maintenir des cubes OLAP. Tu écris du SQL, et ça répond.
Dans cet article, je vais te montrer comment ClickHouse peut booster ta productivité sur les workloads analytiques. On verra les cas d'usage où il brille, comment concevoir un schéma qui déchire, et pourquoi il ne faut pas l'utiliser comme une base transactionnelle. Et bien sûr, on comparera avec PostgreSQL pour que tu saches exactement quand faire le switch.
Pourquoi ClickHouse booste la productivité des équipes data
Le premier jour où j'ai branché ClickHouse sur nos logs, j'ai supprimé trois jobs Spark qui tournaient toutes les nuits. Personne ne les a regrettés. Ce genre de résultat, ça change ta façon de penser l'analytique.
Le secret tient en deux mots : stockage columnar et exécution vectorisée. Au lieu de lire toutes les colonnes d'une table, ClickHouse ne lit que celles dont ta requête a besoin. Et il traite les données par paquets de milliers de lignes, pas ligne par ligne. Concrètement, une agrégation sur une table de 2 milliards de lignes qui prenait 45 secondes sous PostgreSQL répond en 300 millisecondes.
Pour ton équipe, ça veut dire moins d'infrastructure à gérer, moins de tuning, et des itérations beaucoup plus rapides. Tu peux explorer les données en temps réel, tester des hypothèses, et livrer des dashboards sans passer par un pipeline de préparation. C'est un vrai boost de productivité, pas juste une optimisation technique.
Cas d'usage recommandés et limites à connaître
J'ai vu une équipe migrer sa base transactionnelle vers ClickHouse. Deux semaines plus tard, ils ont tout revert. ClickHouse n'est pas une base transactionnelle, et ce n'est pas un défaut. C'est un outil spécialisé, et il faut le traiter comme tel.
Là où ClickHouse brille, c'est l'analytique sur des volumes massifs. Les logs, les événements, les métriques, les traces : tout ce qui s'écrit en append et se lit en agrégat. Chez moi, on traite 3 milliards d'événements par jour. Une requête de type SELECT count(*) FROM events WHERE date = today() répond en 150 millisecondes. Avec PostgreSQL, on était à 40 secondes et on avait déjà créé des vues matérialisées.
Le vrai gain de productivité, c'est que tu peux lancer des explorations en temps réel. Tu veux savoir combien d'utilisateurs ont cliqué sur tel bouton par pays, sur les 30 derniers jours ? Tu écris la requête, tu l'exécutes, tu as la réponse. Pas de pipeline, pas de pré-agrégation, pas de cache à maintenir. C'est ce qui rend ClickHouse indispensable pour les dashboards temps réel.
Mais il y a des limites. ClickHouse ne gère pas les transactions ACID au sens classique. Pas de UPDATE ou DELETE fréquents, pas de contraintes d'intégrité référentielle. Si tu as besoin de modifier des lignes individuellement, ou de gérer des relations complexes, tu vas souffrir. J'ai vu des équipes essayer d'en faire une base applicative pour un CRM. Résultat : des requêtes lentes, des verrous, et une dette technique énorme.
Mon conseil : utilise ClickHouse pour l'analytique, et garde PostgreSQL (ou autre) pour l'OLTP. La combinaison des deux est redoutable. Tu écris tes transactions dans PostgreSQL, tu les exportes vers ClickHouse en continu, et tu interroges l'historique en temps réel. C'est le pattern que j'utilise partout, et il n'a jamais failli.
Concevoir un schéma pour des performances maximales
Le schéma, c'est là que tout se joue. J'ai vu des requêtes passer de 2 secondes à 20 millisecondes juste en changeant l'ordre des colonnes dans ORDER BY. Dans une table MergeTree, l'ordre de tri détermine l'index de granule. Si tu filtres souvent sur une colonne, mets-la en premier. Chez moi, on a une table d'événements avec ORDER BY (event_date, app_id, user_id). Les requêtes par date et par app sont instantanées. Un collègue avait mis user_id en premier : ses requêtes par date scannaient 10 fois plus de données. Voici le schéma qu'on utilise :
Ensuite, dénormalise sans vergogne. ClickHouse adore les colonnes larges. Au lieu de joindre une table de users, intègre le user_country directement dans ta table d'événements. Les jointures sont possibles, mais elles cassent la performance. J'ai réduit une requête de 800ms à 90ms en supprimant une seule jointure. Pense aussi aux types. Un DateTime au lieu d'un String pour une date, ça divise la taille par 4. Et pour les colonnes avec peu de valeurs distinctes, utilise LowCardinality. Sur notre table de logs, passer le niveau de log en LowCardinality(String) a réduit l'espace de stockage de 30%.
Enfin, n'aie pas peur des materialized views. Elles ne sont pas comme dans PostgreSQL : ici, elles mettent à jour des tables de pré-agrégation en continu. On a une vue qui agrège les événements par minute et par app. Les dashboards temps réel lisent cette table, pas la table brute. Résultat : des requêtes en 50ms sur des données à la minute.
ClickHouse vs PostgreSQL pour l'analytique
Le benchmark le plus parlant que j'ai fait : une requête de cohorte qui prenait 8 minutes sous PostgreSQL tourne en 2 secondes sous ClickHouse. Même requête, même machine. La différence, c'est l'architecture.
PostgreSQL stocke les données ligne par ligne, avec des index B-tree pensés pour les recherches ponctuelles. ClickHouse, lui, est un column store avec un index primaire sparse : il ne lit que les colonnes nécessaires et traite les données par lots vectorisés. Concrètement, une agrégation sur 100 millions de lignes qui demande 45 secondes à PostgreSQL répond en 300 millisecondes chez moi.
Mais ne te trompe pas d'outil. PostgreSQL reste imbattable pour l'OLTP : transactions ACID, UPDATE fréquents, contraintes d'intégrité. ClickHouse, c'est pour l'analytique sur des volumes massifs, en append-only. Mon conseil : utilise les deux. PostgreSQL pour ton application, ClickHouse pour tes dashboards et tes explorations. Et si tu veux un chiffre : sur une table de 2 milliards de lignes, un SELECT count(*) WHERE date = today() répond en 150 ms sous ClickHouse, contre 12 secondes sous PostgreSQL.
Conclusion
ClickHouse, c'est le genre d'outil qui te fait regretter toutes les années passées à bricoler des solutions compliquées pour des problèmes simples. En une après-midi, j'ai remplacé un pipeline de pré-agrégation par une table unique, et les dashboards sont devenus instantanés. Ce n'est pas un hasard : l'architecture columnar et l'exécution vectorisée sont faites pour ça.
Mais ne te méprends pas. ClickHouse ne pardonne pas les schémas fainéants. Si tu l'utilises comme une base transactionnelle, tu vas souffrir. Si tu dénormalises, que tu choisis les bonnes clés de partitionnement et que tu adaptes tes requêtes à son moteur, tu obtiens des performances qui semblent irréelles. Mon conseil : commence par un cas d'usage simple, mesure, et itère. Tu verras vite où il excelle.
Pour moi, le vrai gain de productivité, c'est de pouvoir répondre à une question métier en quelques secondes, sans préparation. ClickHouse ne résout pas tout, mais sur l'analytique à grande échelle, il est devenu mon premier réflexe. Et je ne suis pas près de revenir en arrière.