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.

ClickHouse aime la RAM et le disque rapide. Le minimum absolu est 2 Go de RAM pour un environnement de test ou de développement, mais 4 Go constituent le plancher recommandé pour une charge de production légère, et 8 Go offrent une marge bien plus saine pour les agrégations volumineuses et les marques (mark cache). En dessous, vous rencontrerez rapidement des erreurs OOM dès que vous interrogez plusieurs millions de lignes. Côté CPU, 2 vCPU permettent d'exploiter le parallélisme de ClickHouse sur des requêtes simples ; 4 vCPU deviennent nécessaires dès que vous lancez des agrégations ou des jointures sur des tables denses. Le disque est le facteur le plus critique : un SSD NVMe est obligatoire — ClickHouse génère une I/O intense lors des merges de partitions et des requêtes de scan ; un disque rotatif HDD plafonne immédiatement les performances même sur un petit volume. Prévoyez au minimum 50 Go pour démarrer, et augmentez selon votre rétention sachant que la compression réduit l'empreinte réelle d'un facteur 5 à 10. Deux ports sont à connaître : le port 8123 pour l'interface HTTP (utilisé par les connecteurs Grafana, Metabase, curl) et le port 9000 pour le protocole TCP natif (utilisé par les clients ClickHouse en Go, Python, ou clickhouse-client). N'exposez jamais le port 9000 directement sur Internet sans filtrage réseau.

Une fois ClickHouse lancé, trois gestes de configuration consolident la sécurité et les performances. D'abord, créez une base de données dédiée via CREATE DATABASE analytics; dans la console SQL ou via l'API HTTP. Évitez d'écrire directement dans la base default — un espace de nommage propre facilite les backups, les quotas et la gestion des permissions. Ensuite, définissez vos utilisateurs dans un fichier users.d/production.xml plutôt que dans users.xml principal : ce découpage permet de recharger les utilisateurs sans redémarrer le serveur (SYSTEM RELOAD USERS). Spécifiez pour chaque utilisateur un profil (<profile>default</profile>), un quota (<quota>default</quota>) et une liste réseau (<networks><ip>10.0.0.0/8</ip></networks>). Enfin, activez la compression LZ4 dans config.d/compression.xml : c'est le codec par défaut de ClickHouse pour les colonnes, mais le définir explicitement garantit son application sur toutes les tables y compris celles créées avant la modification. LZ4 offre un bon équilibre entre taux de compression et vitesse de décompression à la lecture — pour un stockage encore plus compact au détriment d'un CPU légèrement plus sollicité, ZSTD (niveau 1 à 3) est une alternative viable sur les colonnes rarement requêtées.

ClickHouse est une alternative naturelle à Elasticsearch pour les pipelines de logs analytiques. Là où Elasticsearch indexe chaque champ de chaque document en JSON et consomme une mémoire de JVM importante, ClickHouse stocke chaque colonne séparément et compresse les valeurs répétitives (niveau de log, hostname, service) de façon extrêmement efficace. Pour un pipeline de logs, créez une table logs avec un moteur MergeTree partitionné par jour (PARTITION BY toDate(timestamp)) et trié par (service, timestamp). Ingérez via l'API HTTP en INSERT batch (voir la section performance ci-dessous) ou via Vector.dev, Fluent Bit ou Filebeat qui disposent tous d'un output ClickHouse natif. Pour les métriques time-series, le moteur MergeTree avec une ORDER BY (metric_name, timestamp) convient pour des volumes modérés. À plus grande échelle, le moteur AggregatingMergeTree permet de pré-agréger les données au merge, réduisant encore l'empreinte et accélérant les requêtes de tendances (avg, quantile, count). Une requête typique sur 500 millions de lignes filtrées par un intervalle de temps et groupées par service s'exécute en 2 à 8 secondes sur un VPS 4 vCPU / 8 Go selon l'index — souvent nettement plus rapide que les bases OLTP pour l'analytique qu'une base relationnelle standard.

Le comportement d'écriture de ClickHouse est fondamentalement différent des bases OLTP. Chaque INSERT crée une nouvelle part sur le disque, et ClickHouse fusionne ces parts en arrière-plan (merge). Si vous insérez ligne par ligne ou en petits lots (moins de 1000 lignes), vous inondez le système de petites parts — le merge ne suit plus, les performances se dégradent et vous obtenez l'erreur Too many parts (au-delà de 300 parts actives par partition). La règle d'or est d'insérer par lots de 10 000 à 100 000 lignes minimum, et d'espacer les insertions d'au moins une seconde si vous insérez en continu depuis plusieurs sources. Depuis un script Python, utilisez clickhouse-driver ou clickhouse-connect avec l'option insert_block_size pour contrôler la taille des blocs. Depuis Node.js, le client officiel @clickhouse/client expose une API de streaming qui construit les batches automatiquement. Surveillez la santé des parts en temps réel avec SELECT table, count() as parts, sum(rows) FROM system.parts WHERE active GROUP BY table ORDER BY parts DESC — si une table dépasse 100 parts actives, c'est un signal d'alerte.

Trois erreurs reviennent régulièrement lors du déploiement de ClickHouse sur un VPS. Too many parts : vous insérez en trop petits lots ; regroupez vos inserts, ajoutez un buffer applicatif, ou utilisez le moteur Buffer comme table intermédiaire qui vide automatiquement vers la table principale. Erreur OOM (Killed, Memory limit exceeded) : la requête a consommé plus de RAM que max_memory_usage le permet. Augmentez ce paramètre dans le profil utilisateur, ajoutez la clause LIMIT à vos requêtes exploratoires, ou passez à un VPS avec plus de RAM. Une requête sans filtre sur une table de plusieurs milliards de lignes peut consommer plusieurs Go en une seconde. Permission denied sur /var/lib/clickhouse : l'utilisateur système clickhouse (UID 101 dans l'image Docker officielle) n'a pas les droits en écriture sur le volume monté. Lors du premier démarrage, exécutez chown -R 101:101 /votre/chemin/clickhouse-data sur l'hôte avant de lancer le conteneur. Si ClickHouse a démarré mais ne répond pas sur le port 8123, vérifiez les logs avec docker logs <nom-du-conteneur> — l'erreur de permission y est explicitement affichée.

Tout ce qui précède se fait à la main, et c'est utile de savoir le faire. Si vous préférez ne pas le faire, ClickHouse figure au Marketplace ServOrbit et s'installe sur votre VPS en un clic. Le modèle déploie la version 26.3 LTS épinglée, monte les volumes persistants pour les données et les journaux, porte la limite de descripteurs de fichiers à 262144 comme l'exige ClickHouse, et crée une base analytics au premier démarrage. Il ferme surtout le piège le plus courant du déploiement manuel : l'image d'origine livre un compte default sans aucun mot de passe, et l'installation le retire au démarrage pour le remplacer par un compte admin dont le mot de passe est généré pour votre serveur et affiché dans votre espace client. Seul le port 8123 est publié, et uniquement sur la boucle locale : attachez un domaine et la console SQL intégrée répond sur https://<votre-domaine>/play avec son certificat TLS ; sans domaine, passez par un tunnel ssh -L 8123:127.0.0.1:8123 root@<ip-du-vps> puis http://localhost:8123/play.