{"id":41081,"date":"2020-02-05T21:30:11","date_gmt":"2020-02-05T18:30:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle"},"modified":"2020-02-05T21:30:11","modified_gmt":"2020-02-05T18:30:11","slug":"cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","title":{"rendered":"Cassandra. Come non morire se conosci solo Oracle","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr.<\/p>\n

Mi chiamo Misha Butrimov e vorrei raccontarvi un po 'di Cassandra. La mia storia sar\u00e0 utile a chi non ha mai avuto esperienza con database NoSQL, poich\u00e9 presenta molte peculiarit\u00e0 di implementazione e insidie di cui \u00e8 importante essere a conoscenza. E se oltre a Oracle o a qualsiasi altro database relazionale non avete mai visto altro, queste informazioni vi salveranno la vita.<\/p>\n

Cosa rende Cassandra cos\u00ec valida? \u00c8 un database NoSQL progettato senza un singolo punto di guasto, che scala bene. Se hai bisogno di aggiungere qualche terabyte a un database, basta aggiungere nodi nel ring. Vuoi espanderlo in un altro data center? Aggiungi nodi al cluster. Vuoi aumentare i RPS elaborati? Aggiungi nodi al cluster. Funziona anche al contrario. <\/p>\n

\"Cassandra.<\/a><\/noindex><\/p>\n

In cosa \u00e8 ancora efficace? Nel gestire molte richieste. Ma quanto \u00e8 molto? 10.000, 20.000, 30.000, 40.000 richieste al secondo \u00e8 un numero relativamente basso. 100.000 richieste al secondo in scrittura \u00e8 anche poco. Ci sono aziende che sostengono di gestire 2 milioni di richieste al secondo. A loro, probabilmente, bisogner\u00e0 credere. <\/p>\n

In linea di massima, Cassandra ha una grande differenza rispetto ai dati relazionali: non li assomiglia affatto. \u00c8 molto importante tenerlo a mente.
\n<\/a><\/noindex><\/p>\n

Non tutto ci\u00f2 che appare uguale funziona allo stesso modo.<\/h2>\n

\nUn giorno un collega \u00e8 venuto da me e ha chiesto: \u00abEcco il linguaggio di query SQL di Cassandra, e c'\u00e8 la select statement, c'\u00e8 il where e c'\u00e8 l'and. Scrivo le lettere e non funziona. Perch\u00e9?\u00bb. Se si considera Cassandra come un database relazionale, \u00e8 il modo ideale per concludere in un autolesionismo violento. E non sto promuovendo, \u00e8 vietato in Russia. Stai solo progettando qualcosa di sbagliato.<\/p>\n

Ad esempio, un cliente viene da noi e dice: \u00abCostruiamo un database per serie TV, oppure un database per un ricettario. Avremo piatti con ingredienti o un elenco di serie TV e attori\u00bb. Noi rispondiamo con entusiasmo: \u00abFacciamo cos\u00ec!\u00bb. \u00c8 solo questione di inviare un paio di byte, alcune tabelle e tutto \u00e8 pronto, funzioner\u00e0 molto velocemente e in modo affidabile. E tutto va bene finch\u00e9 i clienti non arrivano e dicono che le casalinghe risolvono anche il problema inverso: hanno un elenco di ingredienti e vogliono sapere quale piatto vogliono preparare. Sei finito.<\/p>\n

Tutto perch\u00e9 Cassandra \u00e8 un database ibrido: \u00e8 sia chiave-valore che memorizza dati in colonne larghe. Parlando il linguaggio Java o Kotlin, si potrebbe descrivere cos\u00ec:<\/p>\n

Map<RowKey, SortedMap><\/code><\/p>\n

Cio\u00e8 una mappa, che contiene anche una mappa ordinata. La prima chiave di questa mappa \u00e8 la Row key o Partition key \u2014 la chiave di partizionamento. La seconda chiave, che \u00e8 la chiave per la mappa gi\u00e0 ordinata, \u00e8 la Clustering key.<\/p>\n

Per illustrare la distribuzione del database, disegniamo tre nodi. Ora dobbiamo capire come distribuire i dati tra i nodi. Perch\u00e9 se mettiamo tutto in uno (ce ne possono essere mille, duemila, cinque \u2014 quanti ne vogliamo), questo non \u00e8 proprio distribuzione. Pertanto, abbiamo bisogno di una funzione matematica che restituisca un numero. Semplicemente un numero, un int lungo, che rientri in un certo intervallo. E un nodo risponder\u00e0 a un determinato intervallo, il secondo a un altro, e cos\u00ec via. <\/p>\n

\"Cassandra.
\n
\nQuesto numero viene ottenuto tramite una funzione hash, che viene applicata esattamente a ci\u00f2 che chiamiamo la chiave di partizione. Questo \u00e8 il campo specificato nella direttiva della chiave primaria ed \u00e8 il campo che sar\u00e0 la prima e principale chiave nella mappa. Definisce su quale nodo i dati andranno. La tabella viene creata in Cassandra con una sintassi quasi identica a quella di SQL: <\/p>\n

CREATE TABLE users (\n\tuser_id uu id,\n\tname text,\n\tyear int,\n\tsalary float,\n\tPRIMARY KEY(user_id)\n\n)\n<\/code><\/pre>\n
La chiave primaria in questo caso consiste in una sola colonna, che \u00e8 anche la chiave di partizione.<\/p>\n
Come verranno distribuiti gli utenti? Parte andr\u00e0 su un nodo, parte su un altro e parte su un terzo. Si ottiene una normale tabella hash, che \u00e8 anche una mappa, che in Python \u00e8 un dizionario, ed \u00e8 una semplice struttura chiave-valore da cui possiamo leggere tutti i valori, leggere e scrivere per chiave.<\/p>\n
\"Cassandra.
\n<\/p>\n
Select: quando allow filtering si trasforma in full scan, o come non bisogna fare<\/h2>\n
\nScriviamo qualche selezione: select * from users where userid = <\/code>. Sembra proprio come in Oracle: scriviamo select, indichiamo le condizioni e tutto funziona, gli utenti vengono estratti. Ma se scegliamo, ad esempio, un utente con un anno di nascita specifico, Cassandra si lamenta di non poter eseguire la query. Perch\u00e9 non sa assolutamente nulla su come sono distribuiti i dati relativi all'anno di nascita \u2014 ha solo una colonna specificata come chiave. A questo punto dice: \u00abVa bene, posso comunque eseguire questa query. Aggiungi allow filtering\u00bb. Aggiungiamo la direttiva e tutto funziona. E in quel momento succede l'inevitabile. <\/p>\n
Quando eseguiamo test con dati di esempio, tutto va bene. Ma quando si esegue una query in produzione, dove abbiamo, ad esempio, 4 milioni di registrazioni, la situazione non \u00e8 cos\u00ec bella. Perch\u00e9 allow filtering \u00e8 una direttiva che consente a Cassandra di raccogliere tutti i dati da questa tabella da tutti i nodi, di data center<\/a> (se ce ne sono molti in questo cluster), e solo dopo filtrarli. \u00c8 analogo a un Full Scan, e difficilmente qualcuno ne sar\u00e0 entusiasta. <\/p>\n
Se avessimo bisogno di utenti solo per identificatori, ci andrebbe bene. Ma a volte dobbiamo scrivere altre query e applicare altre restrizioni sul campione. Pertanto, ricordiamo: questa \u00e8 tutta una mappa, che ha una chiave di partizionamento, ma al suo interno c'\u00e8 una mappa ordinata. <\/p>\n
E anche essa ha una chiave, che chiamiamo Clustering Key. Questa chiave, a sua volta, \u00e8 composta da colonne che sceglieremo e tramite la quale Cassandra comprende come i dati siano fisicamente ordinati e resi disponibili su ogni nodo. Quindi, per un certo Partition key, il Clustering key dir\u00e0 come inserire i dati in questo albero e quale posto occuperanno.<\/p>\n
\u00c8 davvero un albero, viene semplicemente chiamato un comparatore a cui passiamo un certo insieme di colonne come oggetto, e viene definito anche questo come un insieme di colonne. <\/p>\n
CREATE TABLE users_by_year_salary_id (\n\tuser_id uuid,\n\tname text,\n\tyear int,\n\tsalary float,\n\tPRIMARY KEY((year), salary, user_id)\n<\/code><\/pre>\n
Si prega di notare la direttiva Primary key, il cui primo argomento (nel nostro caso l'anno) \u00e8 sempre la Partition key. Pu\u00f2 consistere in una o pi\u00f9 colonne, non importa. Se ci sono pi\u00f9 colonne, deve essere messo di nuovo tra parentesi affinch\u00e9 il preprocessore del linguaggio capisca che si tratta di una Primary key, seguita da tutte le altre colonne \u2014 Clustering key. Queste ultime verranno quindi passate nel comparatore nell'ordine in cui compaiono. Cio\u00e8, la prima colonna \u00e8 pi\u00f9 significativa, la seconda \u00e8 meno significativa e cos\u00ec via. Come scriviamo per le classi di dati, ad esempio, campi equals: elenchiamo i campi e specifichiamo quali sono pi\u00f9 importanti e quali meno. In Cassandra, sono, per cos\u00ec dire, i campi della data class, a cui si applicher\u00e0 l'equals scritto per essa.<\/p>\n
Imponiamo l'ordinamento, imponiamo restrizioni<\/h2>\n
\n\u00c8 importante ricordare che l'ordine di ordinamento (decrescente, crescente, non importa) \u00e8 definito nel momento stesso in cui viene creato la chiave, e non potr\u00e0 essere modificato successivamente. Essa determina fisicamente come saranno ordinati i dati e come si disporranno. Se si rende necessario modificare la Clustering key o l'ordine di ordinamento, sar\u00e0 necessario creare una nuova tabella e trasferirvi i dati. Non sar\u00e0 possibile farlo con una tabella esistente.<\/p>\n
\"Cassandra.
\n
\nAbbiamo popolato la nostra tabella con gli utenti e abbiamo notato che sono stati disposti in anello prima per anno di nascita, e poi all'interno di ogni nodo per stipendio e per ID utente. Ora possiamo selezionare, imponendo delle restrizioni. <\/p>\n
Riparte nuovamente il nostro funzionante where, and<\/code>, e gli utenti ci vengono forniti, e tutto va di nuovo bene. Ma se proviamo a utilizzare solo una parte della Clustering key, e per di pi\u00f9 quella meno significativa, Cassandra subito si lamenter\u00e0, dicendo che non pu\u00f2 trovare nella nostra mappa un posto dove questo oggetto, il cui campo per il comparatore \u00e8 null, si trova, e dove \u00e8 collocato quello che abbiamo appena definito. Dovr\u00f2 sollevare nuovamente tutti i dati da questo nodo e filtrare. E questo \u00e8 analogo a una Full Scan all'interno del nodo, ed \u00e8 un problema.<\/p>\n
In qualsiasi situazione incerta, crea una nuova tabella.<\/h2>\n
\nSe vogliamo essere in grado di recuperare gli utenti per ID, et\u00e0 o stipendio, cosa fare? Niente. Basta utilizzare due tabelle. Se sar\u00e0 necessario recuperare gli utenti in tre modi diversi, le tabelle saranno tre. Sono finiti i tempi in cui risparmiavamo spazio su disco. Questo \u00e8 il pi\u00f9 economico delle risorse. Costa molto meno del tempo di risposta, che pu\u00f2 essere letale per l'utente. \u00c8 molto pi\u00f9 piacevole per l'utente ricevere qualcosa in un secondo piuttosto che in 10 minuti.<\/p>\n
Scambiamo lo spazio occupato in eccesso e i dati denormalizzati con la possibilit\u00e0 di scalare bene e di funzionare in modo affidabile. Infatti, un cluster composto da tre datacenter, ognuno con cinque nodi, in grado di garantire un livello accettabile di integrit\u00e0 dei dati (dove niente va perso), pu\u00f2 sopravvivere alla perdita totale di un datacenter. E ancora, ci sono due nodi in ciascuno dei due datacenter rimanenti. Solo dopo ci\u00f2 iniziano i problemi. Questo \u00e8 un buon livello di ridondanza, che richiede solo un paio di SSD extra e processori. Pertanto, per utilizzare Cassandra, che non \u00e8 SQL e non prevede relazioni n\u00e9 chiavi esterne, \u00e8 necessario conoscere alcune regole semplici.<\/p>\n
Progettiamo tutto partendo dalla richiesta. Non sono i dati ad avere importanza, ma il modo in cui l'applicazione interagir\u00e0 con essi. Se ha bisogno di recuperare dati diversi in modi diversi o gli stessi dati in modi differenti, dobbiamo organizzarli in modo che siano comodi per l'applicazione. Altrimenti, finiremo per eseguire un Full Scan e Cassandra non ci porter\u00e0 alcun vantaggio.<\/p>\n
Denormalizzare i dati \u00e8 la norma. Dimentichiamo le forme normali, non abbiamo pi\u00f9 database relazionali. Metteremo qualcosa 100 volte, e questo sar\u00e0 presente 100 volte. \u00c8 comunque pi\u00f9 economico che rallentare. <\/p>\n
Selezioniamo le chiavi per il partizionamento in modo che siano distribuite uniformemente. Non vogliamo che l'hash delle nostre chiavi cada in un intervallo ristretto. Ad esempio, l'anno di nascita nella precedente discussione \u00e8 un cattivo esempio. In effetti, \u00e8 un buon esempio se i nostri utenti sono distribuiti benissimo per anno di nascita, ed \u00e8 un cattivo esempio se si tratta di alunni di quinta elementare\u2014l\u00ec non sar\u00e0 molto efficace il partizionamento. <\/p>\n
La sortazione viene scelta una sola volta durante la creazione della Clustering Key. Se deve essere modificata, allora dovremo riversare la nostra tabella con un'altra chiave.<\/p>\n
E la cosa pi\u00f9 importante: se abbiamo bisogno di recuperare gli stessi dati in 100 modi diversi, avremo 100 tabelle diverse.
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440. \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0438\u0448\u0430 \u0411\u0443\u0442\u0440\u0438\u043c\u043e\u0432, \u044f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0445\u043e\u0442\u0435\u043b \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e Cassandra. \u041c\u043e\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043b\u0435\u0437\u0435\u043d \u0442\u0435\u043c, \u043a\u0442\u043e \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u043b\u0441\u044f \u0441 NoSQL-\u0431\u0430\u0437\u0430\u043c\u0438, \u2014 \u0443 \u043d\u0435\u0435 \u0435\u0441\u0442\u044c \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0435\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u0438 \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0445 \u043a\u0430\u043c\u043d\u0435\u0439, \u043f\u0440\u043e \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0443\u0436\u043d\u043e \u0437\u043d\u0430\u0442\u044c. \u0418 \u0435\u0441\u043b\u0438 \u043a\u0440\u043e\u043c\u0435 Oracle \u0438\u043b\u0438 \u043b\u044e\u0431\u043e\u0439 \u0434\u0440\u0443\u0433\u043e\u0439 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0431\u0430\u0437\u044b \u0432\u044b \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u0432\u0438\u0434\u0435\u043b\u0438, \u044d\u0442\u0438 \u0432\u0435\u0449\u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":41082,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[10],"tags":[],"class_list":["post-41081","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"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\udd47Cassandra. Come non morire se conosci solo Oracle | ProHoster","description":"Ciao, Habr. Mi chiamo Misha Butrimov e vorrei raccontarvi un po' di Cassandra. La mia presentazione sar\u00e0 utile per chi non ha mai avuto a che fare con database NoSQL, poich\u00e9 ha molte peculiarit\u00e0 di implementazione e insidie di cui \u00e8 importante essere a conoscenza. Se non hai mai visto nulla al di fuori di Oracle o di un altro database relazionale, queste cose","canonical_url":"https:\/\/prohoster.info\/it\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","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\udd47Cassandra. \u041a\u0430\u043a \u043d\u0435 \u0443\u043c\u0435\u0440\u0435\u0442\u044c, \u0435\u0441\u043b\u0438 \u0437\u043d\u0430\u0435\u0448\u044c \u0442\u043e\u043b\u044c\u043a\u043e Oracle | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440. \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041c\u0438\u0448\u0430 \u0411\u0443\u0442\u0440\u0438\u043c\u043e\u0432, \u044f \u0445\u043e\u0442\u0435\u043b \u0431\u044b \u0445\u043e\u0442\u0435\u043b \u043d\u0435\u043c\u043d\u043e\u0433\u043e \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u0442\u044c \u043f\u0440\u043e Cassandra. \u041c\u043e\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0437 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043b\u0435\u0437\u0435\u043d \u0442\u0435\u043c, \u043a\u0442\u043e \u043d\u0438\u043a\u043e\u0433\u0434\u0430 \u043d\u0435 \u0441\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u043b\u0441\u044f \u0441 NoSQL-\u0431\u0430\u0437\u0430\u043c\u0438, \u2014 \u0443 \u043d\u0435\u0435 \u0435\u0441\u0442\u044c \u043e\u0447\u0435\u043d\u044c \u043c\u043d\u043e\u0433\u043e \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0435\u0439 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u0438 \u0438 \u043f\u043e\u0434\u0432\u043e\u0434\u043d\u044b\u0445 \u043a\u0430\u043c\u043d\u0435\u0439, \u043f\u0440\u043e \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043d\u0443\u0436\u043d\u043e \u0437\u043d\u0430\u0442\u044c. \u0418 \u0435\u0441\u043b\u0438 \u043a\u0440\u043e\u043c\u0435 Oracle \u0438\u043b\u0438 \u043b\u044e\u0431\u043e\u0439 \u0434\u0440\u0443\u0433\u043e\u0439 \u0440\u0435\u043b\u044f\u0446\u0438\u043e\u043d\u043d\u043e\u0439 \u0431\u0430\u0437\u044b \u0432\u044b \u043d\u0438\u0447\u0435\u0433\u043e \u043d\u0435 \u0432\u0438\u0434\u0435\u043b\u0438, \u044d\u0442\u0438 \u0432\u0435\u0449\u0438","og:url":"https:\/\/prohoster.info\/it\/blog\/cassandra-kak-ne-umeret-esli-znaesh-tolko-oracle","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-02-05T18:30:11+00:00","article:modified_time":"2020-02-05T18:30:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"41081","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-03-01 00:24:40","updated":"2022-09-30 11:42:25"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/41081","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=41081"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/41081\/revisions"}],"predecessor-version":[{"id":164523,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/41081\/revisions\/164523"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/41082"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=41081"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=41081"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=41081"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}