Au cours des dernières années, les bases de données de séries chronologiques sont passées d’un objet farfelu (hautement spécialisé utilisé soit dans des systèmes de surveillance ouverts (et liées à des solutions spécifiques) soit dans des projets Big Data) à un « produit de consommation ». Sur le territoire de la Fédération de Russie, des remerciements particuliers doivent être adressés à Yandex et ClickHouse pour cela. Jusqu'à présent, si vous deviez stocker une grande quantité de données de séries chronologiques, vous deviez soit accepter la nécessité de créer une monstrueuse pile Hadoop et de la maintenir, soit communiquer avec des protocoles individuels pour chaque système.
Il peut sembler qu'en 2019, un article sur lequel TSDB mérite d'être utilisé ne contiendra qu'une seule phrase : « utilisez simplement ClickHouse ». Mais... il y a des nuances.
En effet, ClickHouse se développe activement, la base d'utilisateurs augmente et le support est très actif, mais sommes-nous devenus les otages du succès public de ClickHouse, qui a éclipsé d'autres solutions, peut-être plus efficaces/fiables ?
Au début de l'année dernière, nous avons commencé à retravailler notre propre système de surveillance, au cours duquel s'est posée la question du choix d'une base de données adaptée pour stocker les données. Je veux parler ici de l’histoire de ce choix.
Formulation du problème
Tout d’abord, une préface nécessaire. Pourquoi avons-nous besoin de notre propre système de surveillance et comment a-t-il été conçu ?
Nous avons commencé à fournir des services de support en 2008 et en 2010, il est devenu clair qu'il devenait difficile de regrouper les données sur les processus se déroulant dans l'infrastructure client avec les solutions qui existaient à l'époque (nous parlons de, Dieu me pardonne, Cacti, Zabbix et le graphite émergent).
Nos principales exigences étaient :
- prise en charge (à l'époque - des dizaines, et à l'avenir - des centaines) de clients au sein d'un seul système et en même temps la présence d'un système centralisé de gestion des alertes ;
- flexibilité dans la gestion du système d'alerte (remontée des alertes entre agents de permanence, planning, base de connaissances) ;
- la capacité de détailler profondément les graphiques (Zabbix à cette époque rendait les graphiques sous forme d'images) ;
- stockage à long terme d'une grande quantité de données (un an ou plus) et possibilité de les récupérer rapidement.
Dans cet article nous nous intéressons au dernier point.
En parlant de stockage, les exigences étaient les suivantes :
- le système doit fonctionner rapidement ;
- il est souhaitable que le système dispose d'une interface SQL ;
- le système doit être stable et disposer d'une base d'utilisateurs et d'un support actifs (une fois que nous avons été confrontés à la nécessité de prendre en charge des systèmes tels que MemcacheDB, qui n'était plus développé, ou le stockage distribué MooseFS, dont le tracker de bugs était conservé en chinois : nous ne voulions pas répéter cette histoire car notre projet);
- respect du théorème CAP : Cohérence (obligatoire) - les données doivent être à jour, nous ne voulons pas que le système de gestion des alertes ne reçoive pas de nouvelles données et crache des alertes sur la non-arrivée des données pour tous les projets ; Tolérance de partition (obligatoire) - nous ne voulons pas obtenir un système Split Brain ; Disponibilité (non critique, s'il existe une réplique active) - nous pouvons nous-mêmes passer au système de sauvegarde en cas d'accident, à l'aide de code.
Curieusement, à cette époque, MySQL s'est avéré être la solution idéale pour nous. Notre structure de données était extrêmement simple : identifiant du serveur, identifiant du compteur, horodatage et valeur ; un échantillonnage rapide des données chaudes a été assuré par un grand pool de tampons, et l'échantillonnage des données historiques a été assuré par SSD.
Ainsi, nous avons obtenu un échantillon de données fraîches sur deux semaines, avec des détails jusqu'à 200 ms avant que les données ne soient complètement restituées, et avons vécu dans ce système pendant assez longtemps.
Pendant ce temps, le temps passait et la quantité de données augmentait. En 2016, les volumes de données atteignaient des dizaines de téraoctets, ce qui représentait une dépense importante dans le contexte de la location de stockage SSD.
À cette époque, les bases de données en colonnes étaient devenues activement répandues, ce à quoi nous avons commencé à réfléchir activement : dans les bases de données en colonnes, les données sont stockées, comme vous pouvez le comprendre, dans des colonnes, et si vous regardez nos données, il est facile de voir un grand nombre de doublons qui pourraient, si vous utilisez une base de données en colonnes, la compresser à l'aide de la compression.
Cependant, le système de clé de l’entreprise a continué à fonctionner de manière stable et je ne voulais pas expérimenter le passage à autre chose.
En 2017, lors de la conférence Percona Live à San Jose, les développeurs de Clickhouse se sont probablement annoncés pour la première fois. À première vue, le système était prêt pour la production (enfin, Yandex.Metrica est un système de production exigeant), le support était rapide et simple et, plus important encore, le fonctionnement était simple. Depuis 2018, nous avons entamé le processus de transition. Mais à cette époque, il y avait beaucoup de systèmes TSDB « adultes » et éprouvés, et nous avons décidé de consacrer beaucoup de temps et de comparer les alternatives afin de nous assurer qu'il n'y avait pas de solutions alternatives à Clickhouse, selon nos exigences.
En plus des exigences de stockage déjà précisées, de nouvelles sont apparues :
- le nouveau système devrait fournir au moins les mêmes performances que MySQL sur la même quantité de matériel ;
- le stockage du nouveau système devrait prendre beaucoup moins de place ;
- Le SGBD doit rester simple à gérer ;
- Je voulais changer l'application au minimum lors du changement de SGBD.
Quels systèmes avons-nous commencé à envisager ?
Apache Hive/Apache Impala
Une ancienne pile Hadoop testée au combat. Il s’agit essentiellement d’une interface SQL construite sur le stockage de données dans des formats natifs sur HDFS.
Pros.
- Avec un fonctionnement stable, il est très facile de mettre à l’échelle les données.
- Il existe des solutions en colonnes pour le stockage des données (moins d'espace).
- Exécution très rapide de tâches parallèles lorsque les ressources sont disponibles.
Cons.
- C'est Hadoop, et c'est difficile à utiliser. Si nous ne sommes pas prêts à adopter une solution toute faite dans le cloud (et nous ne sommes pas prêts en termes de coût), la pile entière devra être assemblée et prise en charge par les administrateurs, et nous ne voulons vraiment pas ce.
- Les données sont agrégées .
Cependant:
La vitesse est obtenue en augmentant le nombre de serveurs informatiques. En termes simples, si nous sommes une grande entreprise engagée dans l'analyse et qu'il est essentiel pour l'entreprise de regrouper les informations le plus rapidement possible (même au prix de l'utilisation d'une grande quantité de ressources informatiques), cela peut être notre choix. Mais nous n’étions pas prêts à multiplier le parc matériel pour accélérer les tâches.
Druide/Pinot
Il y a beaucoup plus à propos de TSDB en particulier, mais encore une fois, la pile Hadoop.
Il est .
En quelques mots : Druid/Pinot est plus beau que Clickhouse dans les cas où :
- Vous avez une nature hétérogène des données (dans notre cas, nous enregistrons uniquement des séries temporelles de métriques de serveur, et, en fait, il s'agit d'une seule table. Mais il peut y avoir d'autres cas : séries chronologiques d'équipements, séries chronologiques économiques, etc. - chacune avec sa propre structure, qui doit être agrégée et traitée).
- De plus, il existe de nombreuses données de ce type.
- Des tableaux et des données avec des séries chronologiques apparaissent et disparaissent (c'est-à-dire qu'un ensemble de données est arrivé, a été analysé et supprimé).
- Il n'existe pas de critère clair selon lequel les données peuvent être partitionnées.
Dans les cas contraires, ClickHouse est plus performant, et c'est notre cas.
Cliquez Maison
- de type SQL
- Facile à gérer.
- Les gens disent que ça marche.
Est présélectionné pour les tests.
InfluxDB
Une alternative étrangère à ClickHouse. Parmi les inconvénients : La haute disponibilité n'est présente que dans la version commerciale, mais elle doit être comparée.
Est présélectionné pour les tests.
Cassandra
D'une part, nous savons qu'il est utilisé pour stocker des séries temporelles métriques par des systèmes de surveillance tels que, par exemple, ou OkMeter. Cependant, il y a des détails.
Cassandra n'est pas une base de données en colonnes au sens traditionnel du terme. Cela ressemble davantage à une vue en lignes, mais chaque ligne peut avoir un nombre différent de colonnes, ce qui facilite l'organisation d'une vue en colonnes. En ce sens, il est clair qu’avec une limite de 2 milliards de colonnes, il est possible de stocker certaines données en colonnes (et la même série temporelle). Par exemple, dans MySQL, il y a une limite de 4096 colonnes et il est facile de tomber sur une erreur avec le code 1117 si vous essayez de faire de même.
Le moteur Cassandra se concentre sur le stockage de grandes quantités de données dans un système distribué sans maître, et le théorème Cassandra CAP mentionné ci-dessus concerne davantage l'AP, c'est-à-dire la disponibilité des données et la résistance au partitionnement. Ainsi, cet outil peut être formidable si vous avez uniquement besoin d’écrire dans cette base de données et rarement de la lire. Et ici, il est logique d'utiliser Cassandra comme chambre froide. Il s’agit d’un endroit fiable à long terme pour stocker de grandes quantités de données historiques rarement nécessaires, mais pouvant être récupérées si nécessaire. Néanmoins, par souci d’exhaustivité, nous le testerons également. Mais, comme je l'ai dit plus tôt, il n'y a aucune volonté de réécrire activement le code de la solution de base de données sélectionnée, nous la testerons donc de manière quelque peu limitée - sans adapter la structure de la base de données aux spécificités de Cassandra.
Prométhée
Eh bien, par curiosité, nous avons décidé de tester les performances du stockage Prometheus - juste pour comprendre si nous sommes plus rapides ou plus lents que les solutions actuelles et de combien.
Méthodologie et résultats des tests
Nous avons donc testé 5 bases de données dans les 6 configurations suivantes : ClickHouse (1 nœud), ClickHouse (table distribuée pour 3 nœuds), InfluxDB, Mysql 8, Cassandra (3 nœuds) et Prometheus. Le plan de tests est le suivant :
- télécharger des données historiques pendant une semaine (840 millions de valeurs par jour ; 208 XNUMX métriques) ;
- nous générons une charge d'enregistrement (6 modes de chargement ont été considérés, voir ci-dessous) ;
- Parallèlement à l'enregistrement, nous effectuons périodiquement des sélections, émulant les demandes d'un utilisateur travaillant avec des graphiques. Afin de ne pas trop compliquer les choses, nous avons sélectionné des données pour 10 métriques (c'est exactement le nombre qu'il y a sur le graphique du CPU) pour une semaine.
Nous chargeons en émulant le comportement de notre agent de surveillance, qui envoie des valeurs à chaque métrique toutes les 15 secondes. En même temps, nous souhaitons varier :
- le nombre total de métriques dans lesquelles les données sont écrites ;
- intervalle d'envoi de valeurs à une métrique ;
- taille du lot.
À propos de la taille du lot. Puisqu'il n'est pas recommandé de charger presque toutes nos bases de données expérimentales avec des insertions uniques, nous aurons besoin d'un relais qui collecte les métriques entrantes, les regroupe en groupes et les écrit dans la base de données sous forme d'insertion par lots.
De plus, pour mieux comprendre comment interpréter ensuite les données reçues, imaginons que nous n'envoyons pas seulement un ensemble de métriques, mais que les métriques sont organisées en serveurs - 125 métriques par serveur. Ici, le serveur est simplement une entité virtuelle – il suffit de comprendre que, par exemple, 10000 80 métriques correspondent à environ XNUMX serveurs.
Et voici, en tenant compte de tout cela, nos 6 modes de chargement en écriture de base de données :
Il y a deux points ici. Premièrement, pour Cassandra, ces tailles de lots se sont avérées trop grandes, nous avons utilisé des valeurs de 50 ou 100. Et deuxièmement, puisque Prometheus fonctionne strictement en mode pull, c'est-à-dire il va lui-même collecter des données à partir de sources de métriques (et même pushgateway, malgré son nom, ne change pas fondamentalement la situation), les charges correspondantes ont été implémentées en utilisant une combinaison de configurations statiques.
Les résultats des tests sont les suivants :
Ce qui vaut la peine d'être noté: échantillons incroyablement rapides de Prometheus, échantillons terriblement lents de Cassandra, échantillons inacceptablement lents d'InfluxDB ; En termes de vitesse d'enregistrement, ClickHouse a gagné tout le monde, et Prometheus ne participe pas au concours, car il fait lui-même les inserts et nous ne mesurons rien.
En conséquence,: ClickHouse et InfluxDB se sont révélés être les meilleurs, mais un cluster d'Influx ne peut être construit que sur la base de la version Enterprise, qui coûte de l'argent, alors que ClickHouse ne coûte rien et est fabriqué en Russie. Il est logique qu'aux États-Unis, le choix soit probablement en faveur d'inInfluxDB, et dans notre pays, en faveur de ClickHouse.
Source: habr.com