{"id":55734,"date":"2020-01-27T00:00:00","date_gmt":"2020-01-26T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie"},"modified":"2020-02-18T14:03:52","modified_gmt":"2020-02-18T11:03:52","slug":"highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","title":{"rendered":"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Nous examinerons le fonctionnement de Zabbix avec la base de donn\u00e9es TimescaleDB en tant que backend. Nous montrerons comment d\u00e9marrer \u00e0 partir de z\u00e9ro et comment migrer depuis PostgreSQL. Nous fournirons \u00e9galement des tests comparatifs de performance entre les deux configurations.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/fb4f7ea4585b6dcdafec9d0d1e3a71e4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nHighLoad++ Sib\u00e9rie 2019. Salle \u00ab Tomsk \u00bb. 24 juin, 16h00. Th\u00e8ses et <noindex><a rel=\"nofollow\" href=\"https:\/\/www.highload.ru\/siberia\/2019\/abstracts\/5390\">pr\u00e9sentation<\/a><\/noindex>. La prochaine conf\u00e9rence HighLoad++ se tiendra les 6 et 7 avril 2020 \u00e0 Saint-P\u00e9tersbourg. D\u00e9tails et billets <noindex><a rel=\"nofollow\" href=\"http:\/\/bit.ly\/2sSxgBx\">via le lien<\/a><\/noindex>.<\/p>\n<p><b>Andrei Goutchin (ci-apr\u00e8s \u2013 AG) :<\/b> \u2013 Je suis ing\u00e9nieur support technique ZABBIX (ci-apr\u00e8s \u2013 \u00ab Zabbix \u00bb), formateur. Je travaille depuis plus de 6 ans dans le support technique et j'ai \u00e9t\u00e9 directement confront\u00e9 \u00e0 la performance. Aujourd'hui, je vais parler de la performance que peut offrir TimescaleDB par rapport \u00e0 un PostgreSQL ordinaire 10. Je ferai \u00e9galement une petite introduction sur le fonctionnement g\u00e9n\u00e9ral.<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Les principaux d\u00e9fis de performance : de la collecte \u00e0 la purification des donn\u00e9es<\/h3>\n<p>\nCommen\u00e7ons par le fait qu'il existe certains d\u00e9fis de performance auxquels chaque syst\u00e8me de monitoring est confront\u00e9. Le premier d\u00e9fi de performance est la collecte et le traitement rapide des donn\u00e9es.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/a2cb78b549a55c3b59d7fcdb8b8865b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUn bon syst\u00e8me de surveillance doit recevoir rapidement et en temps voulu toutes les donn\u00e9es, les traiter selon des expressions de d\u00e9clenchement, c'est-\u00e0-dire les traiter selon certains crit\u00e8res (cela varie d'un syst\u00e8me \u00e0 l'autre) et les conserver dans une base de donn\u00e9es, afin que ces donn\u00e9es puissent \u00eatre utilis\u00e9es ult\u00e9rieurement.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/a3ce55c3aec3eb93948150684838a5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe deuxi\u00e8me d\u00e9fi de performance est le stockage de l'historique. Il est souvent n\u00e9cessaire de conserver des donn\u00e9es dans une base de donn\u00e9es et d'avoir un acc\u00e8s rapide et pratique \u00e0 ces m\u00e9triques qui ont \u00e9t\u00e9 collect\u00e9es sur une certaine p\u00e9riode. L'essentiel est que ces donn\u00e9es soient facilement accessibles, pour pouvoir les utiliser dans des rapports, des graphiques, des d\u00e9clencheurs, des valeurs seuils, des alertes, etc.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/325363d79f0270d620f956eeb8ab3402.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe troisi\u00e8me d\u00e9fi de performance est la purification de l'historique, c'est-\u00e0-dire lorsque vous atteignez un jour o\u00f9 vous n'avez plus besoin de conserver certaines m\u00e9triques d\u00e9taill\u00e9es collect\u00e9es au cours des 5 derni\u00e8res ann\u00e9es (m\u00eame de quelques mois ou de deux mois). Certains n\u0153uds du r\u00e9seau ont \u00e9t\u00e9 supprim\u00e9s, ou certains h\u00f4tes, les m\u00e9triques ne sont plus n\u00e9cessaires car elles sont obsol\u00e8tes et ne sont plus collect\u00e9es. Tout cela doit \u00eatre nettoy\u00e9 pour que votre base de donn\u00e9es ne devienne pas trop volumineuse. De mani\u00e8re g\u00e9n\u00e9rale, la purification de l'historique constitue souvent un v\u00e9ritable d\u00e9fi pour le stockage, car cela affecte souvent la performance.<\/p>\n<h3>Comment r\u00e9soudre les probl\u00e8mes de mise en cache ?<\/h3>\n<p>\nJe vais maintenant parler sp\u00e9cifiquement de \u00ab Zabbix \u00bb. Dans \u00ab Zabbix \u00bb, le premier et le deuxi\u00e8me appels sont r\u00e9solus par le biais de la mise en cache.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/d5510b31553ee8e63a0c240789d51622.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCollecte et traitement des donn\u00e9es - nous utilisons la m\u00e9moire vive pour stocker toutes ces donn\u00e9es. Ces donn\u00e9es seront d\u00e9taill\u00e9es plus loin.<\/p>\n<p>Il existe \u00e9galement une certaine mise en cache du c\u00f4t\u00e9 de la base de donn\u00e9es pour les ensembles de donn\u00e9es principaux - pour les graphiques, d'autres \u00e9l\u00e9ments.<\/p>\n<p>Mise en cache du c\u00f4t\u00e9 du serveur Zabbix : nous avons ConfigurationCache, ValueCache, HistoryCache, TrendsCache. Qu'est-ce que cela signifie ?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/241a131145eccd280a7411c43b2cdce4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConfigurationCache est la m\u00e9moire cache principale o\u00f9 nous stockons les m\u00e9triques, les h\u00f4tes, les \u00e9l\u00e9ments de donn\u00e9es, les d\u00e9clencheurs ; tout ce qui est n\u00e9cessaire pour le pr\u00e9traitement, la collecte de donn\u00e9es, les h\u00f4tes \u00e0 partir desquels collecter, \u00e0 quelle fr\u00e9quence. Tout cela est stock\u00e9 dans ConfigurationCache, afin de ne pas avoir \u00e0 interroger la base de donn\u00e9es pour \u00e9viter des requ\u00eates superflues. Apr\u00e8s le d\u00e9marrage du serveur, nous mettons \u00e0 jour ce cache (le cr\u00e9ons) et le mettons \u00e0 jour r\u00e9guli\u00e8rement (selon les param\u00e8tres de configuration).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/474ac0db2e46aa945a0da62197f72987.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Mise en cache dans Zabbix. Collecte de donn\u00e9es<\/h3>\n<p>\nIci, le sch\u00e9ma est assez important :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/a6ad9dbd5deebac5440433a47c693fcf.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLes principaux \u00e9l\u00e9ments du sch\u00e9ma sont ces collecteurs :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/feb932586302e2284bd44595caf9ee1b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCe sont les processus de collecte eux-m\u00eames, divers \u00ab pollers \u00bb, qui sont responsables de diff\u00e9rents types de collectes. Ils collectent des donn\u00e9es via icmp, ipmi, diff\u00e9rents protocoles et transmettent tout cela au pr\u00e9traitement.<\/p>\n<h3>Pr\u00e9traitement HistoryCache<\/h3>\n<p>\nDe plus, s'il y a des \u00e9l\u00e9ments de donn\u00e9es calcul\u00e9s (ceux qui connaissent \u00ab Zabbix \u00bb le savent), c'est-\u00e0-dire des \u00e9l\u00e9ments de donn\u00e9es calcul\u00e9s, d'agr\u00e9gation - nous les extrayons directement de ValueCache. Je parlerai plus tard de la fa\u00e7on dont il est aliment\u00e9. Tous ces collecteurs utilisent ConfigurationCache pour recevoir leurs t\u00e2ches et transmettent ensuite pour le pr\u00e9traitement.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/3948ee1167c52856949c25e2043be974.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe pr\u00e9traitement utilise \u00e9galement ConfigurationCache pour obtenir les \u00e9tapes de pr\u00e9traitement, traitant ces donn\u00e9es de diverses mani\u00e8res. \u00c0 partir de la version 4.2, il a \u00e9t\u00e9 d\u00e9port\u00e9 vers le proxy. C'est tr\u00e8s pratique, car le pr\u00e9traitement est une op\u00e9ration assez lourde. Et si vous avez un tr\u00e8s grand \u00ab Zabbix \u00bb, avec un grand nombre d'\u00e9l\u00e9ments de donn\u00e9es et une fr\u00e9quence de collecte \u00e9lev\u00e9e, cela facilite \u00e9norm\u00e9ment le travail.<\/p>\n<p>Par cons\u00e9quent, apr\u00e8s avoir trait\u00e9 ces donn\u00e9es d'une mani\u00e8re ou d'une autre \u00e0 l'aide du pr\u00e9traitement, nous les enregistrons dans HistoryCache pour une utilisation ult\u00e9rieure. C'est l\u00e0 que se termine la collecte de donn\u00e9es. Nous passons au processus principal.<\/p>\n<h3>Fonctionnement du syncer d'historique<\/h3>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/66539e4184d041ed84f797080226ba24.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe principal processus dans \u00abZabbix\u00bb (car il s'agit d'une architecture monolithique) est le synchroniseur d'historique. C'est le processus principal qui s'occupe du traitement atomique de chaque \u00e9l\u00e9ment de donn\u00e9e, c'est-\u00e0-dire chaque valeur :<\/p>\n<ul>\n<li>une valeur arrive (il la prend du HistoryCache);<\/li>\n<li>il v\u00e9rifie dans le synchroniseur de configuration : y-a-t-il des d\u00e9clencheurs \u00e0 \u00e9valuer \u2013 il les calcule;<br \/>\ns'il y en a \u2013 il cr\u00e9e des \u00e9v\u00e9nements, g\u00e9n\u00e8re une escalade pour cr\u00e9er une alerte si n\u00e9cessaire selon la configuration;<\/li>\n<li>il enregistre les d\u00e9clencheurs pour un traitement et une agr\u00e9gation ult\u00e9rieurs; si vous agr\u00e9gerez sur la derni\u00e8re heure, par exemple, cette valeur est m\u00e9moris\u00e9e dans le ValueCache, afin de ne pas interroger la table d'historique; ainsi, le ValueCache est rempli des donn\u00e9es n\u00e9cessaires pour le calcul des d\u00e9clencheurs, des \u00e9l\u00e9ments calcul\u00e9s, etc.;<\/li>\n<li>ensuite, le synchroniseur d'historique enregistre toutes les donn\u00e9es dans la base de donn\u00e9es;<\/li>\n<li>la base de donn\u00e9es les enregistre sur le disque \u2013 \u00e0 ce moment, le processus de traitement se termine.<\/li>\n<\/ul>\n<p><\/p>\n<h3>Bases de donn\u00e9es. Mise en cache<\/h3>\n<p>\nDu c\u00f4t\u00e9 de la BDD, lorsque vous souhaitez consulter des graphiques ou des rapports sur les \u00e9v\u00e9nements, il existe divers caches. Mais dans le cadre de cette pr\u00e9sentation, je ne vais pas en parler.<\/p>\n<p>Pour MySQL, il y a Innodb_buffer_pool, ainsi qu'une multitude d'autres caches qui peuvent \u00e9galement \u00eatre configur\u00e9s.<br \/>\nMais voici les principaux :<\/p>\n<ul>\n<li>shared_buffers;<\/li>\n<li>effective_cache_size;<\/li>\n<li>shared_pool.<\/li>\n<\/ul>\n<p>\n<img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/925e7abb21cfaa2516ff2b33ab161dc0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPour toutes les bases de donn\u00e9es, j'ai mentionn\u00e9 qu'il existe certains caches qui permettent de garder en m\u00e9moire vive les donn\u00e9es souvent n\u00e9cessaires pour les requ\u00eates. Ils ont leurs propres technologies pour cela.<\/p>\n<h3>Sur la performance de la base de donn\u00e9es<\/h3>\n<p>\nPar cons\u00e9quent, il existe un environnement concurrentiel, c'est-\u00e0-dire que le serveur \u00abZabbix\u00bb collecte des donn\u00e9es et les enregistre. Lors d'un red\u00e9marrage, il lit \u00e9galement l'historique pour remplir le ValueCache et ainsi de suite. Vous pouvez aussi avoir des scripts et des rapports qui utilisent l'API \u00abZabbix\u00bb, qui est construite sur la base d'une interface web. L'API \u00abZabbix\u00bb acc\u00e8de \u00e0 la BDD et obtient les donn\u00e9es n\u00e9cessaires pour obtenir des graphiques, des rapports ou une liste d'\u00e9v\u00e9nements, des probl\u00e8mes r\u00e9cents.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/10a55cb1af660aace3172a572bea6692.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUne solution de visualisation tr\u00e8s populaire est Grafana, que nos utilisateurs utilisent. Elle sait acc\u00e9der directement \u00e0 la fois via l'API \u00abZabbix\u00bb et la BDD. Elle cr\u00e9e aussi une certaine concurrence pour l'obtention de donn\u00e9es : une configuration de BDD plus fine et meilleure est n\u00e9cessaire pour garantir une restitution rapide des r\u00e9sultats et des tests.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/8a008e55dbee5635d386cec2fc1c40f5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Nettoyage de l'historique. Dans Zabbix, il existe un Housekeeper<\/h3>\n<p>\nLe troisi\u00e8me appel utilis\u00e9 dans \u00ab Zabbix \u00bb est le nettoyage de l'historique via le Housekeeper. Le \u00ab Housekeeper \u00bb respecte tous les param\u00e8tres, c'est-\u00e0-dire que nous avons dans les \u00e9l\u00e9ments de donn\u00e9es indiqu\u00e9 combien de temps conserver (en jours), combien de temps conserver les tendances, la dynamique des changements.<\/p>\n<p>Je n'ai pas parl\u00e9 de TrendCache, que nous calculons \u00e0 la vol\u00e9e : les donn\u00e9es arrivent, nous les agr\u00e9geons sur une heure (principalement ce sont des chiffres de la derni\u00e8re heure), quantit\u00e9 moyenne \/ minimum et nous les enregistrons une fois par heure dans la table de dynamique des changements (\u00ab Trends \u00bb). Le \u00ab Housekeeper \u00bb est lanc\u00e9 et supprime les donn\u00e9es de la base de donn\u00e9es par des s\u00e9lections ordinaires, ce qui n'est pas toujours efficace.<\/p>\n<p>Comment comprendre que ce n'est pas efficace ? Vous pouvez voir sur les graphiques de performance des processus internes cette image :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/f413ec989491d4186a05c779978e2f6d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVotre History syncer est constamment occup\u00e9 (graphique rouge). Et le graphique \u00ab orange \u00bb, qui se trouve au-dessus. C'est le \u00ab Housekeeper \u00bb, qui est lanc\u00e9 et attend de la base de donn\u00e9es qu'elle supprime toutes les lignes qu'il a d\u00e9finies.<\/p>\n<p>Prenons un ID d'\u00e9l\u00e9ment quelconque : il faut supprimer les 5 000 derniers ; bien s\u00fbr, par index. Mais g\u00e9n\u00e9ralement, le dataset est suffisamment grand - la base de donn\u00e9es le lit toujours depuis le disque et le charge en cache, et c'est une op\u00e9ration tr\u00e8s co\u00fbteuse pour la base de donn\u00e9es. Selon sa taille, cela peut entra\u00eener certains probl\u00e8mes de performance.<\/p>\n<p>D\u00e9sactiver le \u00ab Housekeeper \u00bb peut se faire facilement - nous avons une interface web bien connue. Dans le param\u00e9trage de l'Administration g\u00e9n\u00e9rale (param\u00e8tres pour le \u00ab Housekeeper \u00bb), nous d\u00e9sactivons le nettoyage interne pour l'historique et les tendances. Par cons\u00e9quent, le \u00ab Housekeeper \u00bb ne g\u00e8re plus cela :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/c9dc3ca86e7fd0c1229f6b9bc5d31270.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nQue peut-on faire ensuite ? Vous avez d\u00e9sactiv\u00e9, vos graphiques se sont redress\u00e9s\u2026 Quels probl\u00e8mes peuvent encore survenir dans ce cas ? Qu'est-ce qui peut aider ?<\/p>\n<h3>Partitionnement (sectionnement)<\/h3>\n<p>\nCela se configure g\u00e9n\u00e9ralement sur chaque base de donn\u00e9es relationnelle que j'ai \u00e9num\u00e9r\u00e9e, de diff\u00e9rentes mani\u00e8res. Sur MySQL, il y a sa propre technologie. Mais dans l'ensemble, elles sont tr\u00e8s similaires lorsqu'on parle de PostgreSQL 10 et MySQL. Bien s\u00fbr, il y a beaucoup de diff\u00e9rences internes sur la fa\u00e7on dont tout cela est mis en \u0153uvre et comment cela impacte la performance. Mais dans l'ensemble, la cr\u00e9ation d'une nouvelle partition entra\u00eene souvent aussi certains probl\u00e8mes.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/729114d61794314e19383f09ee9b5d61.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSelon votre configuration (en fonction du volume de donn\u00e9es g\u00e9n\u00e9r\u00e9 par jour), la dur\u00e9e minimale g\u00e9n\u00e9ralement attribu\u00e9e est d'un jour\/partition, et pour les \u00ab tendances \u00bb, la dynamique des changements est d'un mois\/nouvelle partition. Cela peut varier si vous avez une tr\u00e8s grande configuration.<\/p>\n<p>Commen\u00e7ons par parler des tailles de configuration : jusqu'\u00e0 5 000 nouvelles valeurs par seconde (ce qu'on appelle NVPS) est consid\u00e9r\u00e9 comme une petite configuration. Une moyenne va de 5 000 \u00e0 25 000 valeurs par seconde. Tout ce qui d\u00e9passe cela correspond \u00e0 de grandes et tr\u00e8s grandes installations, n\u00e9cessitant un r\u00e9glage tr\u00e8s pr\u00e9cis de la base de donn\u00e9es.<\/p>\n<p>Sur de tr\u00e8s grandes installations, une dur\u00e9e d'un jour peut ne pas \u00eatre optimale. J'ai personnellement observ\u00e9 des partitions MySQL allant jusqu'\u00e0 40 Go par jour (et plus). C'est un volume de donn\u00e9es tr\u00e8s important qui peut poser certains probl\u00e8mes. Il faut le r\u00e9duire.<\/p>\n<h3>Pourquoi la partitionnement est-il n\u00e9cessaire ?<\/h3>\n<p>\nCe que le partitionnement apporte, je pense que tout le monde le sait \u2013 c'est la s\u00e9gr\u00e9gation des tables. Souvent, ce sont des fichiers distincts sur le disque et des requ\u00eates segment\u00e9es. Il s\u00e9lectionne plus efficacement une partition si cela s'inscrit dans le partitionnement habituel.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/4920fb3415733799f0a90b1bc7af0114.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPour \u00ab Zabbix \u00bb, en particulier, il s'utilise par plage, c'est-\u00e0-dire que nous utilisons un horodatage (un nombre ordinaire, le temps depuis le d\u00e9but de l'\u00e9poque). Vous d\u00e9finissez le d\u00e9but et la fin de la journ\u00e9e, ce qui constitue la partition. Ainsi, si vous acc\u00e9dez aux donn\u00e9es datant de deux jours, celles-ci sont r\u00e9cup\u00e9r\u00e9es de la base de donn\u00e9es plus rapidement, car il suffit de charger un seul fichier dans le cache et de le d\u00e9livrer (plut\u00f4t qu'une grande table).<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/f5ee4e0b471eb5ebe701615aa617d66d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDe nombreuses bases de donn\u00e9es acc\u00e9l\u00e8rent \u00e9galement l'insertion (ajout dans une table enfant). Je parle de mani\u00e8re abstraite, mais c'est aussi possible. Le partitionnement est souvent b\u00e9n\u00e9fique.<\/p>\n<h3>Elasticsearch pour NoSQL<\/h3>\n<p>\nR\u00e9cemment, dans la version 3.4, nous avons introduit une solution pour NoSQL. Nous avons ajout\u00e9 la possibilit\u00e9 d'\u00e9crire dans Elasticsearch. Vous pouvez \u00e9crire diff\u00e9rents types : choisir \u2013 soit des chiffres, soit des symboles ; nous avons du texte string, vous pouvez \u00e9crire des journaux dans Elasticsearch\u2026 Ainsi, l'interface web interagira \u00e9galement avec Elasticsearch. Cela fonctionne tr\u00e8s bien dans certains cas, mais pour le moment, c'est utilisable.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/24fe7d19c9e42474cd786ba59846c18c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB. Hyper-tables<\/h3>\n<p>\nPour la version 4.4.2, nous avons remarqu\u00e9 une chose concernant TimescaleDB. Qu'est-ce que c'est ? C'est une extension pour PostgreSQL, c'est-\u00e0-dire qu'elle a une interface native PostgreSQL. De plus, cette extension permet de travailler de mani\u00e8re beaucoup plus efficace avec les donn\u00e9es de s\u00e9ries temporelles et d'avoir un partitionnement automatique. Voici \u00e0 quoi cela ressemble :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/de921f06453476215b6240ab9da6fae1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nC'est un hypertable \u2013 c'est un concept dans Timescale. C'est une hypertable que vous cr\u00e9ez, et \u00e0 l'int\u00e9rieur se trouvent des chunks. Les chunks sont des partitions, des sous-tables, si je ne me trompe pas. C'est vraiment efficace.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/719eb3f5d8c9f57544dfc4010850610c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>TimescaleDB et PostgreSQL<\/h3>\n<p>\nSelon les producteurs de TimescaleDB, ils utilisent un algorithme de traitement de requ\u00eates plus optimal, en particulier pour les insertions, qui permet d'avoir une performance quasi constante avec une taille de jeu de donn\u00e9es croissante. Autrement dit, apr\u00e8s 200 millions de lignes, PostgreSQL commence \u00e0 ralentir consid\u00e9rablement et perd presque toute sa performance, tandis que Timescale permet d'ins\u00e9rer des donn\u00e9es aussi efficacement que possible, quel que soit le volume.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/a613d505a9dfe6008551ce981da7b24e.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Comment installer TimescaleDB ? C'est simple !<\/h3>\n<p>\nIl y a cela dans sa documentation, c'est \u00e9crit \u2013 vous pouvez l'installer \u00e0 partir des paquets pour divers syst\u00e8mes\u2026 Il d\u00e9pend des paquets officiels de PostgreSQL. Vous pouvez le compiler manuellement. Il se trouve que j'ai d\u00fb le compiler pour la base de donn\u00e9es.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/6767927fa92260103d318f9aa70ef5b3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPour Zabbix, nous activons simplement l'extension. Je pense que ceux qui ont d\u00e9j\u00e0 utilis\u00e9 une extension dans PostgreSQL\u2026 Vous activez simplement l'extension, vous la cr\u00e9ez pour la base de donn\u00e9es Zabbix que vous utilisez.<\/p>\n<p>Et la derni\u00e8re \u00e9tape\u2026<\/p>\n<h3>TimescaleDB. Migration des tables d'historique<\/h3>\n<p>\nVous devez cr\u00e9er un hypertable. Pour ce faire, il existe une fonction sp\u00e9ciale \u2013 Create hypertable. Dans celle-ci, vous indiquez en premier param\u00e8tre la table dont vous avez besoin dans cette base pour cr\u00e9er l'hypertable.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/47350f79fd9829c12685c1df8f0ff9a6.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe champ selon lequel vous souhaitez cr\u00e9er, et chunk_time_interval (c'est l'intervalle des chunks (partitions \u00e0 utiliser). 86 400 \u2013 c'est un jour. <\/p>\n<p>Param\u00e8tre migrate_data : si vous le mettez \u00e0 true, cela d\u00e9place toutes les donn\u00e9es actuelles vers les chunks cr\u00e9\u00e9s \u00e0 l'avance.<\/p>\n<p>J'ai moi-m\u00eame utilis\u00e9 migrate_data \u2013 cela prend un certain temps, en fonction de la taille de votre base de donn\u00e9es. J'avais plus d'un t\u00e9raoctet \u2013 la cr\u00e9ation a pris plus d'une heure. Dans certains cas, lors de tests, j'ai supprim\u00e9 des donn\u00e9es historiques pour le texte (history_text) et la cha\u00eene (history_str), pour ne pas les transf\u00e9rer \u2013 elles ne m'int\u00e9ressaient vraiment pas.<\/p>\n<p>Et la derni\u00e8re mise \u00e0 jour que nous faisons dans notre db_extension : nous installons timescaledb, afin que la base de donn\u00e9es et, en particulier, notre \u00ab Zabbix \u00bb, comprennent qu'il y a une db_extension. Il l'active et utilise correctement la syntaxe et les requ\u00eates \u00e0 la base de donn\u00e9es, en utilisant d\u00e9j\u00e0 les \u00ab fonctionnalit\u00e9s \u00bb n\u00e9cessaires pour TimescaleDB.<\/p>\n<h3>Configuration du serveur<\/h3>\n<p>\nJ'ai utilis\u00e9 deux serveurs. Le premier serveur est une machine virtuelle assez petite, avec 20 processeurs et 16 gigaoctets de m\u00e9moire vive. J'ai configur\u00e9 \u00ab PostgreSQL \u00bb 10.8 dessus :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/990805374a2380a5c645c578404489bd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe syst\u00e8me d'exploitation \u00e9tait Debian, et le syst\u00e8me de fichiers \u2013 xfs. J'ai effectu\u00e9 des r\u00e9glages minimaux pour utiliser sp\u00e9cifiquement cette base de donn\u00e9es, en tenant compte de ce que \u00ab Zabbix \u00bb utiliserait lui-m\u00eame. Sur cette m\u00eame machine se trouvaient le serveur \u00ab Zabbix \u00bb, PostgreSQL et des agents de charge.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/a6efa9ab9cd58f0061d04f13fe31018c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJ'ai utilis\u00e9 50 agents actifs, qui exploitent LoadableModule pour g\u00e9n\u00e9rer rapidement diff\u00e9rents r\u00e9sultats. Ils ont g\u00e9n\u00e9r\u00e9 des cha\u00eenes, des nombres, etc. J'ai aliment\u00e9 la base de donn\u00e9es avec un grand nombre de donn\u00e9es. \u00c0 l'origine, la configuration contenait 5 000 \u00e9l\u00e9ments de donn\u00e9es par h\u00f4te, et environ chaque \u00e9l\u00e9ment de donn\u00e9es avait un d\u00e9clencheur \u2013 afin que ce soit une v\u00e9ritable configuration. Parfois, l'utilisation n\u00e9cessite m\u00eame plus d'un d\u00e9clencheur.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/d5a3c306402e08bf2532eb6203a4aab4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJ'ai r\u00e9gul\u00e9 l'intervalle de mise \u00e0 jour et la charge, non seulement en utilisant 50 agents (j'en ai ajout\u00e9 d'autres), mais aussi gr\u00e2ce \u00e0 des \u00e9l\u00e9ments de donn\u00e9es dynamiques, r\u00e9duisant l'intervalle de mise \u00e0 jour \u00e0 4 secondes.<\/p>\n<h3>Test de performance. PostgreSQL : 36 000 NVPs<\/h3>\n<p>\nLa premi\u00e8re ex\u00e9cution, le premier setup que j'ai fait \u00e9tait sur du PostgreSQL 10 vierge sur ce mat\u00e9riel (35 000 valeurs par seconde). Dans l'ensemble, comme on peut le voir \u00e0 l'\u00e9cran, l'insertion de donn\u00e9es prend des fractions de seconde \u2013 tout est bon et rapide, disques SSD (200 gigaoctets). La seule chose est que 20 Go se remplissent assez rapidement.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/6803a64fedd26093b9117a036d2993ae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl y aura pas mal d'autres graphiques de ce type. C'est le tableau de bord standard de performance du serveur \u00ab Zabbix \u00bb.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/081cc11c6bf42db3f8f16b6cc4e6ee0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe premier graphique \u2013 le nombre de valeurs par seconde (en bleu, en haut \u00e0 gauche), 35 000 valeurs dans ce cas. Cela (en haut au centre) indique la charge des processus d'assemblage, et cela (en haut \u00e0 droite) \u2013 la charge des processus internes : history syncers et housekeeper, qui ici (en bas au centre) a fonctionn\u00e9 pendant une dur\u00e9e suffisante.<\/p>\n<p>Ce graphique (en bas au centre) montre l'utilisation de ValueCache \u2013 combien de hits ValueCache pour les d\u00e9clencheurs (plusieurs milliers de valeurs par seconde). Un autre graphique important est le quatri\u00e8me (en bas \u00e0 gauche), qui montre l'utilisation de HistoryCache, que j'ai mentionn\u00e9, qui sert de tampon avant d'ins\u00e9rer dans la base de donn\u00e9es.<\/p>\n<h3>Test de performance. PostgreSQL : 50 000 NVPs<\/h3>\n<p>\nEnsuite, j'ai augment\u00e9 la charge \u00e0 50 000 valeurs par seconde sur ce m\u00eame mat\u00e9riel. Lors du chargement par le 'Housekeeper', 10 000 valeurs \u00e9taient d\u00e9j\u00e0 enregistr\u00e9es en 2-3 secondes avec calcul. Ce qui est, en fait, montr\u00e9 sur la capture d'\u00e9cran suivante :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/80824da986dbee2f8d5ebe0ead4fbcfd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLe 'Housekeeper' commence d\u00e9j\u00e0 \u00e0 interf\u00e9rer avec le fonctionnement, mais globalement la charge des trappes des history-syncers est encore \u00e0 60 % (troisi\u00e8me graphique, en haut \u00e0 droite). HistoryCache commence d\u00e9j\u00e0 \u00e0 se remplir activement pendant le fonctionnement du 'Housekeeper' (en bas \u00e0 gauche). Il \u00e9tait d'environ un demi-gigaoctet, rempli \u00e0 20 %.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/9e1bcd4f3b9f3e8a1c9a36b2083ec61b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>Test de performance. PostgreSQL : 80 000 NVPs<\/h3>\n<p>\nEnsuite, j'ai augment\u00e9 \u00e0 80 000 valeurs par seconde :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/13ae1589d6b9d35b4dda9c6c7d989cc2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIl s'agissait d'environ 400 000 \u00e9l\u00e9ments de donn\u00e9es, 280 000 d\u00e9clencheurs. L'insertion, comme vous le voyez, \u00e9tait d\u00e9j\u00e0 assez \u00e9lev\u00e9e en charge sur les history-syncers (il y en avait 30). J'ai ensuite augment\u00e9 divers param\u00e8tres : history-syncers, cache... Sur ce mat\u00e9riel, la charge des history-syncers a commenc\u00e9 \u00e0 grimper \u00e0 son maximum, pratiquement 'en rayons' \u2013 par cons\u00e9quent, HistoryCache a atteint une charge tr\u00e8s \u00e9lev\u00e9e :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/0ec528256c8fa7b16e1c7c95c8119535.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTout ce temps, j'ai observ\u00e9 tous les param\u00e8tres syst\u00e8me (comment le processeur est utilis\u00e9, la m\u00e9moire vive) et j'ai d\u00e9couvert que l'utilisation des disques \u00e9tait maximale \u2013 j'avais atteint la capacit\u00e9 maximale de ce disque sur ce mat\u00e9riel, sur cette machine virtuelle. PostgreSQL a commenc\u00e9 \u00e0 vider les donn\u00e9es assez activement dans une telle intensit\u00e9, et le disque ne parvenait plus \u00e0 \u00e9crire, lire\u2026<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/0809dbd7638e7ee003ea24c611984a0c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJ'ai pris un autre serveur, qui avait d\u00e9j\u00e0 48 processeurs et 128 gigaoctets de m\u00e9moire vive :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/53410b502a4574aac5d40f1a2a6d3f42.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nJe l'ai \u00e9galement 'optimis\u00e9' \u2013 j'ai install\u00e9 60 History syncers et j'ai atteint des performances acceptables. En fait, nous ne sommes pas 'en rayons', mais c'est d\u00e9j\u00e0, probablement, la limite de performance o\u00f9 il est n\u00e9cessaire de faire quelque chose \u00e0 ce sujet.<\/p>\n<h3>Test de performance. TimescaleDB : 80 000 NVPs<\/h3>\n<p>\nJ'avais pour principal objectif d'utiliser TimescaleDB. Sur chaque graphique, une chute est visible :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/b0064068895a34b93b5aa6771aba05cb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCes \u00e9checs concernent la migration des donn\u00e9es. Apr\u00e8s cela, sur le serveur \u00ab Zabbix \u00bb, le profil de chargement des synchroniseurs d'historique, comme vous pouvez le voir, a beaucoup chang\u00e9. Il permet d'ins\u00e9rer des donn\u00e9es presque trois fois plus rapidement et utilise moins de HistoryCache \u2013 ainsi, vous recevrez les donn\u00e9es en temps utile. Encore une fois, 80 000 valeurs par seconde, c'est un taux assez \u00e9lev\u00e9 (bien s\u00fbr, pas pour \u00ab Yandex \u00bb). Dans l'ensemble, c'est une configuration assez importante, avec un seul serveur.<\/p>\n<h3>Test de performance de PostgreSQL : 120 000 NVPs<\/h3>\n<p>\nEnsuite, j'ai augment\u00e9 la valeur du nombre d'\u00e9l\u00e9ments de donn\u00e9es \u00e0 un demi-million et j'ai obtenu une valeur estim\u00e9e de 125 000 par seconde :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/7d0cf2ef7c6691c1bbf4b90afd34e4bb.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEt j'ai obtenu ces graphiques :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/9c09333a50e016921a8a5b70e00397a1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEn principe, c'est une configuration fonctionnelle, elle peut fonctionner pendant une p\u00e9riode relativement longue. Mais comme j'avais un disque de seulement 1,5 To, je l'ai \u00e9puis\u00e9 en quelques jours. Ce qui est le plus important, c'est que pendant ce temps, de nouvelles partitions \u00e9taient cr\u00e9\u00e9es sur TimescaleDB, et cela se faisait de mani\u00e8re totalement invisible pour la performance, ce qui ne peut pas \u00eatre dit pour MySQL.<\/p>\n<p>G\u00e9n\u00e9ralement, les partitions sont cr\u00e9\u00e9es la nuit, car cela bloque compl\u00e8tement l'insertion et le travail avec les tables, ce qui peut entra\u00eener une d\u00e9gradation du service. Dans ce cas, ce n'est pas le cas ! L'objectif principal \u00e9tait de v\u00e9rifier les capacit\u00e9s de TimescaleDB. On a obtenu ce chiffre : 120 000 valeurs par seconde.<\/p>\n<p>Il y a aussi des exemples dans la \u00ab communaut\u00e9 \u00bb :<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/66aa6b1d4c559d12082e4d91b6a1ca10.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUne personne a \u00e9galement activ\u00e9 TimescaleDB et la charge d'utilisation de io.weight a diminu\u00e9 sur le processeur ; l'utilisation des \u00e9l\u00e9ments des processus internes a \u00e9galement diminu\u00e9 gr\u00e2ce \u00e0 l'activation de TimescaleDB. D'ailleurs, il s'agit de disques durs ordinaires, c'est-\u00e0-dire d'une machine virtuelle sur des disques classiques (pas SSD) !<\/p>\n<p>Pour des configurations plus petites, limit\u00e9es par la performance du disque, TimescaleDB me semble \u00eatre une tr\u00e8s bonne solution. Elle permettra de continuer \u00e0 fonctionner jusqu'\u00e0 ce que vous migriez vers un mat\u00e9riel de base de donn\u00e9es plus rapide.<\/p>\n<p>Je vous invite tous \u00e0 nos \u00e9v\u00e9nements : Conf\u00e9rence \u2013 \u00e0 Moscou, Sommet \u2013 \u00e0 Riga. Utilisez nos canaux \u2013 \u00ab Telegram \u00bb, forum, IRC. Si vous avez des questions \u2013 venez nous voir au stand, nous pouvons tout discuter.<\/p>\n<h3>Questions du public<\/h3>\n<p>\nQuestion from the audience (hereinafter \u2013 A): \u2013 If TimescaleDB is so easy to set up, and it offers such a performance boost, could it be considered best practice to use it with PostgreSQL for configuring Zabbix? Are there any pitfalls or downsides to this solution, or can I just seamlessly use PostgreSQL with Timescale from the start for Zabbix and not worry about any issues?<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/314845a019724806283a957b15d857cc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>AG :<\/b> \u2013 Yes, I would say it\u2019s a good recommendation: to use PostgreSQL right away with the TimescaleDB extension. As I mentioned, there are many positive reviews, despite this feature being experimental. But tests actually show that this is an excellent solution (with TimescaleDB), and I believe it will continue to evolve! We are monitoring how this extension develops and will adjust as needed.<\/p>\n<p>Even during development, we relied on one of their well-known features: it allowed for somewhat different chunk management. But then they removed it in the next release, and we had to stop relying on that code. I would recommend using this solution in many setups. If you are using MySQL\u2026 Any solution works well for medium setups.<\/p>\n<p><b>A:<\/b> \u2013 In the latest charts, which are from the community, there was a chart with \u2018Housekeeper\u2019:<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/d01549b6b9b97d8bdf5372efe05d9039.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIt continued to work. What does 'Housekeeper' do in the case of TimescaleDB?<\/p>\n<p><b>AG :<\/b> \u2013 I can\u2019t say for sure right now \u2013 I\u2019ll check the code and provide more details. It specifically uses TimescaleDB queries not for dropping chunks, but rather aggregates somehow. For now, I\u2019m not ready to answer this technical question. We will clarify it on the stand today or tomorrow.<\/p>\n<p><b>A:<\/b> \u2013 I have a similar question \u2013 about the performance of delete operations in Timescale.<br \/>\nA (response from the audience): \u2013 When you delete data from a table, if you do this using delete, you need to go through the table \u2013 delete, clean up, mark everything for future vacuuming. In Timescale, since you have chunks, you can just drop them. Roughly speaking, you\u2019re just telling the file in big data: 'Delete!'<\/p>\n<p>\u00abTimeScale\u00bb comprend simplement qu'il n'y a plus de ce chunk. \u00c9tant donn\u00e9 qu'il s'int\u00e8gre dans le planificateur de requ\u00eates, il attrape vos conditions dans le select ou dans d'autres op\u00e9rations et comprend imm\u00e9diatement que ce chunk n'existe plus \u2013 \u00abJe n'irai plus l\u00e0-bas !\u00bb (donn\u00e9es manquantes). Voil\u00e0 tout ! C'est-\u00e0-dire que le scan de la table est remplac\u00e9 par la suppression du fichier binaire, donc c'est rapide.<\/p>\n<p><b>A:<\/b> \u2013 Nous avons d\u00e9j\u00e0 abord\u00e9 le sujet de non-SQL. Si je comprends bien, \u00abZabbix\u00bb n'a pas vraiment besoin de modifier les donn\u00e9es, tout cela ressemble \u00e0 un journal. Peut-on utiliser des bases de donn\u00e9es sp\u00e9cialis\u00e9es qui ne peuvent pas changer leurs donn\u00e9es, mais qui sont beaucoup plus rapides pour enregistrer, accumuler, restituer \u2013 Clickhouse, par exemple, quelque chose d'analogique \u00e0 Kafka ?.. Kafka est aussi un journal ! Peut-on les int\u00e9grer d'une mani\u00e8re ou d'une autre ?<\/p>\n<p><b>AG :<\/b> \u2013 On peut faire une exportation. Nous avons une certaine \u00abfonctionnalit\u00e9\u00bb depuis la version 3.4 : vous pouvez \u00e9crire dans des fichiers tous les fichiers historiques, les \u00e9v\u00e9nements, tout le reste ; puis envoyer \u00e0 toute autre base de donn\u00e9es avec un certain traitement. En fait, beaucoup de gens font cela et \u00e9crivent directement dans la base de donn\u00e9es. Des history-syncers le font \u00e0 la vol\u00e9e, \u00e9crivant dans des fichiers, faisant tourner ces fichiers, et ensuite vous pouvez les transf\u00e9rer dans \u00abClickhouse\u00bb. Je ne peux pas parler des projets futurs, mais il est possible que le support des solutions NoSQL (comme \u00abClickhouse\u00bb) se poursuive.<\/p>\n<p><b>A:<\/b> \u2013 Donc, en fait, on peut compl\u00e8tement se passer de Postgres ?<\/p>\n<p><b>AG :<\/b> \u2013 Bien s\u00fbr, la partie la plus complexe dans \u00abZabbix\u00bb est les tables historiques, qui posent le plus de probl\u00e8mes, ainsi que les \u00e9v\u00e9nements. Dans ce cas, si vous ne conservez pas les \u00e9v\u00e9nements trop longtemps et que vous stockez l'historique avec des tendances dans un autre stockage rapide, il ne devrait pas y avoir de probl\u00e8me, je pense.<\/p>\n<p><b>A:<\/b> \u2013 Pouvez-vous \u00e9valuer \u00e0 quel point tout fonctionnera plus vite si on passe \u00e0 \u00abClickhouse\u00bb, disons ?<\/p>\n<p><b>AG :<\/b> \u2013 Je n'ai pas test\u00e9. Je pense qu'on peut atteindre au moins les m\u00eames chiffres assez facilement, sachant que \u00abClickhouse\u00bb a son interface, mais je ne peux pas dire avec certitude. Mieux vaut tester. Tout d\u00e9pend de la configuration : combien vous avez d'h\u00f4tes, etc. L'insertion est une chose, mais il faut aussi r\u00e9cup\u00e9rer ces donn\u00e9es \u2013 avec Grafana ou quelque chose d'autre.<\/p>\n<p><b>A:<\/b> \u2013 Donc, il s'agit d'une lutte \u00e9quitable, et non d'un grand avantage de ces bases de donn\u00e9es rapides ?<\/p>\n<p><b>AG :<\/b> \u2013 Je pense que lors de l'int\u00e9gration, nous aurons des tests plus pr\u00e9cis.<\/p>\n<p><b>A:<\/b> \u2013 O\u00f9 est donc pass\u00e9 le bon vieux RRD ? Qu'est-ce qui a pouss\u00e9 \u00e0 passer aux bases de donn\u00e9es SQL ? Au d\u00e9part, toutes les m\u00e9triques \u00e9taient collect\u00e9es sur RRD.<\/p>\n<p><b>AG :<\/b> \u2013 Dans \u00ab Zabbix \u00bb, RRD n'existait peut-\u00eatre que dans une tr\u00e8s ancienne version. Il y a toujours eu des bases de donn\u00e9es SQL \u2013 c'est l'approche classique. L'approche classique, c'est MySQL, PostgreSQL (qui existent depuis tr\u00e8s longtemps). Nous n'avons pratiquement jamais utilis\u00e9 d'interface commune pour les bases de donn\u00e9es SQL et RRD.<\/p>\n<p><img decoding=\"async\" alt=\"HighLoad++, Andre\u00ef Gouchin (Zabbix) : haute performance et partitionnement natif\" src=\"\/wp-content\/uploads\/2020\/01\/ac5f02494c63983601cc09c0b22e722b.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<center><div class=\"youtube-placeholder\" data-id=\"umRk94j5M8o\" onclick=\"loadVideo(this)\">\r\n        <img decoding=\"async\" src=\"https:\/\/img.youtube.com\/vi\/umRk94j5M8o\/hqdefault.jpg\" alt=\"Lire la vid\u00e9o\" loading=\"lazy\" width=\"480\" height=\"360\" style=\"width:100%;height:auto;\">\r\n        <div class=\"play-button\"><\/div>\r\n    <\/div><\/center><\/p>\n<h3>Un peu de publicit\u00e9 \ud83d\ude42<\/h3>\n<p>\nMerci de rester avec nous. Aimez-vous nos articles ? Voulez-vous voir plus de contenu int\u00e9ressant ? Soutenez-nous en passants une commande ou en nous recommandant \u00e0 des amis, <noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/cloudvps\/nl\">VPS cloud pour d\u00e9veloppeurs \u00e0 partir de 4,99 $<\/a><\/noindex>, <b>un \u00e9quivalent unique des serveurs d'entr\u00e9e de gamme, con\u00e7u pour vous :<\/b> <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/347386\/\">Toute la v\u00e9rit\u00e9 sur le VPS (KVM) E5-2697 v3 (6 c\u0153urs) 10 Go DDR4 480 Go SSD 1 Gbps \u00e0 partir de 19 $ ou comment bien diviser un serveur ?<\/a><\/noindex> (options disponibles avec RAID1 et RAID10, jusqu'\u00e0 24 c\u0153urs et jusqu'\u00e0 40 Go DDR4).<\/p>\n<p><b>Dell R730xd deux fois moins cher dans le data center Equinix Tier IV \u00e0 Amsterdam ?<\/b> Uniquement chez nous <b><noindex><a rel=\"nofollow\" href=\"https:\/\/ua-hosting.company\/serversnl\">2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64Go DDR4 4x960Go SSD 1Gbps 100 To \u00e0 partir de 199 $<\/a><\/noindex> aux Pays-Bas ! <b>Dell R420 \u2014 2x E5-2430 2.2GHz 6C 128Go DDR3 2x960Go SSD 1Gbps 100To \u2014 \u00e0 partir de 99 $ !<\/b><\/b> Lisez sur <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/company\/ua-hosting\/blog\/329618\/\">Comment construire une infrastructure de classe entreprise avec des serveurs Dell R730xd E5-2650 v4 co\u00fbtant 9000 euros pour des clopinettes ?<\/a><\/noindex><br \/>\n<br \/>Source : <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/ua-hosting\/blog\/485470\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL. \u0422\u0430\u043a\u0436\u0435 \u043f\u0440\u0438\u0432\u0435\u0434\u0435\u043c \u0441\u0440\u0430\u0432\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u044b\u0435 \u0442\u0435\u0441\u0442\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0434\u0432\u0443\u0445 \u043a\u043e\u043d\u0444\u0438\u0433\u0443\u0440\u0430\u0446\u0438\u0439. HighLoad++ Siberia 2019. \u0417\u0430\u043b \u00ab\u0422\u043e\u043c\u0441\u043a\u00bb. 24 \u0438\u044e\u043d\u044f, 16:00. \u0422\u0435\u0437\u0438\u0441\u044b \u0438 \u043f\u0440\u0435\u0437\u0435\u043d\u0442\u0430\u0446\u0438\u044f. \u0421\u043b\u0435\u0434\u0443\u044e\u0449\u0430\u044f \u043a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f HighLoad++ \u043f\u0440\u043e\u0439\u0434\u0435\u0442 6 \u0438 7 \u0430\u043f\u0440\u0435\u043b\u044f 2020 \u0433\u043e\u0434\u0430 \u0432 \u0421\u0430\u043d\u043a\u0442-\u041f\u0435\u0442\u0435\u0440\u0431\u0443\u0440\u0433\u0435. \u041f\u043e\u0434\u0440\u043e\u0431\u043d\u043e\u0441\u0442\u0438 \u0438 \u0431\u0438\u043b\u0435\u0442\u044b \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-55734","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"fr_FR\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-01-26T21:00:00+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-02-18T11:03:52+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47HighLoad++, Andrei Gouchine (Zabbix) : haute performance et partitionnement natif | ProHoster","description":"Nous examinerons le fonctionnement de Zabbix avec la base de donn\u00e9es TimescaleDB comme backend. Nous montrerons comment d\u00e9marrer \u00e0 partir de z\u00e9ro et comment migrer depuis PostgreSQL.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47HighLoad++, \u0410\u043d\u0434\u0440\u0435\u0439 \u0413\u0443\u0449\u0438\u043d (Zabbix): \u0432\u044b\u0441\u043e\u043a\u0430\u044f \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u0438 \u043d\u0430\u0442\u0438\u0432\u043d\u043e\u0435 \u043f\u0430\u0440\u0442\u0438\u0446\u0438\u043e\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435 | ProHoster","og:description":"\u041c\u044b \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0438\u043c \u0440\u0430\u0431\u043e\u0442\u0443 Zabbix \u0441 \u0431\u0430\u0437\u043e\u0439 \u0434\u0430\u043d\u043d\u044b\u0445 TimescaleDB \u0432 \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435 backend. \u041f\u043e\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c \u0441 \u043d\u0443\u043b\u044f \u0438 \u043a\u0430\u043a \u043c\u0438\u0433\u0440\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0441 PostgreSQL.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/highload-andrej-gushhin-zabbix-vysokaya-proizvoditelnost-i-nativnoe-partitsionirovanie","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-01-26T21:00:00+00:00","article:modified_time":"2020-02-18T11:03:52+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"55734","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 19:37:39","updated":"2022-09-28 01:51:35","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/55734","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=55734"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/55734\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=55734"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=55734"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=55734"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}