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" toutes mes données que je devais indexer dans ElasticSearch, et les envoyer à ElasticSearch. Ensuite, après une migration ou toute autre mise à jour/remplacement des données MySQL, j'essaie de comprendre la partie réindexation du côté d'ElasticSearch », a poursuivi Sidashin.
Quelques inconvénients de ClickHouse
Selon Sidashin, il y a tout de même des inconvénients pour ClickHouse, par rapport à ElasticSearch. « Tout d'abord, si vous créez des analyses internes pour le stockage des journaux, vous voulez obtenir le meilleur outil d'interface graphique. Et Kibana est bon à cet effet de nos jours quand on le compare à Grafana. Et vous devez vous en tenir à Grafana ou Redash si vous utilisez ClickHouse », a-t-il déclaré. Mais, dans le cas du projet ApiRoad.net, Sidashin a déclaré qu'ils construisent des analyses orientées client, ce qui signifie qu'ils doivent construire une interface graphique d'analyse à partir de zéro.
Il cite aussi un autre problème lié à l'écosystème : la sélection des outils à consommer, à traiter les données et à les envoyer à ClickHouse serait quelque peu limitée. Selon lui, pour Elasticsearch, il existe Logstash et filebeat, des outils natifs de l'écosystème Elastic, et conçus pour fonctionner ensemble. « Heureusement, Logstash peut également être utilisé pour envoyer des données à ClickHouse, ce qui atténue le problème », a-t-il déclaré. Dans ApiRoad.net, il a déclaré qu'ils utilisent leur propre expéditeur de journaux Node.js, construit sur mesure, qui regroupe les journaux et les envoie ensuite à ClickHouse par lots.
Conclusion
« ElasticSearch est une solution très puissante, mais je pense que son côté le plus fort reste les énormes configurations avec plus de 10 nœuds, utilisées pour la recherche à grande échelle et les facettes, l'indexation complexe et le calcul des scores. C'est là que ElasticSearch brille. Lorsque nous parlons de séries chronologiques et de stockage de journaux, j'ai le sentiment qu'il existe de meilleures solutions, et ClickHouse est l'une d'entre elles. L'API d'ElasticSearch est énorme, et dans de nombreux cas, il est difficile de se rappeler comment faire une chose précise sans copier la requête HTTP exacte de la documentation. Cela semble juste "entreprenant" et "à saveur Java" », a-t-il déclaré.
Selon lui, ClickHouse et ElasticSearch sont des applications gourmandes en mémoire, mais la mémoire vive requise pour une installation minimale de ClickHouse en production est de 4 Go, et pour ElasticSearch, elle est d'environ 16 Go. « Je pense également que l'attention de l'équipe Elastic devient assez large et floue avec toutes les nouvelles fonctionnalités d'apprentissage automatique qu'elle déploie. Mon humble avis est que, bien que ces fonctions semblent très modernes et à la mode, il est tout simplement impossible de les prendre en charge et de les améliorer, quels que soient le nombre de développeurs et le budget dont vous disposez. Je me trompe peut-être », explique-t-il.
« Clickhouse est tout simplement différent. L'installation est facile. Le SQL est facile. Le client de console est merveilleux. Tout semble si léger et logique, même pour les petites installations, mais les fonctionnalités, les répliques et les tessons de données sont là quand vous en avez besoin », a conclu Sidashin.
Source : Anton Sidashin
Et vous ?
Quel est votre avis sur le sujet ? Quelle comparaison faites-vous entre ElasticSearch et ClickHouse ?Voir aussi
Google Cloud Platform afficherait désormais de meilleures performances que Microsoft Azure et AWS, selon un rapport de Cockroach Labs L'équation des revenus du Cloud : AWS égale à Azure + Google + Alibaba, alors que la reprise du confinement en Europe et les charges de travail liées à la 5G promettent une nouvelle hausse du Cloud Google Cloud Platform parvient à se rapprocher des performances d'AWS et de Microsoft Azure, selon un rapport 
