{"id":39169,"date":"2019-10-31T22:28:14","date_gmt":"2019-10-31T19:28:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya\/"},"modified":"2019-10-31T22:28:14","modified_gmt":"2019-10-31T19:28:14","slug":"postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","title":{"rendered":"PostgreSQL e impostazioni di coerenza della scrittura per ciascuna connessione specifica","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Traduzione dell'articolo preparata appositamente per gli studenti del corso \u00abBasi di Dati\u00bb<\/a><\/noindex>. Ti interessa svilupparti in questo campo? Ti invitiamo a Giornata di Porte Aperte<\/a><\/noindex>, dove parleremo dettagliatamente del programma, delle caratteristiche del formato online, delle competenze e delle prospettive di carriera che attendono i laureati dopo il corso.<\/em><\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

PostgreSQL e impostazioni di coerenza della scrittura per ciascuna connessione specifica
\nNoi di Compose abbiamo a che fare con molte basi di dati, e proprio questo ci d\u00e0 l'opportunit\u00e0 di approfondire la loro funzionalit\u00e0 e i loro limiti. Man mano che impariamo ad apprezzare le caratteristiche funzionali delle nuove basi di dati, a volte iniziamo a pensare a come sarebbe bello se tali funzioni fossero presenti anche negli strumenti pi\u00f9 maturi con cui lavoriamo da tempo. Una delle nuove funzionalit\u00e0 che avremmo voluto vedere in PostgreSQL era la coerenza scritturale configurabile per connessione in tutto il cluster. E, a quanto pare, ce l'abbiamo gi\u00e0, e oggi vogliamo condividere con te informazioni su come puoi utilizzarla.<\/a><\/noindex><\/p>\n

<\/p>\n

A cosa mi serve?<\/h1>\n

<\/p>\n

Il modo in cui deve comportarsi un cluster dipende dalla tua applicazione. Prendiamo, ad esempio, un'applicazione per il pagamento delle bollette. Avrai bisogno di coerenza totale nel cluster, quindi dovrai abilitare i commit sincronizzati affinch\u00e9 il tuo database attenda l'applicazione di tutte le modifiche. Tuttavia, se la tua applicazione \u00e8 un social network in rapida evoluzione, probabilmente preferirai una risposta rapida rispetto alla coerenza totale. Per raggiungere questo obiettivo, puoi utilizzare nel tuo cluster commit asincroni.<\/p>\n

<\/p>\n

Ecco il compromesso<\/h2>\n

<\/p>\n

Dovrai scendere a compromessi tra la coerenza dei dati e le prestazioni. PostgreSQL tende verso la coerenza, poich\u00e9 la configurazione predefinita risulta cos\u00ec prevedibile, senza sorprese inaspettate. E ora iniziamo a esplorare questi compromessi.<\/p>\n

<\/p>\n

Compromesso 1: Prestazioni<\/h3>\n

<\/p>\n

Se al cluster PostgreSQL non \u00e8 richiesta coerenza, pu\u00f2 tranquillamente operare in modo asincrono. La scrittura avviene sul leader del cluster e le sue repliche riceveranno gli aggiornamenti dopo alcuni millisecondi. Quando al cluster PostgreSQL \u00e8 richiesta coerenza, deve operare in modo sincrono. La scrittura sar\u00e0 eseguita sul leader del cluster, che invier\u00e0 l'aggiornamento alle repliche e attender\u00e0 una conferma che ognuna di esse ha registrato l'operazione, prima di inviare la conferma al cliente che ha avviato la scrittura, informandolo che l'operazione \u00e8 andata a buon fine. La differenza pratica tra questi approcci \u00e8 che il metodo asincrono richiede due salti di rete, mentre il sincrono ne richiede quattro. <\/p>\n

<\/p>\n

Compromesso 2: Coerenza<\/h3>\n

<\/p>\n

Il risultato in caso di guasto del leader in questi due approcci sar\u00e0 diverso. Se l'operazione \u00e8 eseguita in modo asincrono, in caso di errore, non tutte le scritture saranno registrate dalle repliche. Quanto sar\u00e0 perso? Dipende dall'applicazione stessa e dall'efficacia della replicazione. La replicazione di Compose impedir\u00e0 alla replica di diventare leader nel caso in cui la quantit\u00e0 di informazioni in essa sia inferiore di 1 MB rispetto al leader, il che significa che potrebbero andare perse fino a 1 MB di scritture durante l'operativit\u00e0 asincrona. <\/p>\n

<\/p>\n

In modalit\u00e0 sincrona questo non accade. Se il leader fallisce, tutte le repliche vengono aggiornate, poich\u00e9 ogni scrittura confermata dal leader deve essere confermata anche nelle repliche. Ecco qua: coerenza. <\/p>\n

<\/p>\n

Il comportamento sincrono ha senso utilizzarlo in un'applicazione per la gestione dei pagamenti, dove la coerenza ha un chiaro vantaggio nel cercare un compromesso tra coerenza e prestazioni. La cosa pi\u00f9 importante per un'applicazione di questo tipo sono i dati validi. Ora, pensate a un social network, dove l'obiettivo principale \u00e8 mantenere l'attenzione dell'utente, rispondendo alle richieste il pi\u00f9 rapidamente possibile. In tal caso, le prestazioni con un numero inferiore di salti di rete e un'attesa minore per i commit avranno la priorit\u00e0. Tuttavia, il compromesso tra prestazioni e coerenza non \u00e8 l'unico di cui tenere conto.<\/p>\n

<\/p>\n

Compromesso 3: Guasti<\/h3>\n

<\/p>\n

\u00c8 molto importante capire come si comporta un cluster durante un guasto. Consideriamo la situazione in cui una o pi\u00f9 repliche si guastano. Quando i commit vengono elaborati in modo asincrono, il leader continua a funzionare, cio\u00e8 accetta ed elabora le scritture senza aspettare le repliche mancanti. Quando le repliche tornano nel cluster, raggiungono il leader. Con la replicazione sincronizzata, se le repliche non rispondono, il leader non avr\u00e0 scelta e continuer\u00e0 a aspettare la conferma del commit finch\u00e9 la replica non torner\u00e0 nel cluster e non potr\u00e0 accettare e confermare la scrittura.<\/p>\n

<\/p>\n

Una connessione per transazione?<\/h2>\n

<\/p>\n

Ogni applicazione ha bisogno di un tipo speciale di combinazione tra coerenza e prestazioni. A meno che non si tratti ovviamente della nostra applicazione per il pagamento delle fatture, che immaginiamo essere completamente coerente, o della nostra applicazione per social network quasi effimera. In tutti gli altri casi ci saranno momenti in cui alcune operazioni devono essere sincronizzate e altre asincrone. Potresti non volere che il sistema aspetti che un messaggio inviato in chat venga confermato, ma se in quella stessa applicazione avviene un pagamento, allora dovrai aspettare.<\/p>\n

<\/p>\n

Tutte queste decisioni, ovviamente, ricadono sullo sviluppatore dell'applicazione. Le giuste decisioni su quando applicare un approccio piuttosto che un altro aiuteranno a ottenere il massimo dal cluster. \u00c8 importante che lo sviluppatore possa alternare tra di essi a livello di SQL per le connessioni e per le transazioni. <\/p>\n

<\/p>\n

Garantire il controllo nella pratica<\/h2>\n

<\/p>\n

Per impostazione predefinita, PostgreSQL garantisce coerenza. Questo \u00e8 controllato dal parametro del server synchronous_commit<\/code>. Per impostazione predefinita \u00e8 impostato su on<\/code>, ma ha altre tre opzioni: local<\/code>, remote_write<\/code> o off<\/code>.<\/p>\n

<\/p>\n

Se il parametro \u00e8 impostato su off<\/code> , tutti i commit sincronizzati vengono interrotti, anche nella sistema locale. Il parametro in local definisce la modalit\u00e0 sincronizzata per il sistema locale, ma le scritture sulle repliche avvengono in modo asincrono. Remote_write<\/code> va ancora oltre: le scritture sulle repliche avvengono in modo asincrono, ma vengono restituite quando la replica ha accettato la scrittura, ma non l'ha ancora registrata su disco.<\/p>\n

<\/p>\n

Considerando l'attuale gamma di opzioni, scegliamo il comportamento e, tenendo presente che on<\/code> \u2013 sono scritture sincrone, sceglieremo local<\/code> per i commit asincroni sulla rete, lasciando i commit locali sincronizzati.<\/p>\n

<\/p>\n

Ora vi spiegheremo come configurarlo in un attimo, ma immaginate che abbiamo installato synchronous_commit<\/code> in local<\/code> per il server. Ci siamo chiesti se fosse possibile modificare il parametro synchronous_commit<\/code> al volo, e si \u00e8 scoperto che non solo \u00e8 possibile, ma ci sono addirittura due modi per farlo. Il primo \u00e8 impostare la sessione della vostra connessione nel seguente modo:<\/p>\n

<\/p>\n

SET SESSION synchronous_commit TO ON;  \n\/\/ Le vostre scritture vanno qui<\/code><\/pre>\n
<\/p>\n
Tutte le scritture successive nella sessione confermeranno le operazioni di scrittura per le repliche, prima di restituire un risultato positivo al client connesso. A meno che, naturalmente, non cambiate di nuovo l'impostazione. synchronous_commit<\/code> \u00c8 possibile omettere la parte SESSION<\/code> nel comando, poich\u00e9 sar\u00e0 impostata sul valore predefinito.<\/p>\n
<\/p>\n
Il secondo metodo \u00e8 utile quando vuoi semplicemente assicurarti di ottenere una replica sincrona per una singola transazione. In molti database di tipo 'NoSQL' non esiste il concetto di transazioni, ma questo \u00e8 presente in PostgreSQL. In tal caso, avvii una transazione e poi imposti synchronous_commit<\/code> in on<\/code> prima di eseguire la scrittura per la transazione. COMMIT<\/code> confermer\u00e0 la transazione, utilizzando qualsiasi valore del parametro synchronous_commit<\/code>, che \u00e8 stato impostato in quel momento, anche se \u00e8 meglio impostare la variabile in anticipo, in modo che gli altri sviluppatori comprendano che le scritture non sono asincrone.<\/p>\n
<\/p>\n
BEGIN;  \nSET LOCAL synchronous_commit TO ON;  \n\/\/ Le vostre scritture vanno qui\nCOMMIT;  <\/code><\/pre>\n
<\/p>\n
Ora tutti i commit delle transazioni saranno confermati, come scritti nelle repliche, ancor prima che il database restituisca una risposta positiva al client connesso.<\/p>\n
<\/p>\n
Configurazione di PostgreSQL<\/h2>\n
<\/p>\n
Prima di questo, immaginavamo un sistema PostgreSQL con synchronous_commit<\/code>, impostato su local<\/code>. Affinch\u00e9 questo sia reale sul lato server, sar\u00e0 necessario impostare due parametri di configurazione del server. Un altro parametro synchronous_standby_names<\/code> entrer\u00e0 in gioco quando synchronous_commit<\/code> sar\u00e0 in on<\/code>. Esso definisce quali repliche hanno diritto a commit sincroni, e lo imposteremo su *<\/code>, il che significher\u00e0 coinvolgere tutte le repliche. Questi valori vengono generalmente configurati in file di configurazione<\/a><\/noindex> aggiungendo: <\/p>\n
<\/p>\n
synchronous_commit = local  \nsynchronous_standby_names='*'<\/code><\/pre>\n
<\/p>\n
Impostando il parametro synchronous_commit<\/code> a valore local<\/code>, stiamo creando un sistema in cui i dischi locali rimangono sincroni, ma i commit delle repliche di rete sono di default asincroni. A meno che, naturalmente, non decidiamo di rendere questi commit sincroni, come mostrato sopra.<\/p>\n
<\/p>\n
Se avete seguito l'evoluzione del progetto Governor<\/a><\/noindex>, potreste aver notato alcuni cambiamenti recenti (1<\/a><\/noindex>, 2<\/a><\/noindex>), che hanno permesso agli utenti di Governor di testare queste impostazioni e di controllarne la coerenza.<\/p>\n
<\/p>\n
Altre due parole\u2026<\/h2>\n
<\/p>\n
Letteralmente una settimana fa, ti avrei detto che era impossibile ottimizzare cos\u00ec finemente PostgreSQL. \u00c8 stato allora che Kurt, un membro del team della piattaforma Compose, ha insistito sul fatto che esisteva questa possibilit\u00e0. Ha placato le mie obiezioni e ha trovato nella documentazione di PostgreSQL quanto segue<\/a><\/noindex>:<\/p>\n
<\/p>\n
\"PostgreSQL<\/p>\n
<\/p>\n
Questo parametro pu\u00f2 essere modificato in qualsiasi momento. Il comportamento di ogni transazione \u00e8 determinato dall'impostazione attiva al momento del commit. Pertanto, \u00e8 possibile e utile che per alcune transazioni i commit avvengano in modo sincrono, mentre per altre in modo asincrono. Ad esempio, per costringere una multistatement<\/code> transazione a eseguire commit in modo asincrono, quando il valore predefinito \u00e8 l'opposto, impostare <\/em>SET LOCAL synchronous_commit TO OFF<\/code> nella transazione.<\/em><\/p>\n
<\/p>\n
Con una piccola modifica al file di configurazione, abbiamo dato agli utenti la possibilit\u00e0 di controllare la loro coerenza e prestazioni.<\/p>\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043a\u0443\u0440\u0441\u0430 \u00ab\u0411\u0430\u0437\u044b \u0414\u0430\u043d\u043d\u044b\u0445\u00bb. \u0418\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0434\u0430\u043d\u043d\u043e\u043c \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0438? \u041f\u0440\u0438\u0433\u043b\u0430\u0448\u0430\u0435\u043c \u0432\u0430\u0441 \u043d\u0430 \u0414\u0435\u043d\u044c \u041e\u0442\u043a\u0440\u044b\u0442\u044b\u0445 \u0414\u0432\u0435\u0440\u0435\u0439, \u0433\u0434\u0435 \u043c\u044b \u043f\u043e\u0434\u0440\u043e\u0431\u043d\u043e \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u043e \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0435, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u044f\u0445 \u043e\u043d\u043b\u0430\u0439\u043d-\u0444\u043e\u0440\u043c\u0430\u0442\u0430, \u043a\u043e\u043c\u043f\u0435\u0442\u0435\u043d\u0446\u0438\u044f\u0445 \u0438 \u043a\u0430\u0440\u044c\u0435\u0440\u043d\u044b\u0445 \u043f\u0435\u0440\u0441\u043f\u0435\u043a\u0442\u0438\u0432\u0430\u0445, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0436\u0434\u0443\u0442 \u0432\u044b\u043f\u0443\u0441\u043a\u043d\u0438\u043a\u043e\u0432 \u043f\u043e\u0441\u043b\u0435 \u043e\u0431\u0443\u0447\u0435\u043d\u0438\u044f. PostgreSQL \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u043b\u044f \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u0433\u043e \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f \u041d\u0430\u043c \u0432 Compose \u043f\u0440\u0438\u0445\u043e\u0434\u0438\u0442\u0441\u044f \u0438\u043c\u0435\u0442\u044c \u0434\u0435\u043b\u043e \u0441\u043e \u043c\u043d\u043e\u0433\u0438\u043c\u0438 \u0431\u0430\u0437\u0430\u043c\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29395,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-39169","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\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\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47PostgreSQL e impostazioni di coerenza della scrittura per ogni singola connessione | ProHoster","description":"La traduzione dell'articolo \u00e8 stata preparata specificamente per gli studenti del corso \"Database\". Sei interessato a svilupparti in questa direzione?","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\udd47PostgreSQL \u0438 \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0438 \u0441\u043e\u0433\u043b\u0430\u0441\u043e\u0432\u0430\u043d\u043d\u043e\u0441\u0442\u0438 \u0437\u0430\u043f\u0438\u0441\u0438 \u0434\u043b\u044f \u043a\u0430\u0436\u0434\u043e\u0433\u043e \u043a\u043e\u043d\u043a\u0440\u0435\u0442\u043d\u043e\u0433\u043e \u0441\u043e\u0435\u0434\u0438\u043d\u0435\u043d\u0438\u044f | ProHoster","og:description":"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043a\u0443\u0440\u0441\u0430 \u00ab\u0411\u0430\u0437\u044b \u0414\u0430\u043d\u043d\u044b\u0445\u00bb. \u0418\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e \u0440\u0430\u0437\u0432\u0438\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0434\u0430\u043d\u043d\u043e\u043c \u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u0438?","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/postgresql-i-nastrojki-soglasovannosti-zapisi-dlya-kazhdogo-konkretnogo-soedineniya","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:28:14+00:00","article:modified_time":"2019-10-31T19:28:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"39169","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-24 01:05:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:54:44","updated":"2026-01-24 01:05:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39169","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=39169"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/39169\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/29395"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=39169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=39169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=39169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}