Elastic Stack vs ClickStack
- UI and Alerting : des outils pour interroger les données, créer des dashboards et gérer les alertes.
- Storage and Query Engine : les systèmes backend chargés de stocker les données d’observabilité et d’exécuter les requêtes analytiques.
- Data Collection and ETL : des agents et des pipelines qui collectent les données de télémétrie et les traitent avant leur ingestion.
| Role | Elastic Stack | ClickStack | Comments |
|---|---|---|---|
| UI & Alerting | Kibana — dashboards, recherche et alertes | ClickStack UI (HyperDX) — UI en temps réel, recherche et alertes | Les deux constituent l’interface principale pour les utilisateurs, notamment pour les visualizations et la gestion des alertes. ClickStack UI est spécialement conçu pour l’observabilité et étroitement aligné sur la sémantique OpenTelemetry. |
| Storage & Query Engine | Elasticsearch — magasin de documents JSON avec inverted index | ClickHouse — base de données orientée colonnes avec moteur vectorisé | Elasticsearch s’appuie sur un inverted index optimisé pour la recherche ; ClickHouse utilise un stockage orienté colonnes et SQL pour des analytics à haute vitesse sur des données structurées et semi-structured. |
| Data Collection | Elastic Agent, Beats (par ex. Filebeat, Metricbeat) | OpenTelemetry Collector (edge + gateway) | Elastic prend en charge des expéditeurs personnalisés ainsi qu’un agent unifié géré par Fleet. ClickStack s’appuie sur OpenTelemetry, ce qui permet une collecte et un traitement des données indépendants du fournisseur. |
| Instrumentation SDKs | Elastic APM agents (propriétaires) | OpenTelemetry SDKs (distribués par ClickStack) | Les SDK d’Elastic sont liés à la stack Elastic. ClickStack s’appuie sur les OpenTelemetry SDKs pour les logs, metrics et traces dans les principaux langages. |
| ETL / Data Processing | Logstash, ingest pipelines | OpenTelemetry Collector + vues matérialisées ClickHouse | Elastic utilise les ingest pipelines et Logstash pour les transformations. ClickStack déplace le calcul au moment de l’insertion grâce aux vues matérialisées et aux processors de l’OTel collector, qui transforment les données de manière efficace et incrémentale. |
| Architecture Philosophy | Intégration verticale, agents et formats propriétaires | Composants faiblement couplés, fondés sur des standards ouverts | Elastic construit un écosystème étroitement intégré. ClickStack met l’accent sur la modularité et les standards (OpenTelemetry, SQL, stockage objet) pour offrir davantage de flexibilité et une meilleure efficacité des coûts. |
Elasticsearch vs ClickHouse
Concepts structurels fondamentaux
| Elasticsearch | ClickHouse / SQL | Description |
|---|---|---|
| Champ | Colonne | L’unité de base des données, qui contient une ou plusieurs valeurs d’un type donné. Les champs Elasticsearch peuvent stocker des types primitifs, ainsi que des tableaux et des objets. Un champ ne peut avoir qu’un seul type. ClickHouse prend aussi en charge les tableaux et les objets (Tuples, Maps, Nested), ainsi que des types dynamiques comme Variant et Dynamic, qui permettent à une colonne d’avoir plusieurs types. |
| Document | Ligne | Un ensemble de champs (colonnes). Les documents Elasticsearch sont plus flexibles par défaut, avec de nouveaux champs ajoutés dynamiquement en fonction des données (le type est déduit de ). Les lignes ClickHouse sont liées à un schéma par défaut, les utilisateurs devant insérer toutes les colonnes d’une ligne ou seulement un sous-ensemble. Le type JSON de ClickHouse permet une création équivalente de colonnes dynamiques semi-structurées à partir des données insérées. |
| Index | Table | L’unité d’exécution des requêtes et de stockage. Dans les deux systèmes, les requêtes s’exécutent sur des index ou des tables, qui stockent des lignes/documents. |
| Implicite | Schéma (SQL) | Les schémas SQL regroupent les tables dans des espaces de noms, souvent utilisés pour le contrôle d’accès. Elasticsearch et ClickHouse n’ont pas de schémas, mais tous deux prennent en charge la sécurité au niveau des lignes et des tables via les rôles et le RBAC. |
| Cluster | Cluster / Base de données | Les clusters Elasticsearch sont des environnements d’exécution qui gèrent un ou plusieurs index. Dans ClickHouse, les bases de données organisent les tables au sein d’un espace de noms logique, offrant le même regroupement logique qu’un cluster dans Elasticsearch. Un cluster ClickHouse est un ensemble distribué de nœuds, similaire à Elasticsearch, mais découplé et indépendant des données elles-mêmes. |
Modélisation des données et flexibilité
Dynamic, Variant et JSON. Ceux-ci permettent l’ingestion de données semi-structurées, avec création dynamique de colonnes et inférence de type, comme dans Elasticsearch. De même, le type Map permet de stocker des paires clé-valeur arbitraires — même si un seul type est imposé à la fois pour la clé et pour la valeur.
L’approche de ClickHouse en matière de flexibilité des types est plus transparente et mieux maîtrisée. Contrairement à Elasticsearch, où des conflits de types peuvent entraîner des erreurs d’ingestion, ClickHouse autorise les données de types mixtes dans les colonnes Variant et prend en charge l’évolution du schéma via le type JSON.
Si vous n’utilisez pas JSON, le schéma est défini statiquement. Si aucune valeur n’est fournie pour une ligne, les champs concernés doivent soit être définis comme Nullable (non utilisé dans ClickStack), soit prendre la valeur par défaut du type, par exemple une valeur vide pour String.
Ingestion et transformation
enrich, rename, grok) pour transformer les documents avant leur indexation. Dans ClickHouse, une fonctionnalité similaire est assurée par les vues matérialisées incrémentielles, qui peuvent filtrer, transformer ou enrichir les données entrantes et insérer les résultats dans des tables cibles. Vous pouvez également insérer des données dans un moteur de table Null si vous souhaitez uniquement stocker la sortie de la vue matérialisée. Cela signifie que seuls les résultats des vues matérialisées sont conservés, tandis que les données d’origine sont supprimées, ce qui permet d’économiser de l’espace de stockage.
Pour l’enrichissement, Elasticsearch prend en charge des processeurs d’enrichissement dédiés afin d’ajouter du contexte aux documents. Dans ClickHouse, les dictionnaires peuvent être utilisés à la fois à l’exécution de la requête et au moment de l’ingestion pour enrichir les lignes - par exemple, pour associer des adresses IP à des lieux ou effectuer des lookups de user-agent à l’insertion.
Langages de requête
ES|QL. ClickHouse prend en charge l’ensemble de la syntaxe SQL, y compris tous les types de jointures, les fonctions de fenêtre, les sous-requêtes (y compris les sous-requêtes corrélées) et les CTE. C’est un avantage majeur si vous devez corréler les signaux d’observabilité avec des données métier ou d’infrastructure.
Dans ClickStack, l’UI fournit une interface de recherche compatible avec Lucene pour faciliter la transition, avec en parallèle la prise en charge complète de SQL via le backend ClickHouse. Cette syntaxe est comparable à la syntaxe query string d’Elastic. Pour une comparaison précise de cette syntaxe, consultez « Rechercher dans ClickStack et Elastic ».
Formats de fichiers et interfaces
Indexation et stockage
Traitement des insertions dans ElasticsearchⒶ Les documents nouvellement insérés Ⓑ passent d’abord dans un tampon d’indexation en mémoire, vidé par défaut une fois par seconde. Une formule de routage est utilisée pour déterminer le shard cible des documents vidés, puis un nouveau segment est écrit sur disque pour ce shard. Pour améliorer l’efficacité des requêtes et permettre la suppression physique des documents supprimés ou mis à jour, les segments sont fusionnés en continu en arrière-plan dans des segments plus volumineux, jusqu’à atteindre une taille maximale de 5 Go. Il est toutefois possible de forcer une fusion vers des segments plus grands.
_source (compressé avec LZ4, Deflate ou ZSTD), tandis que ClickHouse ne stocke pas de représentation distincte du document. Les données sont reconstruites à partir des colonnes au moment de la requête, ce qui économise de l’espace de stockage. Cette même capacité existe dans Elasticsearch avec Synthetic _source, avec certaines restrictions. La désactivation de _source a également des conséquences qui ne s’appliquent pas à ClickHouse.
Dans Elasticsearch, les mappings d’index (l’équivalent des schémas de table dans ClickHouse) contrôlent le type des champs et les structures de données utilisées pour ce stockage et ces requêtes.
ClickHouse, à l’inverse, est orienté colonnes : chaque colonne est stockée indépendamment, mais toujours triée selon la clé primaire/de tri de la table. Cet ordre permet d’utiliser des index primaires clairsemés, qui permettent à ClickHouse d’ignorer efficacement certaines données pendant l’exécution des requêtes. Lorsque les requêtes filtrent sur les champs de la clé primaire, ClickHouse ne lit que les parties pertinentes de chaque colonne, ce qui réduit considérablement les E/S disque et améliore les performances, même sans index complet sur chaque colonne.
ClickHouse prend également en charge les index de saut, qui accélèrent le filtrage en précalculant des données d’index pour les colonnes sélectionnées. Ils doivent être définis explicitement, mais peuvent améliorer considérablement les performances. En outre, ClickHouse vous permet de spécifier des codecs de compression et des algorithmes de compression par colonne, ce qu’Elasticsearch ne prend pas en charge (sa compression s’applique uniquement au stockage JSON de _source).
ClickHouse prend également en charge le sharding, mais son modèle est conçu pour privilégier la mise à l’échelle verticale. Un seul shard peut stocker des milliers de milliards de lignes et rester performant tant que la mémoire, le CPU et le disque le permettent. Contrairement à Elasticsearch, il n’existe pas de limite stricte du nombre de lignes par shard. Dans ClickHouse, les shards sont logiques — en pratique, des tables individuelles — et ne nécessitent pas de partitionnement, sauf si le jeu de données dépasse la capacité d’un seul nœud. Cela se produit généralement en raison de contraintes de capacité disque, le sharding ① n’étant introduit que lorsqu’une montée en charge horizontale est nécessaire, ce qui réduit la complexité et le surcoût. Dans ce cas, comme avec Elasticsearch, un shard contiendra un sous-ensemble des données. Les données au sein d’un shard unique sont organisées comme une collection de ② parties de données immuables contenant ③ plusieurs structures de données.
Le traitement au sein d’un shard ClickHouse est entièrement parallélisé, et les utilisateurs sont encouragés à privilégier la mise à l’échelle verticale pour éviter les coûts réseau liés au déplacement des données entre les nœuds.
Traitement des insertions dans ClickHouseLes insertions dans ClickHouse sont synchrones par défaut — l’écriture n’est confirmée qu’après le commit — mais peuvent être configurées en insertions asynchrones pour retrouver un buffering et un batching de type Elastic. Si des insertions de données asynchrones sont utilisées, les lignes Ⓐ nouvellement insérées vont d’abord dans un Ⓑ tampon d’insertion en mémoire, qui est vidé par défaut toutes les 200 millisecondes. Si plusieurs shards sont utilisés, une table distribuée sert à acheminer les lignes nouvellement insérées vers leur shard cible. Une nouvelle partie est écrite sur disque pour le shard.
Distribution et réplication
SELECT à tous les shards puis en fusionnant les résultats. Pour les opérations INSERT, elles répartissent la charge en distribuant uniformément les données entre les shards. La réplication de ClickHouse est très souple : toute réplique (copie d’un shard) peut accepter des écritures, et toutes les modifications sont synchronisées de façon asynchrone avec les autres. Cette architecture permet d’assurer le service des requêtes sans interruption pendant les pannes ou les opérations de maintenance, avec une resynchronisation gérée automatiquement - ce qui élimine la nécessité d’imposer un modèle primaire-secondaire au niveau de la couche de données.
ClickHouse CloudDans ClickHouse Cloud, l’architecture introduit un modèle de calcul shared-nothing dans lequel un seul shard s’appuie sur le stockage objet. Cela remplace la haute disponibilité traditionnelle fondée sur les répliques, en permettant au shard d’être lu et écrit simultanément par plusieurs nœuds. La séparation du stockage et du calcul permet une mise à l’échelle élastique sans gestion explicite des répliques.
- Elastic : Les shards sont des structures Lucene physiques liées à la mémoire JVM. Une fragmentation excessive en shards entraîne des pénalités de performance. La réplication est synchrone et coordonnée par un nœud maître.
- ClickHouse : Les shards sont logiques et extensibles verticalement, avec une exécution locale très efficace. La réplication est asynchrone (mais peut être séquentielle), et la coordination est légère.
Déduplication et routage
_id et les achemine en conséquence vers les shards appropriés. ClickHouse ne stocke pas d’identifiant de ligne par défaut, mais prend en charge la déduplication à l’insertion, ce qui permet aux utilisateurs de relancer sans risque les inserts ayant échoué. Pour un contrôle plus fin, ReplacingMergeTree et d’autres moteurs de table permettent la déduplication sur des colonnes spécifiques.
Le routage des index dans Elasticsearch garantit que certains documents sont toujours acheminés vers des shards spécifiques. Dans ClickHouse, vous pouvez définir des clés de sharding ou utiliser des tables Distributed pour obtenir une localité des données similaire.
Agrégations et modèle d’exécution
SELECT count(*) FROM ... GROUP BY ... est la terms aggregation, qui est une bucket aggregation d’Elasticsearch.
Le GROUP BY de ClickHouse avec count(*) et la terms aggregation d’Elasticsearch sont généralement équivalents sur le plan fonctionnel, mais diffèrent fortement par leur implémentation, leurs performances et la qualité des résultats.
Dans Elasticsearch, cette agrégation estime les résultats des requêtes « top-N » (par exemple, les 10 premiers hôtes par nombre d’occurrences) lorsque les données interrogées s’étendent sur plusieurs shards. Cette estimation améliore la vitesse, mais peut compromettre la précision. Vous pouvez réduire cette erreur en inspectant doc_count_error_upper_bound et en augmentant le paramètre shard_size — au prix d’une consommation mémoire plus élevée et de performances de requête dégradées.
Elasticsearch exige également un size setting pour toutes les agrégations par bucket — il n’existe aucun moyen de renvoyer tous les groupes uniques sans définir explicitement une limite. Les agrégations à forte cardinalité risquent d’atteindre les limites max_buckets ou nécessitent une pagination avec une composite aggregation, ce qui est souvent complexe et peu efficace.
ClickHouse, en revanche, effectue des agrégations exactes prêtes à l’emploi. Des fonctions comme count(*) renvoient des résultats précis sans nécessiter d’ajustements de configuration, ce qui rend le comportement des requêtes plus simple et plus prévisible.
ClickHouse n’impose aucune limite de taille. Vous pouvez exécuter des requêtes group-by non bornées sur de grands jeux de données. Si les seuils de mémoire sont dépassés, ClickHouse peut écrire sur disque. Les agrégations qui regroupent sur un préfixe de la clé primaire sont particulièrement efficaces et s’exécutent souvent avec une consommation mémoire minimale.
Modèle d’exécution
- Vectorisation SIMD : les opérations sur des données en colonnes utilisent des instructions SIMD du CPU (par ex. AVX512), ce qui permet de traiter des lots de valeurs.
- Parallélisme au niveau du cluster : dans les déploiements distribués, chaque nœud effectue le traitement des requêtes localement. Les états d’agrégation partiels sont transmis en flux au nœud initiateur, puis fusionnés. Si les clés
GROUP BYde la requête correspondent aux clés de partitionnement, la fusion peut être réduite au minimum, voire complètement évitée.
Ce modèle permet une mise à l’échelle efficace entre les cœurs et les nœuds, ce qui fait de ClickHouse une solution bien adaptée à l’analytique à grande échelle. L’utilisation d’états d’agrégation partiels permet de fusionner les résultats intermédiaires provenant de différents threads et nœuds sans perte de précision. Elasticsearch, en revanche, attribue un thread par shard pour la plupart des agrégations, quel que soit le nombre de cœurs CPU disponibles. Ces threads renvoient des résultats top-N locaux au shard, qui sont fusionnés sur le nœud coordinateur. Cette approche peut sous-utiliser les ressources système et introduire d’éventuelles imprécisions dans les agrégations globales, en particulier lorsque des termes fréquents sont répartis sur plusieurs shards. La précision peut être améliorée en augmentant le paramètre
shard_size, mais cela se fait au prix d’une utilisation mémoire plus élevée et d’une latence accrue des requêtes.
En résumé, ClickHouse exécute les agrégations et les requêtes avec un parallélisme plus fin et un contrôle accru des ressources matérielles, tandis qu’Elasticsearch repose sur une exécution basée sur les shards, avec des contraintes plus rigides.
Pour plus de détails sur les mécanismes des agrégations dans ces technologies respectives, nous recommandons l’article de blog “ClickHouse vs. Elasticsearch: The Mechanics of Count Aggregations”.
Gestion des données
Gestion du cycle de vie des index vs TTL natif
Paliers de stockage et architectures hot-warm
MergeTree, qui peuvent déplacer automatiquement les données plus anciennes entre différents volumes (par exemple, de SSD vers HDD puis vers le stockage objet) selon des règles personnalisées. Cela permet de reproduire l’approche hot-warm-cold d’Elastic — mais sans la complexité liée à la gestion de plusieurs rôles de nœuds ou de clusters.
ClickHouse CloudDans ClickHouse Cloud, cela devient encore plus fluide : toutes les données sont stockées sur le stockage objet (par ex. S3), et la puissance de calcul est découplée. Les données peuvent rester dans le stockage objet jusqu’à ce qu’elles soient interrogées, auquel cas elles sont récupérées et mises en cache localement (ou dans un distributed cache) — offrant le même profil de coût que le palier frozen d’Elastic, avec de meilleures performances. Avec cette approche, il n’est plus nécessaire de déplacer les données entre différents paliers de stockage, ce qui rend les architectures hot-warm superflues.
Rollups vs agrégations incrémentielles
blue (11, 12 et 13) apparus depuis le checkpoint précédent. L’index source est donc filtré pour récupérer tous les documents blue existants, puis, à l’aide d’une composite aggregation (afin de tirer parti de la pagination des résultats), les valeurs agrégées sont recalculées (et l’index de destination est mis à jour avec un document qui remplace celui contenant les valeurs d’agrégation précédentes). De même, en ② et ③, de nouveaux checkpoints sont traités en vérifiant les changements puis en recalculant les valeurs agrégées à partir de tous les documents existants appartenant au même bucket blue.
ClickHouse adopte une approche fondamentalement différente. Plutôt que de réagréger périodiquement les données, ClickHouse prend en charge les vues matérialisées incrémentielles, qui transforment et agrègent les données au moment de l’insertion. Lorsque de nouvelles données sont écrites dans une table source, une vue matérialisée exécute une requête SQL d’agrégation prédéfinie uniquement sur les blocs insérés et écrit les résultats agrégés dans une table cible.
Ce modèle est rendu possible par la prise en charge par ClickHouse des états d’agrégation partiels — des représentations intermédiaires de fonctions d’agrégation qui peuvent être stockées puis fusionnées ultérieurement. Cela permet de conserver des résultats partiellement agrégés, rapides à interroger et peu coûteux à mettre à jour. Comme l’agrégation se produit à mesure que les données arrivent, il n’est pas nécessaire d’exécuter des tâches récurrentes coûteuses ni de résumer à nouveau les données plus anciennes.
Nous illustrons abstraitement le mécanisme des vues matérialisées incrémentielles (notez que nous utilisons la couleur bleue pour toutes les lignes appartenant au même groupe pour lequel nous voulons précalculer des valeurs agrégées) :
Dans le schéma ci-dessus, la table source de la vue matérialisée contient déjà une partie de données stockant certaines lignes blue (de 1 à 10) appartenant au même groupe. Pour ce groupe, il existe déjà aussi une partie de données dans la table cible de la vue stockant un état d’agrégation partiel pour le groupe blue. Lorsque les insertions ① ② ③ de nouvelles lignes dans la table source ont lieu, une partie de données correspondante est créée dans la table source pour chaque insertion et, en parallèle, pour chaque block de lignes nouvellement insérées, un état d’agrégation partiel est calculé puis inséré sous la forme d’une partie de données dans la table cible de la vue matérialisée. ④ Lors des fusions de parts en arrière-plan, les états d’agrégation partiels sont fusionnés, ce qui produit une agrégation incrémentielle des données.
Notez que toutes les fonctions d’agrégation (plus de 90), y compris leurs combinaisons avec les combinators de fonctions d’agrégation, prennent en charge les états d’agrégation partiels.
Pour un exemple plus concret d’Elasticsearch vs ClickHouse pour les agrégats incrémentiels, consultez cet exemple.
Les avantages de l’approche de ClickHouse incluent :
- Agrégats toujours à jour : les vues matérialisées restent toujours synchronisées avec la table source.
- Aucune tâche en arrière-plan : les agrégations sont effectuées à l’insert plutôt qu’au moment de la requête.
- Meilleures performances en temps réel : idéal pour les charges de travail d’observabilité et l’analytique en temps réel, lorsque des agrégats frais sont nécessaires immédiatement.
- Composable : les vues matérialisées peuvent être superposées ou jointes à d’autres vues et tables pour mettre en place des stratégies plus complexes d’accélération des requêtes.
- TTL distincts : des paramètres TTL différents peuvent être appliqués à la table source et à la table cible de la vue matérialisée.
Prise en charge du lakehouse
- Intégration avec un Data Catalog : ClickHouse prend en charge l’intégration avec des catalogues de données comme AWS Glue, ce qui permet la découverte automatique des tables dans le stockage objet et leur accès.
- Prise en charge du stockage objet : prise en charge native de l’interrogation des données stockées dans S3, GCS et Azure Blob Storage, sans nécessiter de déplacement des données.
- Fédération de requêtes : la capacité à corréler des données provenant de plusieurs sources, notamment des tables lakehouse, des bases de données traditionnelles et des tables ClickHouse, à l’aide de dictionnaires externes et de fonctions de table.
- Chargement incrémentiel : prise en charge du chargement continu depuis des tables lakehouse vers des tables locales MergeTree, à l’aide de fonctionnalités telles que S3Queue et ClickPipes.
- Optimisation des performances : exécution distribuée des requêtes sur des données lakehouse à l’aide des fonctions cluster, pour améliorer les performances.