Passer au contenu principal

​
Recherche dans ClickStack et Elastic

ClickHouse est un moteur nativement SQL, conçu dès le départ pour les charges de travail analytiques à hautes performances. À l’inverse, Elasticsearch propose une interface de type SQL, en transpilant le SQL vers le DSL de requête Elasticsearch sous-jacent — autrement dit, SQL n’y est pas pris en charge nativement, et la parité fonctionnelle reste limitée. ClickHouse prend non seulement en charge l’ensemble du SQL, mais l’étend également avec une série de fonctions axées sur l’observabilité, comme argMax, histogram et quantileTiming, qui simplifient les requêtes sur des logs, metrics et traces structurés. Pour explorer simplement les logs et les traces, la ClickStack UI (HyperDX) fournit une syntaxe de type Lucene permettant un filtrage textuel intuitif sur des requêtes champ-valeur, des plages, des caractères génériques, etc. Cela est comparable à la syntaxe Lucene dans Elasticsearch, ainsi qu’à certains éléments du Kibana Query Language. L’interface de recherche prend en charge cette syntaxe familière, mais la traduit en arrière-plan en clauses SQL WHERE efficaces. L’expérience reste ainsi familière pour les utilisateurs de Kibana, tout en leur permettant d’exploiter, si nécessaire, toute la puissance du SQL. Vous pouvez ainsi tirer parti de toute la gamme des string search functions, des similarity functions et des fonctions de date et heure dans ClickHouse. Ci-dessous, nous comparons les langages de requête Lucene de ClickStack et d’Elasticsearch.

​
Syntaxe de recherche ClickStack vs query string Elasticsearch

ClickStack et Elasticsearch offrent tous deux des langages de requête flexibles pour permettre un filtrage intuitif des logs et des traces. Alors que le query string d’Elasticsearch est étroitement intégré à son DSL et à son moteur d’indexation, ClickStack prend en charge une syntaxe inspirée de Lucene, traduite en ClickHouse SQL en arrière-plan. Le tableau ci-dessous montre le comportement des modèles de recherche courants dans les deux systèmes, en soulignant les similitudes de syntaxe et les différences d’exécution côté backend.

​
Différences entre existence et valeur manquante

Contrairement à Elasticsearch, où un champ peut être entièrement omis d’un événement et donc réellement « ne pas exister », ClickHouse exige que toutes les colonnes d’un schéma de table soient présentes. Si un champ n’est pas fourni dans un événement d’insertion :
  • Pour les champs Nullable, il sera défini sur NULL.
  • Pour les champs non nullables (par défaut), il recevra une valeur par défaut (souvent une chaîne vide, 0 ou une valeur équivalente).
Dans ClickStack, nous utilisons ce second cas, car Nullable est déconseillé. Cela signifie qu’il n’est pas possible de vérifier directement si un champ « existe » au sens d’Elasticsearch. À la place, vous pouvez utiliser field:* ou field != '' pour vérifier la présence d’une valeur non vide. Il n’est donc pas possible de distinguer un champ réellement manquant d’un champ explicitement vide. En pratique, cette différence pose rarement problème pour les cas d’usage d’observabilité, mais il est important de la garder à l’esprit lors de la traduction de requêtes d’un système à l’autre.
Dernière modification le 2 juillet 2026