Une infra qui grossit produit des logs, des métriques et des traces par téraoctets, et la facture de la stack d'observabilité finit par dépasser celle de l'infra qu'elle surveille. C'est le moment où les équipes regardent leur cluster Elasticsearch de stockage de logs, comptent les nœuds, et se demandent comment une fonction de support en est arrivée à coûter ce prix. La réponse tient souvent dans le choix du moteur de stockage en dessous. Et de plus en plus, ce moteur est ClickHouse.
ClickHouse est une base de données analytique en colonnes, conçue pour un usage précis : avaler des inserts massifs et répondre à des requêtes d'agrégation sur des milliards de lignes en quelques millisecondes. Ce n'est pas une base transactionnelle, et la confondre avec une mène droit dans le mur. Comprendre ce pour quoi elle est faite, et ce qu'elle refuse de faire, évite de la déployer au mauvais endroit.
Colonnes contre lignes : pourquoi l'OLAP change tout
Une base transactionnelle classique comme PostgreSQL stocke les données par lignes : tous les champs d'un enregistrement sont contigus sur le disque. Parfait pour lire ou écrire un enregistrement entier, le pain quotidien de l'OLTP (traitement transactionnel) : récupérer une commande, mettre à jour un compte. ClickHouse stocke par colonnes : toutes les valeurs d'un même champ sont regroupées ensemble.
Cette différence de disposition décide de tout. Une requête analytique typique ne touche que quelques colonnes sur des millions de lignes : la latence moyenne par service sur les dernières 24 heures, le compte d'erreurs 5xx par endpoint. En stockage colonne, ClickHouse ne lit que les colonnes concernées et ignore tout le reste, là où une base ligne devrait parcourir chaque enregistrement entier. Et comme une colonne regroupe des valeurs de même type et souvent proches, la compression atteint des ratios qu'un stockage ligne ne verra jamais, souvent un ordre de grandeur. Moins de données sur le disque, moins de données à lire, des requêtes qui répondent en millisecondes là où la même question prendrait des minutes ailleurs.
Il faut situer ClickHouse face à ses voisins pour ne pas se tromper de catégorie. Postgres est une base OLTP : transactions, lectures et écritures unitaires, cohérence forte. Une TSDB (base de séries temporelles) comme Prometheus, VictoriaMetrics ou TimescaleDB pour les métriques d'infrastructure est taillée pour les métriques, des séries numériques horodatées avec un modèle de données spécifique. ClickHouse est une base OLAP généraliste : elle excelle sur l'analytique de gros volumes hétérogènes, ce qui la rend redoutable sur les logs et les traces, là où une TSDB est trop spécialisée et une base OLTP s'effondre sous le volume.
MergeTree, le moteur qui fait le travail
Tout repose sur la famille de moteurs MergeTree. Le principe : les données arrivent par paquets, chaque insert crée une partie (part) écrite sur le disque, triée selon la clé de tri primaire, et un processus de fond fusionne (merge) ces parties en arrière-plan selon des règles définies. D'où le nom. Ce design explique la vitesse d'ingestion : un insert n'a pas à réorganiser une structure existante, il dépose une nouvelle partie, point.
La clé de tri primaire ne fonctionne pas comme un index Postgres. ClickHouse construit un index clairsemé (sparse) qui ne pointe pas chaque ligne mais des blocs de lignes, ce qui le rend minuscule et permet de sauter directement aux blocs pertinents. Sur une requête bien alignée avec la clé de tri, ClickHouse écarte d'emblée 99 % des données sans les lire. Mal aligner la clé de tri avec les requêtes réelles, c'est le contraire : des scans complets et des performances décevantes. C'est le premier réglage à soigner.
Ce comportement, déposer des parties puis fusionner en fond, impose une règle d'exploitation non négociable : il faut batcher les inserts. ClickHouse veut de gros paquets espacés, pas un flot de petites écritures unitaires. Chaque insert créant une partie, un déluge de micro-inserts génère une multitude de petites parties que le moteur n'arrive plus à fusionner assez vite, et les performances s'écroulent. La règle qu'on applique : agréger côté client ou via un buffer, et insérer par lots de plusieurs milliers de lignes.
Réplication : ReplicatedMergeTree et ClickHouse Keeper
En production, une seule instance ne suffit pas. Le moteur ReplicatedMergeTree réplique les parties de données entre plusieurs serveurs ClickHouse. Chaque réplica écrit ses parties localement et les enregistre dans un service de coordination ; les autres répliques détectent les nouvelles entrées dans la file de réplication et tirent les parties depuis le serveur d'origine.
Ce service de coordination, c'est ClickHouse Keeper. Il remplace ZooKeeper, l'ancienne dépendance Java qui imposait d'opérer une stack séparée. Keeper parle le même protocole que ZooKeeper, c'est un remplaçant direct, mais il est intégré à ClickHouse et nettement plus léger à opérer. Tout nouveau déploiement part sur Keeper, sans discussion. La logique de quorum d'un service de coordination distribué reste classique : nombre impair de nœuds, faible latence entre eux, et surveillance du quorum, parce que sans coordination la réplication s'arrête.
TTL, partitions et vues matérialisées : tenir la rétention
Sur des logs, la donnée a une durée de vie. Personne ne requête les logs d'il y a dix-huit mois à la milliseconde près, mais il faut parfois les garder pour la conformité. ClickHouse gère ça nativement avec les TTL (Time To Live) : on définit une règle qui supprime automatiquement les données passé un délai, ou qui les déplace vers un stockage moins cher. Couplé au stockage par paliers, on garde le récent sur du NVMe rapide et on bascule l'ancien vers de l'object store S3, en gardant la donnée requêtable.
Les partitions complètent le dispositif. Partitionner par jour ou par mois permet à ClickHouse de supprimer une partition entière d'un coup, opération quasi instantanée, au lieu d'effacer ligne par ligne. C'est ce qui rend la purge de rétention triviale sur des volumes énormes.
Les vues matérialisées (materialized views) ferment le tableau. Une vue matérialisée ClickHouse se déclenche à l'insertion : elle calcule à la volée des agrégats pré-calculés et les écrit dans une table dédiée. Au lieu de recalculer la latence p99 par service sur des milliards de lignes brutes à chaque requête de dashboard, on interroge une table d'agrégats déjà prête, mise à jour en continu. C'est la technique qui fait tenir un dashboard temps réel sur un volume de logs qui exploserait n'importe quel calcul à la volée.
Le piège : ce que ClickHouse refuse de faire
ClickHouse n'est pas une base transactionnelle, et tout ce qui suppose une mutation ligne par ligne y est inefficace. Les UPDATE et DELETE ne sont pas de vraies opérations transactionnelles : ce sont des mutations lourdes et asynchrones qui réécrivent des parties entières en arrière-plan. Sur un usage analytique en append (on ajoute, on ne modifie pas), c'est sans conséquence. Mais quiconque arrive avec un réflexe OLTP, modifier une ligne, supprimer un enregistrement précis à la demande, va vivre une expérience douloureuse.
Même chose pour la cohérence : la réplication est à cohérence à terme (eventual consistency). Une donnée écrite sur un réplica met un court instant à se propager aux autres. Pour des logs et des métriques, c'est parfaitement acceptable. Pour un système qui exige de relire immédiatement ce qu'il vient d'écrire, ça ne l'est pas. Le bon usage de ClickHouse : append massif, lecture analytique, pas de mutation unitaire, pas de relecture immédiate après écriture.
Le rôle en observabilité : backend de plus en plus dominant
C'est là que tout converge. Les caractéristiques de ClickHouse, inserts massifs, compression forte, requêtes analytiques rapides, rétention par TTL, en font un backend taillé pour l'observabilité. SigNoz, l'alternative open source à Datadog basée sur OpenTelemetry, stocke ses trois signaux (logs, métriques, traces) dans ClickHouse précisément pour ça. ClickHouse sert aussi de source de données sous Grafana, et de backend de stockage de logs en remplacement d'Elasticsearch.
L'argument décisif sur les logs, c'est le coût. Selon la comparaison officielle ClickHouse face à Elasticsearch sur l'observabilité, la compression colonne réduit l'empreinte de stockage de plus de la moitié, ce qui ouvre une rétention longue à un prix tenable, là où Elasticsearch force à arbitrer entre durée de conservation et facture. Pour qui exploite déjà une stack de logs Loki ou cherche une solution de logs légère avec VictoriaLogs, ClickHouse occupe le segment du gros volume analytique : moins léger à opérer que VictoriaLogs, mais imbattable quand il faut requêter et agréger des milliards de lignes de logs.
Verdict ops
ClickHouse n'est pas une base à tout faire, et c'est sa force. Pour du gros volume analytique, des logs, des traces, de l'agrégation sur des milliards de lignes, c'est le bon outil : compression d'un ordre de grandeur, requêtes en millisecondes, rétention native par TTL et partitions, le tout à un coût de stockage qui ridiculise Elasticsearch sur les logs. Si votre stack d'observabilité étouffe sous le volume et la facture, ClickHouse en backend mérite le banc d'essai, directement ou via SigNoz qui l'embarque déjà.
Là où il ne faut pas le mettre : partout où on a besoin de transactions, de mutations ligne par ligne ou de relecture immédiate. Ce n'est pas une base applicative, ce n'est pas un remplaçant de Postgres, et pour des métriques pures une TSDB dédiée reste plus simple à opérer. Le déployer hors de son terrain, c'est hériter de tous ses pièges (inserts à batcher, updates inefficaces, cohérence à terme) sans le moindre de ses bénéfices. Bien posé, en revanche, il encaisse des volumes qui mettraient n'importe quelle base ligne à genoux.
Sources
- ClickHouse, documentation MergeTree : moteur MergeTree, parties, fusion en arrière-plan et réglages associés.
- ClickHouse and SigNoz, OpenTelemetry observability : ClickHouse comme backend de logs, traces et métriques, compression colonne et gain de coût face à Elasticsearch.
- Elastic Observability vs ClickStack, ClickHouse : comparaison du stockage de logs ClickHouse face à Elasticsearch sur le coût et la compression.
- SigNoz, dépôt GitHub : plateforme d'observabilité OpenTelemetry construite sur ClickHouse pour logs, métriques et traces.
