ClickHouse est-il une meilleure alternative à Elasticsearch pour le stockage et l'analyse des journaux ? Oui

Selon le développeur Anton Sidashin

ClickHouse est-il une meilleure alternative à Elasticsearch pour le stockage et l'analyse des journaux ?
oui, selon le développeur Anton Sidashin

L'analyse des journaux (logs) est le processus d'examen, d'interprétation et de compréhension des enregistrements générés par ordinateur appelés journaux. Les journaux sont générés par une série de technologies programmables, notamment des dispositifs de réseau, des systèmes d'exploitation, des applications, etc. Un journal est constitué d'une série de messages en séquence temporelle qui décrivent les activités se déroulant au sein d'un système. Les fichiers journaux peuvent être transmis en continu à un collecteur de journaux via un réseau actif, ou être stockés dans des fichiers pour un examen ultérieur.

Dans les deux cas, l'analyse des journaux est l'art "délicat" d'examiner et d'interpréter ces messages afin d'obtenir un aperçu des rouages internes du système. Grâce à l'analyse des journaux, les équipes ont la possibilité de découvrir les problèmes bien avant qu'ils ne surviennent ou au moment où ils surviennent, et d'éviter les retards inutiles et la perte de temps critique. L'analyse des journaux de votre entreprise vous apporte toute une série d'avantages. Par exemple, votre entreprise réagit mieux aux incidents, réduit ses dépenses, contribue à augmenter ses revenus et s'assure que vous travaillez dans le respect des exigences légales.


Dans un billet publié sur son site Web personnel, Anton Sidashin, développeur au sein du projet ApiRoad.net (un marché d'API où les développeurs vendent leurs API), estime que ClickHouse est une meilleure alternative à ElasticSearch pour le stockage et l'analyse des journaux. Pour rappel, ClickHouse est un système de gestion de base de données open source orienté colonne qui permet de générer des rapports de données analytiques en temps réel à l'aide de requêtes SQL. Il a été développé par la société informatique russe Yandex pour son service d'analyse Web Yandex.Metrica.

Le système est commercialisé pour ses hautes performances. En outre, ElasticSearch est un moteur de recherche et d'analyse distribué, gratuit et ouvert pour tous les types de données, y compris les données textuelles, numériques, géospatiales, structurées et non structurées. ElasticSearch est construit sur Apache Lucene et a été publié pour la première fois en 2010 par ElasticSearch N.V. (maintenant connu sous le nom de Elastic). Sidashin a déclaré qu'après une analyse en profondeur, l'équipe d'ApiRoad.net a préféré utiliser ClickHouse en lieu et place d'ElasticSearch ou de MySQL.

« Étant moi-même développeur d'API, je sais combien l'observabilité et l'analyse du cycle requête/réponse HTTP sont importantes pour maintenir la qualité du service et détecter rapidement les bogues, cela est particulièrement vrai pour le service API pur », a-t-il déclaré. Voici ci-dessous les principales raisons pour lesquelles son équipe et lui ont choisi ClickHouse et non ElasticSearch (ou MySQL) comme solution de stockage des données essentielles d'ApiRoad.net, notamment les journaux des requêtes.

Prise en charge de SQL, JSON et Arrays

Sidashin estime que le langage SQL est parfait pour l'analyse. « J'adore le langage de requête SQL et le schéma SQL est un exemple parfait de technologie que je recommande d'utiliser pour traiter les données dans 99 % des projets : si le code du projet n'est pas parfait, vous pouvez l'améliorer relativement facilement si l'état de votre base de données est fortement structuré. Si l'état de votre base de données est un énorme blob JSON (NoSQL) et que personne ne peut saisir pleinement la structure de ces données, ce remaniement devient généralement beaucoup plus problématique », a-t-il déclaré.

« J'ai vu cela se produire, en particulier dans les projets plus anciens avec MongoDB, où chaque nouveau rapport d'analyse et chaque nouveau remaniement incluant une migration de données sont très pénibles. Démarrer de tels projets est amusant, car vous n'avez pas besoin de passer votre temps à concevoir soigneusement le schéma complet du projet, juste à "voir comment ça se passe", mais les maintenir n'est pas amusant », soutient-il. Toutefois, il a noté que cette règle (utiliser un schéma strict) empirique n'est pas si critique pour les cas d'utilisation de stockage de journaux.

Selon lui, c'est pour cette raison qu'ElasticSearch est un tel succès. Sidashin estime qu'ElasticSearch a un schéma flexible et de nombreux points forts, dont une bonne prise en charge de JSON qu'il voit comme un format très pratique pour les structures dynamiques (comme le stockage de journaux). Cela dit, il a déclaré que les SGBDR traditionnels rattrapent désormais ElasticSearch en matière d'interrogation et de syntaxe JSON. ClickHouse, par contre, maintiendrait un avantage spécifique sur ses concurrents, en particulier grâce à la prise en charge de SQL, JSON et Arrays.

Le développeur estime que ClickHouse n'a pas à porter le bagage de la rétrocompatibilité et des normes SQL strictes de ces SGBDR populaires. Cela signifierait que l'équipe de ClickHouse peut aller vite en matière de fonctionnalités et d'améliorations. Il estime que les développeurs de ClickHouse ont su trouver un équilibre entre des schémas relatifs stricts et la flexibilité de JSON. ClickHouse essaierait de rivaliser avec Google Big Query et d'autres grands acteurs dans le domaine de l'analyse. Ainsi, Sidashin suggère que c'est ce qui lui a permis d'obtenir de nombreuses améliorations par rapport au SQL "standard".

« Cela fait que sa syntaxe est une combinaison gagnante et, dans de nombreux cas, bien meilleure que celle des SGBDR classiques, à des fins d'analyse et de calculs divers », a-t-il déclaré. « Quelques exemples de base : dans MySQL, vous pouvez extraire des champs JSON. Mais les traitements JSON complexes, comme la jointure de données relationnelles sur des données JSON, ne sont disponibles que depuis peu, à partir de la version 8 avec la fonction JSON_TABLE. Dans PostgreSQL, la situation est encore pire. Il n'y a pas d'alternative directe à JSON_TABLE avant PostgreSQL 12 », a-t-il ajouté.

Selon Sidashin, il suffit de comparer tout ceci à la prise en charge de JSON de ClickHouse et à l'ensemble des fonctions de tableaux associées pour voir l'"énorme différence". « En ce qui concerne le langage de la requête, je ne suis toujours pas à l'aise avec la verbosité et l'approche de la syntaxe Lucene d'ElasticSearch, l'API HTTP, et toutes ces structures JSON qu'il faut écrire pour récupérer des données. Le SQL est mon choix préféré », a-t-il déclaré.

Schéma flexible, mais strict quand vous en avez besoin

Ici, Sidashin a expliqué que, pour les tâches de stockage des journaux, le schéma exact des données évolue souvent pendant la durée du projet, et ElasticSearch vous permet de mettre un "énorme" blob JSON dans l'index et de déterminer plus tard les types de champs et la partie d'indexation. Il estime que ClickHouse permet aussi d'utiliser la même approche. Autrement dit, vous pouvez mettre des données dans le champ JSON et les filtrer relativement rapidement, bien que cela ne soit pas rapide à l'échelle du téraoctet.


Sidashin continue en disant que, lorsque vous constatez que vous avez souvent besoin d'une exécution rapide des requêtes sur un champ de données spécifique, vous ajoutez des colonnes matérialisées à votre tableau de journaux, et ces colonnes extraient les valeurs des champs JSON existants à la volée. Selon Sidashin, cela permet d'effectuer des requêtes beaucoup plus rapides sur des téraoctets de données. En gros, il estime que JSON offre de meilleures performances pour le stockage des données de journaux que le schéma tabulaire.

Efficacité du stockage et de l'interrogation

Selon Sidashin, ClickHouse est très rapide en qui concerne les requêtes SELECT. « Ce qui est intéressant, c'est qu'il a été prouvé que ClickHouse peut être 5 à 6 fois plus efficace en matière de stockage, comparé à ElasticSearch, tout en étant littéralement un ordre de grandeur plus rapide en matière de requêtes », a-t-il déclaré. « Si l'on parle de MySQL, toute requête imparfaite, tout index manquant, sur une table contenant seulement 100 millions de lignes de données de log peut faire crawler et permuter votre serveur. MySQL n'est pas vraiment adapté aux requêtes de log à grande échelle », a ajouté le développeur.

Toutefois, ce dernier estime qu'en matière de stockage, les tables InnoDB compressées ne sont étonnamment pas si mauvaises. « Bien sûr, elle est bien pire en matière de compression que celle de ClickHouse, en raison de sa nature basée sur les lignes, mais elle parvient encore souvent à réduire les coûts de manière significative sans que cela affecte les performances. Nous utilisons des tableaux InnoDB compressés dans certains cas pour les journaux à petite échelle », a déclaré Sidashin.

Intégration étroite entre MySQL et ClickHouse

Selon Sidashin, MySQL et ClickHouse ont des intégrations à plusieurs niveaux, ce qui permet de les utiliser facilement avec un minimum de duplication de données. « Je ne peux pas dire avec certitude à quel point les moteurs de bases de données dynamiques et les moteurs de tables fonctionnent rapidement et de manière stable sur les requêtes JOIN. Cela nécessite certainement des points de repère, mais le concept est très attrayant. Vous avez un clone complet et à jour de vos tables MySQL sur votre base de données ClickHouse, et vous n'avez pas à vous occuper de l'invalidation et de la réindexation du cache », a-t-il déclaré.

« En ce qui concerne l'utilisation de MySQL avec Elasticsearch, mon expérience limitée me dit que ces deux technologies sont tout simplement trop différentes et j'ai l'impression qu'elles parlent des langues étrangères et ne jouent pas "ensemble". Donc ce que je faisais habituellement, c'était juste "JSONifier"...