Pourquoi auto-héberger ClickHouse sur un VPS
ClickHouse excelle sur les requêtes analytiques (OLAP) : grâce à son stockage en colonnes et sa compression agressive, il peut scanner des téraoctets sur du matériel modeste là où une base relationnelle classique s'effondrerait. L'auto-héberger sur un VPS vous évite les coûts au volume de requêtes des offres managées (ClickHouse Cloud, BigQuery) et vous donne la maîtrise complète du schéma, des moteurs de table et de la rétention. C'est particulièrement pertinent pour ingérer vos propres logs applicatifs, métriques produit ou événements analytics sans envoyer vos données à un tiers. Comme ClickHouse compresse souvent les données d'un facteur 5 à 10, un VPS avec un disque SSD raisonnable peut stocker des centaines de millions d'événements. Vous gardez aussi le contrôle sur la latence : vos dashboards interrogent une instance proche de vos utilisateurs plutôt qu'un service distant.
Les bénéfices concrets du self-hosting de ClickHouse
- Requêtes analytiques extrêmement rapides : agrégations sur des centaines de millions de lignes en sous-seconde.
- Compression colonne de 5x à 10x qui réduit drastiquement le coût de stockage de vos logs et événements.
- Ingestion massive : des centaines de milliers de lignes par seconde sur un seul nœud bien réglé.
- Compatible SQL et avec de nombreux connecteurs (Grafana, Metabase, clients HTTP et natifs).
- Souveraineté analytique : vos logs et métriques produit restent sur votre infrastructure.
- Pas de facturation à la requête : un coût VPS fixe pour un volume analytique élevé.
Prérequis matériels et logiciels
ClickHouse aime la RAM et le disque rapide. Pour un usage analytique sérieux, visez 4 Go de RAM minimum, mais 8 Go offrent une marge bien plus saine pour les agrégations volumineuses et les marques (mark cache). Côté CPU, 2 à 4 vCPU permettent de paralléliser les requêtes. Le disque est critique : privilégiez du SSD NVMe avec au moins 50 à 100 Go selon votre volume et votre rétention, sachant que la compression réduit l'empreinte réelle. Vous aurez besoin de Docker, d'un domaine si vous exposez l'interface HTTP, et d'une attention particulière au paramètre max_memory_usage pour éviter qu'une requête ne fasse tomber le serveur. Évitez d'exposer le port natif 9000 directement sur Internet.
Déployer ClickHouse étape par étape
Préparer le VPS
Installez Docker, augmentez les limites système (ulimit -n à 262144) car ClickHouse ouvre beaucoup de descripteurs de fichiers. Désactivez le swap excessif et vérifiez que le disque est bien en SSD NVMe.
Lancer ClickHouse via Docker
Utilisez l'image officielle clickhouse/clickhouse-server. Montez trois volumes persistants : /var/lib/clickhouse (données), /var/log/clickhouse-server (logs) et un dossier de configuration /etc/clickhouse-server/config.d. Ajoutez ulimits: nofile: 262144 dans le compose.
Créer un utilisateur et un mot de passe
Ne laissez jamais l'utilisateur default sans mot de passe. Créez un fichier users.d/custom.xml avec un utilisateur dédié, un mot de passe hashé (echo -n motdepasse | sha256sum) et des quotas. Restreignez
Régler la mémoire et le profil
Dans config.d, fixez max_server_memory_usage_to_ram_ratio à 0.8 et définissez un max_memory_usage par requête adapté à votre VPS pour éviter les OOM. Activez la rétention des partitions avec un TTL sur vos tables (TTL date + INTERVAL 90 DAY).
Exposer l'interface HTTP derrière un reverse proxy
ClickHouse expose une API HTTP sur le port 8123. Placez Nginx ou Caddy devant pour le TLS et l'authentification supplémentaire, et n'ouvrez pas le port natif 9000 au public. Réservez l'accès natif au réseau interne ou via tunnel SSH.
Connecter un outil de visualisation
Branchez Grafana ou Metabase sur l'endpoint HTTPS pour construire vos dashboards. Créez vos tables avec le moteur MergeTree, choisissez une ORDER BY pertinente et partitionnez par mois pour des requêtes et une purge efficaces.
Le choix de la clé de tri (ORDER BY) du moteur MergeTree est le facteur décisif de performance : placez en premier les colonnes les plus filtrées dans vos requêtes (souvent une date et un identifiant). Utilisez les tables Buffer ou des inserts par lots de plusieurs milliers de lignes plutôt que des insertions ligne par ligne, qui créent une multitude de petites partitions et déclenchent des merges coûteux. Surveillez system.merges et system.parts pour détecter une fragmentation excessive.
