{"id":7466,"date":"2019-05-17T12:33:32","date_gmt":"2019-05-17T11:33:32","guid":{"rendered":"http:\/\/blog.capdata.fr\/?p=7466"},"modified":"2022-11-21T16:22:52","modified_gmt":"2022-11-21T15:22:52","slug":"mysql-dans-le-paas-le-radar-de-notation-des-solutions","status":"publish","type":"post","link":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/","title":{"rendered":"MySQL dans le PaaS : le radar de notation des solutions"},"content":{"rendered":"\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>

Pour ajouter un peu de visibilit\u00e9 \u00e0 ce comparatif MySQL dans le PaaS, j’ai d\u00e9cid\u00e9 de faire un r\u00e9cap par th\u00e9matique et des podiums par solution, avec un argumentaire pour chaque cas. Cet article sera remis \u00e0 jour avec les infos sur Aurora pour compl\u00e9ter le tableau une fois l’\u00e9tude publi\u00e9e. <\/p>\n\n\n
Disclaimer <\/strong>: avant de d\u00e9buter, j’indiquerais que le choix des th\u00e8mes et le syst\u00e8me de notation n’engage que moi. Je me base sur mon exp\u00e9rience de production sur MySQL, que j’utilise au quotidien depuis plus de 10 ans, de la 4.1 \u00e0 la 5.7 qui est aujourd’hui notre socle data en production sur AllDB. Si vous avez des commentaires ou si vous n’\u00eates pas d’accord avec la m\u00e9thode, vous pouvez vous manifester dans les commentaires en bas de cette page, le dialogue est toujours ouvert \ud83d\ude42 <\/p>\n

Egalement pour dire que le monde du cloud est un monde en perp\u00e9tuel mouvement. Ce qui est annonc\u00e9 ici peut changer la semaine qui suit. Ce classement dresse un \u00e9tat qui n’est valable que jusqu’\u00e0 la date de publication de cet article, c’est \u00e0 dire dans le courant de mai 2019…<\/em><\/td>\n<\/tr>\n<\/table>\n

Avant de se lancer, on rappellera les articles de r\u00e9f\u00e9rence pour retrouver tous les d\u00e9tails des tests effectu\u00e9s par plateforme cloud:
\n– \u00e9pisode 1 : MySQL sur Google Cloud platform<\/a>.
\n– \u00e9pisode 2 : MySQL et MariaDB sur Microsoft Azure<\/a>.
\n– \u00e9pisode 3 1\/2 : MySQL et MariaDB dans Amazon RDS 1\/2<\/a>
\n– \u00e9pisode 3 2\/2 : MySQL et MariaDB dans Amazon RDS 2\/2<\/a><\/p>\n

Les th\u00e9matiques<\/h2>\n

Chaque solution est jug\u00e9e sur la base d’une th\u00e9matique. Le but est de dresser un tableau suffisamment exhaustif pour pouvoir estimer justement o\u00f9 se situent ces offres les unes par rapport aux autres… La liste des th\u00e9matiques est la suivante:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Couverture technique<\/strong><\/td>\n Liste des versions et fonctions support\u00e9es. Ce th\u00e8me permet de mesurer la distance en fonctionnalit\u00e9s entre une instance on-premise et une instance dans le PaaS.<\/td>\n<\/tr>\n
Tiers et stockage<\/strong><\/td>\n Vari\u00e9t\u00e9 dans les diff\u00e9rents choix de tier et de stockage utilisables. <\/td>\n<\/tr>\n
Manageabilit\u00e9<\/strong><\/td>\n Souplesse de l’administration (acc\u00e8s aux logs, configuration, connectivit\u00e9, arr\u00eat, d\u00e9marrage, etc…) <\/td>\n<\/tr>\n
Options de facturation<\/strong><\/td>\n Vari\u00e9t\u00e9 des choix possibles de facturation. <\/td>\n<\/tr>\n
Diagnostics et outillage<\/strong><\/td>\n Richesse des interfaces de diagnostic et de l’outillage disponible pour l’analyser des incidents et des probl\u00e8mes de performance. <\/td>\n<\/tr>\n
Industrialisation<\/strong><\/td>\n Mesure des capacit\u00e9s d’automatisation et de la richesse de la grammaire CLI. <\/td>\n<\/tr>\n
Disponibilit\u00e9<\/strong><\/td>\n Solutions de haute disponibilit\u00e9 propos\u00e9es. <\/td>\n<\/tr>\n
Scalabilit\u00e9<\/strong><\/td>\n Solutions de mont\u00e9e en charge sur les tiers, le stockage, les solutions de r\u00e9plication et le scale-out en lecture seule. <\/td>\n<\/tr>\n
Sauvegarde et restauration<\/strong><\/td>\n Solutions de sauvegarde et flexibilit\u00e9 sur la restauration. <\/td>\n<\/tr>\n
Gestion des mises \u00e0 jour<\/strong><\/td>\n Encadrement de la maintenance cloud et la mise \u00e0 jour des versions de la base. <\/td>\n<\/tr>\n
S\u00e9curit\u00e9<\/strong><\/td>\n Moyens de mise en s\u00e9curit\u00e9 du point de vue des donn\u00e9es, acc\u00e8s, connexions, sauvegardes, etc…<\/td>\n<\/tr>\n
Prix<\/strong><\/td>\n Evaluation du co\u00fbt de la solution. <\/td>\n<\/tr>\n<\/table>\n

A noter que je n’ai pas mis de th\u00e8me ‘Performance’, ce sera certainement l’objet d’un futur post, mais pour noter objectivement la performance il faudrait pouvoir faire un bench, donc, pour l’instant la performance n’entrera pas dans les crit\u00e8res sans preuve \u00e0 l’appui…<\/p>\n

Les crit\u00e8res de notation:<\/h2>\n

Chaque th\u00e9matique pour chaque solution sera jug\u00e9e sur une \u00e9chelle de 1 \u00e0 5 o\u00f9:
\n– 1<\/strong>: Inexistant<\/em>. Le th\u00e8me n’est tout bonnement pas couvert.
\n– 2<\/strong>: Faible<\/em>. La couverture est minimaliste.
\n– 3<\/strong>: Moyen<\/em>. Couvre les besoins de base uniquement.
\n– 4<\/strong>: Optimal<\/em>. Couvre tous les besoins connus.
\n– 5<\/strong>: D\u00e9passe les attentes<\/em>. Pr\u00e9sente une plus-value par rapport \u00e0 l’\u00e9quivalent on-premise. <\/p>\n

Le radar:<\/h2>\n

Le radar donne la meilleure repr\u00e9sentation du bilan par th\u00e9matique et par solution.
\n\"\"
\nL’avance sur presque tous les domaines prise par Amazon se paye … comptant ! Le prix est ainsi le seul crit\u00e8re pour lequel RDS termine bon dernier. Le d\u00e9tail du pourquoi dans les articles pr\u00e9-cit\u00e9s, pour la synth\u00e8se th\u00e9matique par th\u00e9matique, c’est par ici… <\/p>\n

\n

Couverture technique<\/h2>\n

\"\"
\nRDS : 5\/5. <\/strong>J’ai mis la note maximale \u00e0 RDS parce qu’il supporte les derni\u00e8res versions stables de MySQL (8.0.15) et MariaDB (10.3.13), mais aussi la version 5.5 de MySQL pour compatibilit\u00e9. Aucun autre clouder ne supporte la version 8.0 pour l’instant et aucun autre n’est aussi large dans son choix de version. Quand on migre dans le cloud, c’est important aussi de ne pas avoir \u00e0 faire une migration de version en plus… Quant aux seules fonctionnalit\u00e9s non support\u00e9es on retrouve seulement la r\u00e9plication semi-synchrone, les tablespaces encryptables ou transpotables et le SET PERSIST dans la version 8.0. J’ai mis 5 aussi car le support de memcached et du plugin d’audit MariaDB dans les option groups est un plus qui n’\u00e9tait pas attendu. <\/p>\n

Azure : 3\/5<\/strong>. Azure est en seconde position parce qu’il propose MySQL et MariaDB, mais seulement dans les versions 5.6, 5.7 et MariaDB 10.2. Il ne permet toujours pas de cr\u00e9er des fonctions et triggers pour MySQL en raison d’un param\u00e8tre non configurable (log_bin_trust_function_creators). <\/p>\n

GCP : 2\/5<\/strong>. GCP est dernier car il ne propose que MySQL, dans les versions 5.6 et 5.7 pour l’instant, et pas MariaDB. Il ne permet pas d’utiliser Performance_Schema avec tous les tiers et n’autorise pas non plus de faire un CREATE TABLE AS SELECT ou CREATE TEMPORARY TABLE parce que GTID est impos\u00e9 par d\u00e9faut. <\/p>\n

\n

Tiers et stockage<\/h2>\n

\"\"
\nGlobalement les 3 solutions sont \u00e9quilibr\u00e9es en termes de tiers disponibles, c’est sur le stockage que la diff\u00e9rence se fait. <\/p>\n

RDS : 4\/5<\/strong>. Sur le stockage, RDS est la seule solution qui propose en plus du provisionnement en Gb un provisionnement en IOPS, (presque) quelle que soit la capacit\u00e9 demand\u00e9e. Evidemment au prix fort mais la fonctionnalit\u00e9 est l\u00e0. <\/p>\n

Azure : 2\/5<\/strong>. C’est le plafond \u00e0 6000 IOPS qui p\u00e9nalise Azure. Comme sur le GP2 d’Amazon, les IOPS sont li\u00e9s \u00e0 la capacit\u00e9 \u00e0 hauteur de 3IOPS\/Gb mais il n’y a, contrairement \u00e0 RDS avec les cr\u00e9dits d’IOPS, aucun levier dans le cas d’Azure, m\u00eame en stockage Premium. <\/p>\n

GCP : 3\/5<\/strong>. J’aurais bien mis 3.5 car les caract\u00e9ristiques du stockage propos\u00e9 par Google sont quand m\u00eame bien plus int\u00e9ressantes que celles d’Azure, avec la capacit\u00e9 \u00e0 monter beaucoup plus rapidement en IOPS qu’avec les 3IOPS\/Gb d’Azure. Elles sont m\u00eame plus int\u00e9ressantes que le GP2 de RDS, mais il n’y a pas d’\u00e9quivalent chez Google de provisionnement en IOPS \u00e0 ce jour, c’est pourquoi il ne peut pas \u00eatre au m\u00eame niveau. <\/p>\n

\n

Manageabilit\u00e9<\/h2>\n

\"\"
\nRDS: 5\/5<\/strong>. Encore une fois RDS nous surprend en allant plus loin encore que ce que propose le moteur on-premise en termes de manageabilit\u00e9. <\/p>\n

D\u00e9j\u00e0 la quasi-totalit\u00e9 des commandes qui n\u00e9cessitent le privil\u00e8ge SUPER sont impl\u00e9ment\u00e9es via des proc\u00e9dures stock\u00e9es d\u00e9di\u00e9es. On acc\u00e8de m\u00eame \u00e0 des informations qui sont plus du ressort de l’operating system que de la couche applicative de la base, comme la possibilit\u00e9 de d\u00e9coder le contenu des binlogs par exemple, ou comme on le voit dans la partie diagnostics, acc\u00e9der aux processus sous-jacents et aux compteurs de l’h\u00f4te (uptime, CPU, m\u00e9moire, swap, etc…). <\/p>\n

L’impl\u00e9mentation du collecteur pour la partie variables de statut est un vrai plus par rapport \u00e0 l’existant. Tous les param\u00e8tres sont modifiables, soit avec des valeurs statiques ou dynamiques (par exemple via la formule DBInstanceClassMemory*3\/4<\/em> pour innodb_buffer_pool_size) soit des fonctions… Ce qui n’est pas le cas chez les autres clouders. <\/p>\n

L’apport des parameter groups et security groups d\u00e9tach\u00e9s des services PaaS est aussi primordial dans cette cat\u00e9gorie, car il simplifie les d\u00e9ploiements et les restaurations, les PG et SG sont m\u00eame copiables pour en faire des ‘backups’. Il n’y a gu\u00e8re que le red\u00e9marrage au bout de 7 jours d’arr\u00eat qui d\u00e9\u00e7oive un peu mais cela reste g\u00e9rable et devant le nombre de fonctionnalit\u00e9s en plus par rapports aux concurrents, on ne fera pas la fine bouche.<\/p>\n

Azure:3\/5<\/strong>. Il y a plus de param\u00e8tres de configuration sur Azure que sur GCP, il y a le verrou anti-suppression accidentelle comme sur RDS, par contre le gros point noir c’est l’impossibilit\u00e9 d’arr\u00eater une instance, avec comme seul mode de facturation le pay-as-you-go. Il y aussi le fait qu’une restauration de snapshot oblige \u00e0 r\u00e9impl\u00e9menter les param\u00e8tres, les r\u00e8gles firewalls et les alertes, aspect qui est pris en charge par les parameter groups et security groups chez Amazon. Et enfin autre probl\u00e8me de taille lorsqu’il faudra restaurer une sauvegarde, une ressource ne peut pas \u00eatre renomm\u00e9e dans Azure. Il faudra donc faire utiliser toujours un alias DNS dans les cha\u00eenes de connexion et jamais l’endpoint fourni par Azure. <\/p>\n

GCP:3\/5<\/strong>. Dans le cas de GCP, la surface de configuration est la plus faible avec seulement 45 param\u00e8tres modifiables contre 105 pour Azure et pr\u00e8s de 400 sur RDS. Par contre c’est GCP qui est le plus flexible sur les capacit\u00e9s d’arr\u00eat et red\u00e9marrage, je l’ai donc mis \u00e0 \u00e9galit\u00e9 avec Azure. Sur RDS, on peut stopper une instance seulement 7 jours, et sur Azure on ne peut rien arr\u00eater du tout… Sur GCP, on peut laisser une instance stopp\u00e9e sans limitation de temps, on ne paiera que le stockage. Il y a aussi le fait que le stockage ait la capacit\u00e9 d’autoscale, \u00e0 l’inverse de ses 2 concurrents. Attention toutefois \u00e0 la facture, c’est un aspect qui peut \u00eatre positif sur cette th\u00e9matique et n\u00e9gatif sur la question du prix. <\/p>\n

\n

Options de facturation<\/h2>\n

\"\"
\nRDS : 4\/5<\/strong>. J’ai mis 4 \u00e0 RDS car c’est le seul \u00e0 proposer de la r\u00e9servation sur 1 an ou 3 ans avec un paiement all upfront<\/em> ou partial upfront<\/em>, en plus du pay-as-you-go. RDS est pass\u00e9 \u00e0 une tarification \u00e0 la seconde fin mars de cette ann\u00e9e, c’est la derni\u00e8re brique qui manquait pour s’aligner sur les autres, Azure notamment. <\/p>\n

Azure: 2\/5<\/strong>. Azure ne propose que du pay-as-you-go pour MySQL, m\u00eame si la notion de r\u00e9servation commence \u00e0 arriver pour d’autres bases comme SQL Database. Et en raison de l’impossibilit\u00e9 de stopper une instance sur Azure, je ne met que 2, parce qu’il ne reste que la possibilit\u00e9 de baisser toutes les ressources d’une instance pour limiter sa tarification. Comme \u00e9voqu\u00e9 dans l’article de r\u00e9f\u00e9rence, c’est un des gros points noirs d’Azure.<\/p>\n

GCP : 3\/5<\/strong>. Comme Azure, Google ne propose qu’un syst\u00e8me en pay as you go, sans r\u00e9servation, et reste \u00e0 une tarification \u00e0 la minute pour Cloud SQL contrairement \u00e0 Azure ou RDS. Mais je l’ai mis devant Azure car une instance Cloud SQL est arr\u00eatable, donc le pay-as-you-go a du sens. <\/p>\n

\n

Diagnostics et outillage<\/h2>\n

\"\"
\nRDS : 5\/5<\/strong>. J’ai mis la note maximale l\u00e0 encore parce que RDS va au del\u00e0 de ce que permet de faire une instance on-premise. Performance Insights est un premier exemple de cette avance, c’est le seul syst\u00e8me propos\u00e9 qui puisse s’interfacer avec Performance Schema, m\u00eame si les tiers les plus modestes en sont exclus. Ensuite il y a le bien pratique collecteur GSH pour les variables de statut qui a d\u00e9j\u00e0 \u00e9t\u00e9 mentionn\u00e9. Enfin Cloudwatch pour la restitution et la gestion des alarmes. <\/p>\n

Azure : 3\/5<\/strong>. Il y a moins de compteurs disponibles sur Azure, mais tous peuvent \u00eatre li\u00e9s \u00e0 une alerte sur seuil, ce qui reste assez pratique, et c’est ce que l’on attend d’une solution de ce type. Mais il n’y a pas d’outil qui puisse s’interfacer avec Performance Schema alors qu’il est activ\u00e9 par d\u00e9faut. Quant aux variables de statut, elles sont accessibles mais il faudra construire un syst\u00e8me de collecte autour, rien n’est fourni cl\u00e9 en main. <\/p>\n

GCP : 2\/5<\/strong>. Performance Schema n’est pas disponible dans tous les tiers, et aucun outil n’est propos\u00e9 pour s’y interfacer. La couche Stackdriver propose une quinzaine de compteurs seulement, donc en termes d’int\u00e9gration et d’outillage, \u00e7a reste la plateforme la plus faible dans ce domaine. <\/p>\n

\n

Industrialisation<\/h2>\n

\"\"
\nLes 3 solutions proposent un outil de gestion en ligne de commande pour permettre l’automatisation de certaines t\u00e2ches comme le d\u00e9ploiement de nouvelles instances, les changements de taille de stockage, de tier, le red\u00e9marrage, la configuration, la bascule, le t\u00e9l\u00e9chargement des logs, etc… <\/p>\n

RDS : 4\/5<\/strong>. aws cli est de loin le CLI plus riche en commandes et fonctionnalit\u00e9s. Il y a assez peu de choses que l’on ne peut pas faire en CLI sur AWS en g\u00e9n\u00e9ral, ce qui permet de construire des outils de management cloud assez complets: cr\u00e9er un failover replica, cr\u00e9er des read replicas, faire une sauvegarde, la restaurer, cr\u00e9er des alertes, lire les logs, cr\u00e9er des alertes, reconfigurer un param\u00e8tre, g\u00e9rer les r\u00e8gles de firewall, g\u00e9rer les fen\u00eatres de maintenance, upgrader une instance, lire les \u00e9v\u00e8nements attendus comme les op\u00e9rations de maintenance pr\u00e9vues, changer de tier, de type de stockage… L’\u00e9quivalent API associ\u00e9 \u00e0 la puissance de Lambda (runtime serverless) autorise l’automatisation de n’importe quelle t\u00e2che r\u00e9currente. <\/p>\n

Azure : 3\/5<\/strong>. az cli est plus r\u00e9duit en termes de fonctionnalit\u00e9s. Le fait de ne pas pouvoir utiliser la source JSON qui d\u00e9crit les param\u00e8tres d’une instance par exemple, pour pouvoir le recr\u00e9er suite \u00e0 une restauration, rend presque impossible l’automatisation de certaines t\u00e2ches comme la duplication d’environnements. <\/p>\n

GCP : 3\/5<\/strong>. M\u00eames remarques pour GCP. gcloud permet de faire l’essentiel mais ne va pas aussi loin que l’\u00e9quivalent sur AWS. <\/p>\n

\n

Disponibilit\u00e9<\/h2>\n

\"\"
\nRDS : 4\/5<\/strong>. En mode Multi-AZ, l’instance MySQL sera secourue par une instance failover dans une autre zone de disponibilit\u00e9, synchronis\u00e9e via un m\u00e9canisme de r\u00e9plication de stockage synchrone. La d\u00e9tection du d\u00e9faut est g\u00e9r\u00e9e par un observer <\/em>externe, et la bascule de l’endpoint est automatiquement r\u00e9percut\u00e9e sur le DNS. Le co\u00fbt d’ajouter un failover fait monter la facture d’environ 40%, en fonction du tier. <\/p>\n

Azure : 2\/5<\/strong>. Pas de failover replica sur Azure. Seulement une disponibilit\u00e9 couverte localement dans l’AZ, et au del\u00e0 des volumes GRS r\u00e9pliqu\u00e9s g\u00e9ographiquement dans une autre r\u00e9gion, avec des temps de remont\u00e9e pouvant aller jusqu’\u00e0 12 heures. en fonction de l\u00e0 o\u00f9 l’on souhaite remonter l’instance de secours. C’est le moins bien loti des 3. <\/p>\n

GCP : 4\/5<\/strong>. Comme pour RDS, il est possible de d\u00e9ployer un failover replica dans une autre zone de disponibilit\u00e9. Sur GCP, l’instance failover sera maintenue synchronis\u00e9e via la r\u00e9plication GTID, c’est donc une approche compl\u00e8tement diff\u00e9rente de celle de RDS. Par contre elle sera factur\u00e9e au m\u00eame prix que l’instance nominale ce qui fait gonfler la facture de mani\u00e8re consid\u00e9rable. <\/p>\n

\n

Scalabilit\u00e9<\/h2>\n

\"\"
\nCette th\u00e9matique montre les possibilit\u00e9 de changer l’\u00e9chelle de calcul, du stockage, et de r\u00e9partir la charge en lecture avec des slaves en r\u00e9plication. Les 3 clouders proposent des solutions assez homog\u00e8nes. <\/p>\n

RDS : 4\/5<\/strong>. Changement de tier et de stockage, et m\u00eame de type de stockage (passer de GP2 \u00e0 IO1). Et possibilit\u00e9 de cr\u00e9er jusqu’\u00e0 5 read replicas pour lisser la charge en lecture seule. <\/p>\n

Azure : 4\/5<\/strong>. Changement de tier et de stockage, et 5 read replicas comme RDS. <\/p>\n

GCP : 4\/5<\/strong>. M\u00eame chose, pas de limitation donn\u00e9e sur le nombre de replicas. <\/p>\n

\n

Sauvegarde et restauration<\/h2>\n

\"\"
\nToutes les solutions proposent des backups automatiques et une restauration \u00e0 un point dans le temps. Dans tous les cas, restaurer une sauvegarde sera fera toujours sur un nouveau service PaaS cr\u00e9\u00e9 \u00e0 cette occasion. Donc il y a dans tous les cas le probl\u00e8me de renommage \u00e0 prendre en consid\u00e9ration. <\/p>\n

RDS : 4\/5<\/strong>. Sur RDS, les sauvegardes automatiques se font sous la forme de snapshots associ\u00e9s \u00e0 des logs binaires pour la restauration point-in-time. Mais il est possible de cr\u00e9er jusqu’\u00e0 50 snapshots manuels maximum par r\u00e9gion en plus des snapshots automatiques. Tous les snapshots sont copiables dans d’autres AZ \/ r\u00e9gions ou partageables avec d’autres comptes Amazon. Tout est g\u00e9rable depuis aws cli. <\/p>\n

Mais ce qui permet \u00e0 AWS d’\u00eatre devant ses concurrents, c’est le fait de pouvoir conserver les sauvegardes apr\u00e8s avoir supprim\u00e9 l’instance. Et comme on l’a d\u00e9j\u00e0 mentionn\u00e9 dans Manageabilit\u00e9<\/em>, lorsque l’on restaure le snapshot d’une instance existante, on peut directement appliquer \u00e0 la cr\u00e9ation du nouveau service PaaS le Parameter Group et le Security Group de l’ancien. <\/p>\n

Une fen\u00eatre pr\u00e9f\u00e9rentielle de sauvegarde peut \u00eatre pr\u00e9cis\u00e9e, et RDS conserve jusqu’\u00e0 35 jours maximum de sauvegarde en ligne. Et enfin, lorsque l’instance est en Multi-AZ, les backups automatiques se feront sur l’instance de failover pour limiter l’impact en termes de performances sur la production. <\/p>\n

Azure : 2\/5<\/strong>. Seules les sauvegardes automatiques sont possibles, aucune sauvegarde manuelle. Aucune possibilit\u00e9 de pr\u00e9ciser une fen\u00eatre de pr\u00e9f\u00e9rence pour les backups. Les backups peuvent \u00eatre copi\u00e9s dans une autre r\u00e9gion pour pallier \u00e0 la perte de la r\u00e9gion nominale, mais c’est \u00e0 peu pr\u00e8s tout. Et le seul point par rapport \u00e0 GCP est la r\u00e9tention jusqu’\u00e0 35 jours. <\/p>\n

GCP : 3\/5<\/strong>. Des backups automatiques sont effectu\u00e9s et stock\u00e9s dans 2 r\u00e9gions diff\u00e9rentes. Et il est possible d’indiquer une fen\u00eatre de pr\u00e9f\u00e9rence. Les backups ne seront conserv\u00e9s que 7 jours seulement. On ne peut pas backuper sur le failover replica, mais par rapport \u00e0 Azure, on peut compl\u00e9ter les backups automatiques par des backups manuels. <\/p>\n

\n

Gestion des mises \u00e0 jour<\/h2>\n

\"\"
\nChez les 3 clouders, la mise \u00e0 jour des syst\u00e8mes est pris en charge automatiquement. Ici nous \u00e9valuons la souplesse de passage de ces patches, et leur impact sur la disponibilit\u00e9 de l’instance. <\/p>\n

RDS : 4\/5<\/strong>. Sur RDS, il est possible de d\u00e9finir une fen\u00eatre pour le passage de patches syst\u00e8mes et les upgrades MySQL mineurs, et dans le cas des upgrades MySQL, il est m\u00eame possible de les d\u00e9sactiver pour les passer \u00e0 la main au besoin. Il est aussi possible de changer de version majeure alors que cela n’est pas propos\u00e9 sur GCP ou Azure. Des logs de maintenance pr\u00e9vue permettent de savoir \u00e0 l’avance si des op\u00e9rations sont \u00e0 pr\u00e9voir, et on peut aussi choisir de forcer une mise \u00e0 jour sans attendre la fen\u00eatre de maintenance. Si l’instance est en Multi-AZ, une maintenance provoque une bascule vers l’instance failover de sorte que l’interruption est minimale. <\/p>\n

Azure : 2\/5<\/strong>. Pas de fen\u00eatre pour la maintenance et les upgrades mineurs MySQL. Pas de migration majeure possible non plus. Comme il n’y a pas de failover replica sur Azure, le passage d’une maintenance implique n\u00e9cessairement son interruption, \u00e0 une p\u00e9riode qui n’est donc pas pr\u00e9visible. <\/p>\n

GCP : 3\/5<\/strong>. Il est possible de pr\u00e9ciser une fen\u00eatre de maintenance pour les instances de g\u00e9n\u00e9ration II. On ne peut pas migrer de version majeure. <\/p>\n

\n

Prix<\/h2>\n

On rappelle les \u00e9l\u00e9ments de comparaison:
\n\"\"
\nIl n’a pas de secret, la flexibilit\u00e9 et la richesse en fonctionnalit\u00e9s a un co\u00fbt. Si on se r\u00e9f\u00e8re au dernier article sur RDS<\/a>, on a vu que les 2 solutions vraiment comparables sont GCP et RDS, car dans leur co\u00fbt final respectif figure un failover replica qui n’existe pas sur Azure. Et \u00e0 ce jeu-l\u00e0, Google propose une solution qui certes ne dispose pas de tous les atouts propos\u00e9s par Amazon, mais qui pourrait bien convenir \u00e0 des petits et moyens budgets, avec des applicatifs moyennement critiques. <\/p>\n

Il faudra cependant bien faire attention aux co\u00fbt cach\u00e9s d’une migration dans le PaaS. On a vu dans la th\u00e9matique de couverture technique que Google est le moins bien plac\u00e9 des trois, ce qui signifie que si vous n’\u00eates pas dans une version support\u00e9e par GCP, il y aura avant tout une premi\u00e8re migration \u00e0 faire on-premise pour amener vos instances en 5.1 ou 5.5 \u00e0 un bon niveau de compatibilit\u00e9. Encore plus subtilement, le fait que GCP impose les transactions globales GTID notamment pour le failover replica, impose que l’instance qui migre soit en 5.6.5 minimum car il n’y a pas de support de GTID avant cette version… <\/p>\n

RDS : 2\/5<\/strong>. La seule th\u00e9matique o\u00f9 Amazon n’est pas concurrentiel. Si on regarde de pr\u00e8s la configuration, celle d’Amazon propose 200Gb \u00e0 5000 IOPS provisionn\u00e9s garantis alors que GCP ne propose que 4500 IOPS maximum. Les deux configurations propos\u00e9es ne sont donc pas si \u00e9loign\u00e9es que \u00e7a, ensuite le choix se fera sur les fonctionnalit\u00e9s. Je pense que pour les d\u00e9ploiements critiques, RDS reste la solution de choix et qu’il faudra simplement y mettre le prix. On rappelle que RDS est la seule solution qui permet de s’engager sur la dur\u00e9e et nous avons montr\u00e9 dans l’article 2\/2 sur RDS<\/a> que sur cette m\u00eame configuration on arrive \u00e0 gagner 40% du prix sur 3 ans. <\/p>\n

Azure : 3\/5<\/strong>. Sur le comparatif effectu\u00e9 dans les articles Azure est moins cher mais le calcul est fauss\u00e9 en raison de l’absence de failover replica. Il ne peut donc pas \u00eatre mis au dessus de GCP qui propose une solution plus compl\u00e8te et \u00e0 peine plus on\u00e9reuse. <\/p>\n

GCP : 4\/5<\/strong>. GCP a pour lui cet atout de comp\u00e9titivit\u00e9 sur le prix de son service. C’est un service qui on l’a vu est plus mature que celui d’Azure parce qu’il en est d\u00e9j\u00e0 \u00e0 sa seconde g\u00e9n\u00e9ration, et que le stockage propos\u00e9 est aussi le plus int\u00e9ressant en termes de rapport performances \/ prix. Et pourtant le failover replica est factur\u00e9 au prix fort, mais le co\u00fbt \u00e0 l’instance reste bien plus faible que sur RDS. M\u00eame sur 3 ans avec les 40% de r\u00e9duction, GCP reste plus attractif avec 60000 euros contre 78000 euros pour RDS. Seul petit b\u00e9mol, il faudra faire attention aux risques d’explosion de facturation en raison de l’autoscale du stockage. <\/p>\n

\n

S\u00e9curit\u00e9<\/h2>\n

\"\"
\nC’est presque un non-match tant le niveau de s\u00e9curisation est comparable sur les 3 solutions. Il n’y en a pas une qui cr\u00e9\u00e9 une fracture technologique par rapport aux autres. Le niveau est optimal pour les 3 clouders : des certificats sont fournis pour les connexions, le stockage est encryptable pour les donn\u00e9es, backups, et les flux r\u00e9seaux… etc. Ce n’est vraiment pas l\u00e0 o\u00f9 la diff\u00e9rence peut se faire…<\/p>\n

\n

Classement Final<\/h2>\n

\"\"
\nSur 12 th\u00e9matiques \u00e0 5 points, sans pond\u00e9ration, on arrive \u00e0 un classement logique dans lequel RDS domine de la t\u00eate et des \u00e9paules sans surprise, par sa polyvalence, son orientation production-ready, la richesse des fonctionnalit\u00e9s, disons que \u00e7a respire l’exp\u00e9rience. RDS est un service qui a \u00e9t\u00e9 lanc\u00e9 en 2009 avec MySQL comme premier service PaaS base de donn\u00e9e, autant dire que ‘pr\u00e9curseur’ est un qualificatif presque faible. <\/p>\n

Google Cloud SQL arrive en position de challenger, avec un excellent compromis fonctionnalit\u00e9s \/ prix, sa force principale. Les performances disque annonc\u00e9es sont concurrentielles avec les IOPS provisionn\u00e9s d’Amazon, et on dispose \u00e0 la fois d’un failover replica pour la reprise sur incident et de read replicas pour le scale-out en lecture. Il y a encore des am\u00e9liorations \u00e0 faire comme augmenter la surface de configuration de l’instance (la plus pauvre des 3), ou les interfaces de diagnostics et l’outillage pour l’analyse de performance, peut \u00eatre sur une troisi\u00e8me g\u00e9n\u00e9ration qui sera compatible avec la version 8.0 ? <\/p>\n

Azure arrive en derni\u00e8re place, on sent bien que pour l’instant les bases open-source ne sont pas encore matures dans le PaaS Microsoft. On en est \u00e0 une premi\u00e8re g\u00e9n\u00e9ration, avec des \u00e9cueils, et ce n’est pas ce qui constitue la ‘vitrine’ d’Azure en termes de bases de donn\u00e9es. Il est possible qu’avec le rachat de Citus Data<\/a> et l’int\u00e9gration r\u00e9cente dans Hyperscale<\/a>, PostgreSQL monte en force beaucoup plus vite dans la ‘culture’ MS que MySQL, l’histoire le dira.<\/p>\n

A suivre la mise \u00e0 jour avec Aurora…<\/p>\n

A bient\u00f4t !<\/p>\n

David. <\/p>\n\"twitter\"<\/a>\"linkedin\"<\/a>\"mail\"<\/a>","protected":false},"excerpt":{"rendered":"

Pour ajouter un peu de visibilit\u00e9 \u00e0 ce comparatif MySQL dans le PaaS, j’ai d\u00e9cid\u00e9 de faire un r\u00e9cap par th\u00e9matique et des podiums par solution, avec un argumentaire pour chaque cas. Cet article sera remis \u00e0 jour avec les… Continuer la lecture →<\/span><\/a><\/p>\n","protected":false},"author":2,"featured_media":7489,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[295,282,296,4],"tags":[316],"class_list":["post-7466","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-aws","category-azure","category-google-cloud-platform","category-mysql","tag-comparatif"],"yoast_head":"\nMySQL dans le PaaS : le radar de notation des solutions - Capdata TECH BLOG<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"MySQL dans le PaaS : le radar de notation des solutions - Capdata TECH BLOG\" \/>\n<meta property=\"og:description\" content=\"Pour ajouter un peu de visibilit\u00e9 \u00e0 ce comparatif MySQL dans le PaaS, j’ai d\u00e9cid\u00e9 de faire un r\u00e9cap par th\u00e9matique et des podiums par solution, avec un argumentaire pour chaque cas. Cet article sera remis \u00e0 jour avec les… Continuer la lecture →\" \/>\n<meta property=\"og:url\" content=\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/\" \/>\n<meta property=\"og:site_name\" content=\"Capdata TECH BLOG\" \/>\n<meta property=\"article:published_time\" content=\"2019-05-17T11:33:32+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-11-21T15:22:52+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/radar2.png\" \/>\n\t<meta property=\"og:image:width\" content=\"634\" \/>\n\t<meta property=\"og:image:height\" content=\"523\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"David Baffaleuf\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"David Baffaleuf\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"20 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/\"},\"author\":{\"name\":\"David Baffaleuf\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf\"},\"headline\":\"MySQL dans le PaaS : le radar de notation des solutions\",\"datePublished\":\"2019-05-17T11:33:32+00:00\",\"dateModified\":\"2022-11-21T15:22:52+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/\"},\"wordCount\":3940,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/blog.capdata.fr\/#organization\"},\"keywords\":[\"comparatif\"],\"articleSection\":[\"AWS\",\"Azure\",\"GCP\",\"MySQL\"],\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/\",\"url\":\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/\",\"name\":\"MySQL dans le PaaS : le radar de notation des solutions - Capdata TECH BLOG\",\"isPartOf\":{\"@id\":\"https:\/\/blog.capdata.fr\/#website\"},\"datePublished\":\"2019-05-17T11:33:32+00:00\",\"dateModified\":\"2022-11-21T15:22:52+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/blog.capdata.fr\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"MySQL dans le PaaS : le radar de notation des solutions\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/blog.capdata.fr\/#website\",\"url\":\"https:\/\/blog.capdata.fr\/\",\"name\":\"Capdata TECH BLOG\",\"description\":\"Le blog technique sur les bases de donn\u00e9es de CAP DATA Consulting\",\"publisher\":{\"@id\":\"https:\/\/blog.capdata.fr\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/blog.capdata.fr\/?s={search_term_string}\"},\"query-input\":\"required name=search_term_string\"}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/blog.capdata.fr\/#organization\",\"name\":\"Capdata TECH BLOG\",\"url\":\"https:\/\/blog.capdata.fr\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp\",\"contentUrl\":\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp\",\"width\":800,\"height\":254,\"caption\":\"Capdata TECH BLOG\"},\"image\":{\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.linkedin.com\/company\/cap-data-consulting\/mycompany\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf\",\"name\":\"David Baffaleuf\",\"sameAs\":[\"http:\/\/www.capdata.fr\"],\"url\":\"https:\/\/blog.capdata.fr\/index.php\/author\/dbaffaleuf\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"MySQL dans le PaaS : le radar de notation des solutions - Capdata TECH BLOG","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/","og_locale":"fr_FR","og_type":"article","og_title":"MySQL dans le PaaS : le radar de notation des solutions - Capdata TECH BLOG","og_description":"Pour ajouter un peu de visibilit\u00e9 \u00e0 ce comparatif MySQL dans le PaaS, j’ai d\u00e9cid\u00e9 de faire un r\u00e9cap par th\u00e9matique et des podiums par solution, avec un argumentaire pour chaque cas. Cet article sera remis \u00e0 jour avec les… Continuer la lecture →","og_url":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/","og_site_name":"Capdata TECH BLOG","article_published_time":"2019-05-17T11:33:32+00:00","article_modified_time":"2022-11-21T15:22:52+00:00","og_image":[{"width":634,"height":523,"url":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/05\/radar2.png","type":"image\/png"}],"author":"David Baffaleuf","twitter_card":"summary_large_image","twitter_misc":{"\u00c9crit par":"David Baffaleuf","Dur\u00e9e de lecture estim\u00e9e":"20 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/#article","isPartOf":{"@id":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/"},"author":{"name":"David Baffaleuf","@id":"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf"},"headline":"MySQL dans le PaaS : le radar de notation des solutions","datePublished":"2019-05-17T11:33:32+00:00","dateModified":"2022-11-21T15:22:52+00:00","mainEntityOfPage":{"@id":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/"},"wordCount":3940,"commentCount":0,"publisher":{"@id":"https:\/\/blog.capdata.fr\/#organization"},"keywords":["comparatif"],"articleSection":["AWS","Azure","GCP","MySQL"],"inLanguage":"fr-FR","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/","url":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/","name":"MySQL dans le PaaS : le radar de notation des solutions - Capdata TECH BLOG","isPartOf":{"@id":"https:\/\/blog.capdata.fr\/#website"},"datePublished":"2019-05-17T11:33:32+00:00","dateModified":"2022-11-21T15:22:52+00:00","breadcrumb":{"@id":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/blog.capdata.fr\/index.php\/mysql-dans-le-paas-le-radar-de-notation-des-solutions\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/blog.capdata.fr\/"},{"@type":"ListItem","position":2,"name":"MySQL dans le PaaS : le radar de notation des solutions"}]},{"@type":"WebSite","@id":"https:\/\/blog.capdata.fr\/#website","url":"https:\/\/blog.capdata.fr\/","name":"Capdata TECH BLOG","description":"Le blog technique sur les bases de donn\u00e9es de CAP DATA Consulting","publisher":{"@id":"https:\/\/blog.capdata.fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/blog.capdata.fr\/?s={search_term_string}"},"query-input":"required name=search_term_string"}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/blog.capdata.fr\/#organization","name":"Capdata TECH BLOG","url":"https:\/\/blog.capdata.fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/","url":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp","contentUrl":"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2023\/01\/logo_capdata.webp","width":800,"height":254,"caption":"Capdata TECH BLOG"},"image":{"@id":"https:\/\/blog.capdata.fr\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.linkedin.com\/company\/cap-data-consulting\/mycompany\/"]},{"@type":"Person","@id":"https:\/\/blog.capdata.fr\/#\/schema\/person\/136297da9f61d6e4878abe0f48bc5fbf","name":"David Baffaleuf","sameAs":["http:\/\/www.capdata.fr"],"url":"https:\/\/blog.capdata.fr\/index.php\/author\/dbaffaleuf\/"}]}},"_links":{"self":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/7466","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/comments?post=7466"}],"version-history":[{"count":8,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/7466\/revisions"}],"predecessor-version":[{"id":9498,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/posts\/7466\/revisions\/9498"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/media\/7489"}],"wp:attachment":[{"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/media?parent=7466"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/categories?post=7466"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.capdata.fr\/index.php\/wp-json\/wp\/v2\/tags?post=7466"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}