Comment envoyer des données blockchain dans ClickHouse ?
Mis à jour en août 2026
Exécutez un sink SQL Substreams vers ClickHouse. Votre module transforme et émet un message Protobuf par bloc — le sink se charge de l'écrire dans vos tables, en rejouant l'historique en parallèle avant de passer en streaming continu.
ClickHouse est naturellement adapté aux données blockchain : la charge est en append massif, ordonnée dans le temps et analytique — exactement ce pour quoi il est conçu.
Dois-je faire tourner le sink moi-même ?
Non. Hosted Sinks s'en charge pour vous — configurez un package et les informations de connexion à votre ClickHouse sur The Graph Market, et il indexe en continu sans infrastructure de votre côté. Il existe un guide documenté pour ClickHouse Cloud.
C'est en bêta, et votre instance ClickHouse doit être accessible depuis internet. Sinon, faites tourner le sink vous-même comme décrit ci-dessous — mais il vous faut d'abord votre propre base ClickHouse, auto-hébergée ou managée. En déployer une prend généralement quelques minutes ; voir le guide ClickHouse Cloud pour le chemin le plus rapide, même si vous comptez faire tourner le sink vous-même. Le package Substreams reste le même dans les deux cas.
Pourquoi ClickHouse pour les données onchain ?
Les données blockchain ont une forme particulière — volume énorme, naturellement ordonnées par bloc, interrogées avec des agrégations sur des plages temporelles. Le stockage orienté colonnes gère cela bien mieux qu'un stockage en lignes.
La différence pratique se voit sur des requêtes comme le volume quotidien par pool sur deux ans, ou des agrégats par wallet sur tout l'historique d'un token. Sur Postgres, ces requêtes deviennent lentes et exigent un indexage soigné. Sur ClickHouse, elles sont banales.
| Postgres | ClickHouse | |
|---|---|---|
| Idéal pour | État applicatif, transactions | Analytique, agrégations, séries temporelles |
| Mises à jour | Peu coûteuses | Coûteuses — privilégier l'append |
| Grosses agrégations | Nécessite du tuning | Natif |
| Usage typique | Servir une application | Dashboards, recherche, reporting |
Comment concevoir le schéma ?
Trois décisions comptent plus que les autres.
Clé d'ordre (ordering key). Généralement le numéro de bloc en premier, puis ce sur quoi vous filtrez le plus. C'est ce qui influence le plus la compression et les performances de requête.
Moteur de table. MergeTree pour du pur append. ReplacingMergeTree quand vous devez corriger des lignes — ce qui arrive, à cause des reorgs.
Vues matérialisées. Pré-agrégez les rollups que vous interrogez régulièrement plutôt que de les recalculer à chaque fois. C'est de là que vient l'essentiel de l'avantage pratique de ClickHouse.
L'agent skill substreams-sql couvre les patterns spécifiques à ClickHouse, notamment les schémas optimisés pour l'analytique, les vues matérialisées et la conception en série temporelle — un chemin plus rapide vers un schéma sensé que de le déduire à partir de zéro.
Comment fonctionnent les reorgs avec un stockage orienté append ?
C'est le point délicat. ClickHouse n'aime pas les mises à jour ligne par ligne, mais les reorgs demandent de corriger des données déjà écrites.
L'approche habituelle est ReplacingMergeTree avec une colonne de version, de sorte que les lignes corrigées remplacent les précédentes lors du merge. Pour les vues matérialisées en particulier, un pattern en delta fonctionne bien aussi : émettez une colonne de compte signée — +1 à l'insertion, -1 à la suppression ou lors d'un reorg — et agrégez avec SummingMergeTree, de sorte que les corrections deviennent de nouvelles lignes qui s'annulent plutôt que des mises à jour en place. Autre option : retarder les écritures d'une profondeur de confirmation — accepter un peu de latence en échange de n'écrire que des données finalisées.
Le choix dépend de si vos dashboards ont besoin du bloc courant ou peuvent tolérer d'être quelques blocs en retard. C'est le cas de la plupart des charges analytiques.
Qu'en est-il des très gros backfills ?
Le traitement historique s'exécute en parallèle, donc le côté extraction est rapide. La contrainte se situe généralement du côté de l'ingestion ClickHouse.
Augmentez la taille des batchs pour le backfill — bien au-delà de la valeur par défaut en streaming — et envisagez de charger dans une table de staging avant de basculer vers la table qui sert les requêtes. substreams-sink-deploy documente le réglage du flush et les modes de défaillance associés.
Questions fréquentes
Puis-je utiliser ClickHouse Cloud ? Oui. Il vous faut les informations de connexion et les droits d'écriture ; le sink ne se soucie pas de l'endroit où il est hébergé.
Dois-je utiliser Postgres ou ClickHouse ? Postgres pour l'état applicatif que vous lisez et mettez à jour de façon transactionnelle. ClickHouse pour l'analytique sur de grandes plages historiques. Beaucoup d'équipes utilisent les deux.
Puis-je streamer vers ClickHouse et Postgres depuis le même module ? Oui. La sortie d'un même module peut alimenter plusieurs sinks.
Obtenez une clé API sur thegraph.market — aucune information personnelle requise.
Voir aussi : Comment diffuser des données onchain vers une base de données ? · Comment envoyer des données blockchain dans Postgres ? · Qu'est-ce que l'ETL blockchain ?