{"id":37975,"date":"2019-10-31T22:20:56","date_gmt":"2019-10-31T19:20:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost\/"},"modified":"2019-10-31T22:20:56","modified_gmt":"2019-10-31T19:20:56","slug":"apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","title":{"rendered":"Am\u00e9lioration pour les paresseux : comment PostgreSQL 12 am\u00e9liore la performance","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Am\u00e9lioration<\/p>\n

PostgreSQL 12<\/a><\/noindex>, la derni\u00e8re version de \u00ab la meilleure base de donn\u00e9es relationnelle open source au monde \u00bb, sera disponible dans quelques semaines (si tout se passe comme pr\u00e9vu). Cela correspond \u00e0 un calendrier habituel \u2014 une nouvelle version avec de nombreuses nouvelles fonctionnalit\u00e9s est publi\u00e9e chaque ann\u00e9e, et, honn\u00eatement, c'est impressionnant. C'est pourquoi je suis devenu un membre actif de la communaut\u00e9 PostgreSQL.<\/p>\n

<\/p>\n

\u00c0 mon avis, contrairement aux versions pr\u00e9c\u00e9dentes, PostgreSQL 12 ne contient pas une ou deux fonctionnalit\u00e9s r\u00e9volutionnaires (comme le partitionnement ou le parall\u00e9lisme des requ\u00eates). J'ai plaisant\u00e9 en disant que la principale caract\u00e9ristique de PostgreSQL 12 est une plus grande stabilit\u00e9. N'est-ce pas ce dont vous avez besoin lorsque vous g\u00e9rez des donn\u00e9es critiques pour votre entreprise ?<\/p>\n

<\/p>\n

Mais PostgreSQL 12 ne s'arr\u00eate pas l\u00e0 : avec les nouvelles fonctionnalit\u00e9s et am\u00e9liorations, les applications fonctionneront mieux, et il vous suffit de r\u00e9aliser une mise \u00e0 niveau !<\/em><\/p>\n

<\/p>\n

(Eh bien, peut-\u00eatre aussi de reconstruire les index, mais dans cette version, ce n'est pas si grave que nous avons l'habitude de le penser.)<\/p>\n

<\/a><\/noindex><\/p>\n

Ce serait super \u2014 mettre \u00e0 niveau PostgreSQL et profiter imm\u00e9diatement d'am\u00e9liorations significatives sans effort suppl\u00e9mentaire. Il y a quelques ann\u00e9es, j'ai analys\u00e9 la mise \u00e0 jour de PostgreSQL 9.4 \u00e0 PostgreSQL 10 et j'ai vu comment l'application s'\u00e9tait acc\u00e9l\u00e9r\u00e9e gr\u00e2ce au meilleur parall\u00e9lisme des requ\u00eates dans PostgreSQL 10. Et surtout, il ne m'a presque rien \u00e9t\u00e9 demand\u00e9 (il suffisait de d\u00e9finir un param\u00e8tre de configuration max_parallel_workers<\/code>).<\/p>\n

<\/p>\n

Vous conviendrez qu'il est pratique que les applications fonctionnent mieux imm\u00e9diatement apr\u00e8s une mise \u00e0 niveau. Et nous faisons de notre mieux pour ravir les utilisateurs, car PostgreSQL en a de plus en plus.<\/p>\n

<\/p>\n

Et comment une simple mise \u00e0 niveau vers PostgreSQL 12 vous rendra-t-elle heureux ? Je vais vous le raconter maintenant.<\/p>\n

<\/p>\n

Am\u00e9liorations significatives de l'indexation<\/h3>\n

<\/p>\n

Sans indexation, une base de donn\u00e9es n'ira pas loin. Comment trouver rapidement des informations autrement ? Le syst\u00e8me fondamental d'indexation de PostgreSQL s'appelle l'arbre B<\/a><\/noindex>. Ce type d'index est optimis\u00e9 pour les syst\u00e8mes de stockage.<\/p>\n

<\/p>\n

Nous utilisons simplement l'instruction CREATE INDEX ON some_table (some_column)<\/code>, et PostgreSQL fait le gros du travail pour maintenir la pertinence de l'index pendant que nous ins\u00e9rons, mettons \u00e0 jour et supprimons constamment des valeurs. Tout fonctionne tout seul, comme par magie.<\/p>\n

<\/p>\n

Mais les index de PostgreSQL ont un probl\u00e8me \u2014 ils s'\u00e9tendent<\/a><\/noindex> et occupent un espace disque inutile, r\u00e9duisant ainsi la performance de l'extraction et de la mise \u00e0 jour des donn\u00e9es. Par \u00ab gonflement \u00bb, j'entends le maintien inefficace de la structure d'index. Cela peut \u00eatre, ou non, li\u00e9 aux tuples orphelins que supprime VACUUM<\/a><\/noindex> (merci pour l'information \u00e0 Peter Geoghegan (Peter Geoghegan<\/a><\/noindex>)). Le gonflement de l'index est particuli\u00e8rement visible dans les charges de travail o\u00f9 l'index est activement modifi\u00e9.<\/p>\n

<\/p>\n

PostgreSQL 12 am\u00e9liore consid\u00e9rablement le fonctionnement des index en arbre B, et des exp\u00e9riences avec des tests de type TPC-C ont montr\u00e9 que l'espace utilis\u00e9 n'est maintenant, en moyenne, que 40 % de moins. Nous d\u00e9pensons d\u00e9sormais moins de temps non seulement pour l'entretien des index en arbre B (c'est-\u00e0-dire pour les op\u00e9rations d'\u00e9criture), mais aussi pour l'extraction des donn\u00e9es, car les index sont devenus beaucoup plus petits.<\/p>\n

<\/p>\n

Les applications qui mettent \u00e0 jour activement leurs tables \u2014 g\u00e9n\u00e9ralement des applications OLTP (traitement des transactions en temps r\u00e9el<\/a><\/noindex>) \u2014 utiliseront beaucoup plus efficacement le disque et traiteront les requ\u00eates. Plus il y a d'espace sur le disque, plus la base de donn\u00e9es dispose d'espace pour cro\u00eetre sans mettre \u00e0 niveau l'infrastructure.<\/p>\n

<\/p>\n

Certaines strat\u00e9gies de mise \u00e0 niveau n\u00e9cessitent la reconstruction des index en arbre B pour profiter de ces avantages (par exemple, pg_upgrade<\/a><\/noindex> ne reconstruit pas automatiquement les index). Dans les versions pr\u00e9c\u00e9dentes de PostgreSQL, la reconstruction de gros index dans des tables entra\u00eenait des temps d'arr\u00eat significatifs, car pendant ce temps, aucune modification ne pouvait \u00eatre apport\u00e9e. Mais dans PostgreSQL 12, il y a une autre fonctionnalit\u00e9 int\u00e9ressante : il est d\u00e9sormais possible de reconstruire les index en parall\u00e8le avec la commande REINDEX CONCURRENTLY<\/a><\/noindex>, afin d'\u00e9viter compl\u00e8tement le temps d'arr\u00eat.<\/p>\n

<\/p>\n

Dans PostgreSQL 12, il y a \u00e9galement d'autres am\u00e9liorations de l'infrastructure d'indexation. Une autre chose o\u00f9 la magie a fait son effet est le journal de pr\u00e9\u00e9criture<\/a><\/noindex>, aussi connu sous le nom de WAL (write-ahead log). Le journal de pr\u00e9\u00e9criture enregistre chaque transaction dans PostgreSQL en cas de panne et pour la r\u00e9plication. Les applications l'utilisent pour l'archivage et la r\u00e9cup\u00e9ration \u00e0 un moment donn\u00e9<\/a><\/noindex>. Bien s\u00fbr, le journal de pr\u00e9\u00e9criture est \u00e9crit sur disque, ce qui peut affecter les performances.<\/p>\n

<\/p>\n

Dans PostgreSQL 12, les co\u00fbts des enregistrements WAL g\u00e9n\u00e9r\u00e9s par les index GiST, GIN et SP-GiST lors de la construction de l'index ont \u00e9t\u00e9 r\u00e9duits. Cela offre plusieurs avantages tangibles : les enregistrements WAL occupent moins d'espace disque et les donn\u00e9es se reproduisent plus rapidement, par exemple lors d'une restauration apr\u00e8s un plantage ou lors d'une r\u00e9cup\u00e9ration \u00e0 un moment donn\u00e9. Si vous utilisez ces index dans vos applications (par exemple, les applications g\u00e9ospatiales bas\u00e9es sur PostGIS utilisent beaucoup l'index GiST), c'est une autre fonctionnalit\u00e9 qui am\u00e9liorera consid\u00e9rablement les performances sans effort de votre part.<\/p>\n

<\/p>\n

Le partitionnement - plus, mieux, plus rapide<\/h3>\n

<\/p>\n

Dans PostgreSQL 10, le partitionnement d\u00e9claratif<\/a><\/noindex>. Dans PostgreSQL 11, son utilisation est devenue beaucoup plus simple. Dans PostgreSQL 12, le dimensionnement des sections peut \u00eatre modifi\u00e9.<\/p>\n

<\/p>\n

Dans PostgreSQL 12, la performance du syst\u00e8me de partitionnement s'est consid\u00e9rablement am\u00e9lior\u00e9e, surtout si la table contient des milliers de sections. Par exemple, si une requ\u00eate ne touche que quelques sections d'une table contenant des milliers d'entre elles, elle s'ex\u00e9cutera beaucoup plus rapidement. La performance a \u00e9t\u00e9 am\u00e9lior\u00e9e non seulement pour ce type de requ\u00eates. Vous remarquerez \u00e9galement comment les op\u00e9rations INSERT dans les tables avec de nombreuses sections ont \u00e9t\u00e9 acc\u00e9l\u00e9r\u00e9es.<\/p>\n

<\/p>\n

L'enregistrement des donn\u00e9es via COPY<\/a><\/noindex> - d'ailleurs, c'est un excellent moyen de charger des donn\u00e9es en masse<\/a><\/noindex> et voici un exemple avec JSON<\/a><\/noindex> - dans les tables partitionn\u00e9es de PostgreSQL 12 est \u00e9galement devenu plus efficace. Avec COPY, c'\u00e9tait d\u00e9j\u00e0 rapide, mais dans PostgreSQL 12, c'est vraiment rapide.<\/p>\n

<\/p>\n

Gr\u00e2ce \u00e0 ces avantages, PostgreSQL peut stocker des ensembles de donn\u00e9es encore plus grands, et leur extraction est devenue plus simple. Et sans aucun effort de votre part. Si votre application poss\u00e8de de nombreuses sections, par exemple, si elle \u00e9crit des donn\u00e9es de s\u00e9ries temporelles, une simple mise \u00e0 niveau am\u00e9liorera consid\u00e9rablement ses performances.<\/p>\n

<\/p>\n

Et m\u00eame si cette am\u00e9lioration n'est pas tout \u00e0 fait dans la cat\u00e9gorie \u00ab nous avons mis \u00e0 niveau et nous nous r\u00e9jouissons \u00bb, dans PostgreSQL 12, il est possible de cr\u00e9er des cl\u00e9s \u00e9trang\u00e8res qui font r\u00e9f\u00e9rence \u00e0 des tables partitionn\u00e9es, rendant le travail avec le partitionnement un v\u00e9ritable plaisir.<\/p>\n

<\/p>\n

Les requ\u00eates WITH se sont beaucoup am\u00e9lior\u00e9es<\/h3>\n

<\/p>\n

Lorsque un patch a \u00e9t\u00e9 appliqu\u00e9 pour les expressions de table g\u00e9n\u00e9ralis\u00e9es int\u00e9gr\u00e9es<\/a><\/noindex> (\u00e9galement appel\u00e9es CTE, \u00e9galement des requ\u00eates WITH), j'\u00e9tais impatient d'\u00e9crire un article sur la joie des d\u00e9veloppeurs d'applications utilisant PostgreSQL<\/a><\/noindex>. C'est l'une de ces fonctionnalit\u00e9s qui acc\u00e9l\u00e9rera l'application. Si, bien s\u00fbr, vous utilisez des CTE.<\/p>\n

<\/p>\n

Je remarque souvent que les d\u00e9butants en SQL aiment utiliser les CTE : si on les \u00e9crit d'une certaine mani\u00e8re, on a vraiment l'impression d'\u00e9crire un programme imp\u00e9ratif. Personnellement, j'aimais r\u00e9\u00e9crire ces requ\u00eates pour m'en passer. sans<\/em> CTE et am\u00e9liorer les performances. Tout est diff\u00e9rent maintenant.<\/p>\n

<\/p>\n

PostgreSQL 12 permet d'int\u00e9grer un certain type de CTE sans effets secondaires (SELECT<\/code>), qui n'est utilis\u00e9 qu'une seule fois pr\u00e8s de la fin de la requ\u00eate. Si je tenais des statistiques sur les requ\u00eates avec CTE que je r\u00e9\u00e9crivais, la plupart d'entre elles tomberaient dans cette cat\u00e9gorie. Cela aide les d\u00e9veloppeurs \u00e0 \u00e9crire un code compr\u00e9hensible, qui fonctionne d\u00e9sormais aussi rapidement.<\/p>\n

<\/p>\n

De plus, PostgreSQL 12 optimise l'ex\u00e9cution des SQL par lui-m\u00eame, vous n'avez rien \u00e0 faire. Et bien que je n'aurai probablement plus besoin d'optimiser ces requ\u00eates, c'est super que PostgreSQL continue \u00e0 travailler sur l'optimisation des requ\u00eates.<\/p>\n

<\/p>\n

Just-in-Time (JIT) \u2014 est maintenant activ\u00e9 par d\u00e9faut.<\/h3>\n

<\/p>\n

Dans les syst\u00e8mes PostgreSQL 12 prenant en charge LLVM<\/a><\/noindex> La compilation JIT est activ\u00e9e par d\u00e9faut. Tout d'abord, vous b\u00e9n\u00e9ficiez du support JIT<\/a><\/noindex> pour certaines op\u00e9rations internes, et deuxi\u00e8mement, les requ\u00eates avec des expressions (le plus simple exemple est x + y) dans les listes de s\u00e9lection (qui se trouvent apr\u00e8s SELECT), les agr\u00e9gats, les expressions avec des clauses WHERE et d'autres peuvent utiliser JIT pour am\u00e9liorer les performances.<\/p>\n

<\/p>\n

Puisque JIT est activ\u00e9 par d\u00e9faut dans PostgreSQL 12, la performance s'am\u00e9liorera par elle-m\u00eame, mais je conseille de tester l'application dans PostgreSQL 11, o\u00f9 JIT a fait ses d\u00e9buts, afin de mesurer la performance des requ\u00eates et de d\u00e9terminer s'il est n\u00e9cessaire d'ajuster quelque chose.<\/p>\n

<\/p>\n

Et qu'en est-il des autres nouvelles fonctionnalit\u00e9s de PostgreSQL 12 ?<\/h3>\n

<\/p>\n

PostgreSQL 12 offre une multitude de nouvelles fonctionnalit\u00e9s int\u00e9ressantes \u2014 de la possibilit\u00e9 d'explorer des donn\u00e9es JSON \u00e0 l'aide d'expressions SQL\/JSON standard \u00e0 l'authentification multifactorielle avec l'option clientcert=verify-full<\/code>, des colonnes g\u00e9n\u00e9r\u00e9es et bien d'autres encore. Il y a de quoi \u00e9crire un article s\u00e9par\u00e9.<\/p>\n

<\/p>\n

Tout comme PostgreSQL 10, PostgreSQL 12 am\u00e9liorera les performances globales imm\u00e9diatement apr\u00e8s la mise \u00e0 niveau. Vous aurez, bien s\u00fbr, votre propre fa\u00e7on de faire \u2014 testez l'application dans des conditions similaires dans un syst\u00e8me de production avant d'activer les am\u00e9liorations, comme je l'ai fait avec PostgreSQL 10. M\u00eame si PostgreSQL 12 est d\u00e9j\u00e0 plus stable que je ne l'aurais pens\u00e9, ne n\u00e9gligez pas de tester soigneusement les applications avant de les mettre en production.<\/p>\n

Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

PostgreSQL 12, \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u044f\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u00ab\u043b\u0443\u0447\u0448\u0435\u0439 \u0432 \u043c\u0438\u0440\u0435 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 \u0441 \u043e\u0442\u043a\u0440\u044b\u0442\u044b\u043c \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u043c \u043a\u043e\u0434\u043e\u043c\u00bb, \u0432\u044b\u0445\u043e\u0434\u0438\u0442 \u0447\u0435\u0440\u0435\u0437 \u043f\u0430\u0440\u0443-\u0442\u0440\u043e\u0439\u043a\u0443 \u043d\u0435\u0434\u0435\u043b\u044c (\u0435\u0441\u043b\u0438 \u0432\u0441\u0435 \u043f\u043e\u0439\u0434\u0435\u0442 \u043f\u043e \u043f\u043b\u0430\u043d\u0443). \u042d\u0442\u043e \u0441\u043e\u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0443\u0435\u0442 \u043e\u0431\u044b\u0447\u043d\u043e\u043c\u0443 \u0440\u0430\u0441\u043f\u0438\u0441\u0430\u043d\u0438\u044e \u2014 \u043d\u043e\u0432\u0430\u044f \u0432\u0435\u0440\u0441\u0438\u044f \u0441 \u0443\u0439\u043c\u043e\u0439 \u043d\u043e\u0432\u044b\u0445 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0435\u0439 \u0432\u044b\u0445\u043e\u0434\u0438\u0442 \u0440\u0430\u0437 \u0432 \u0433\u043e\u0434, \u0438, \u0447\u0435\u0441\u0442\u043d\u043e \u0433\u043e\u0432\u043e\u0440\u044f, \u044d\u0442\u043e \u0432\u043f\u0435\u0447\u0430\u0442\u043b\u044f\u0435\u0442. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u044f \u0438 \u0441\u0442\u0430\u043b \u0430\u043a\u0442\u0438\u0432\u043d\u044b\u043c \u0447\u043b\u0435\u043d\u043e\u043c \u0441\u043e\u043e\u0431\u0449\u0435\u0441\u0442\u0432\u0430 PostgreSQL. \u041f\u043e-\u043c\u043e\u0435\u043c\u0443, \u0432 \u043e\u0442\u043b\u0438\u0447\u0438\u0435 \u043e\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":28500,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-37975","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Am\u00e9lioration pour les paresseux : comment PostgreSQL 12 am\u00e9liore les performances | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","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\udd47\u0410\u043f\u0433\u0440\u0435\u0439\u0434 \u0434\u043b\u044f \u043b\u0435\u043d\u0438\u0432\u044b\u0445: \u043a\u0430\u043a PostgreSQL 12 \u043f\u043e\u0432\u044b\u0448\u0430\u0435\u0442 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c | ProHoster","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/apgrejd-dlya-lenivyh-kak-postgresql-12-povyshaet-proizvoditelnost","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":"2019-10-31T19:20:56+00:00","article:modified_time":"2019-10-31T19:20:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"37975","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":"2026-01-23 19:59:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:17:22","updated":"2026-01-23 19:59:19","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\/37975","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=37975"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/37975\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/28500"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=37975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=37975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=37975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}