{"id":34419,"date":"2019-10-31T21:58:13","date_gmt":"2019-10-31T18:58:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql\/"},"modified":"2019-10-31T21:58:13","modified_gmt":"2019-10-31T18:58:13","slug":"ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Utilizziamo tutte le possibilit\u00e0 degli indici in PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Utilizziamo
\nNel mondo di Postgres, gli indici sono estremamente importanti per una navigazione efficace nel database (denominato \u00abheap\u00bb). Postgres non supporta la clustering per questo, e l'architettura MVCC porta ad accumulare molte versioni dello stesso tuple. Pertanto, \u00e8 fondamentale saper creare e mantenere indici efficienti a supporto delle applicazioni.<\/p>\n

Vi propongo alcuni consigli per l'ottimizzazione e il miglior utilizzo degli indici.<\/p>\n

Nota: le query mostrate di seguito funzionano su un esempio di database pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Utilizzo degli indici coprenti (Covering Indexes)<\/h3>\n

\nDiamo un'occhiata a una query per estrarre indirizzi email per utenti inattivi. Nella tabella customer<\/code> c'\u00e8 la colonna active<\/code>, e la query risulta abbastanza semplice:<\/p>\n

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                        QUERY PLAN\n-----------------------------------------------------------\n Seq Scan on customer  (cost=0.00..16.49 rows=15 width=32)\n   Filter: (active = 0)\n(2 rows)<\/code><\/pre>\n
\nLa query comporta una scansione sequenziale completa della tabella customer<\/code>. Creiamo un indice sulla colonna active<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_cust1 ON customer(active);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                 QUERY PLAN\n-----------------------------------------------------------------------------\n Index Scan using idx_cust1 on customer  (cost=0.28..12.29 rows=15 width=32)\n   Index Cond: (active = 0)\n(2 rows)<\/code><\/pre>\n
\nHa aiutato, la scansione successiva \u00e8 diventata «index scan<\/code>«. Questo significa che Postgres scansioner\u00e0 l'indice «idx_cust1<\/code>«, e poi continuer\u00e0 a cercare nel heap della tabella per leggere i valori di altre colonne (in questo caso, la colonna email<\/code>), necessaria alla query.<\/p>\n
Nella versione 11 di PostgreSQL sono stati introdotti gli indici coprenti. Questi consentono di includere nell'indice una o pi\u00f9 colonne aggiuntive \u2014 i loro valori vengono memorizzati nel deposito dati dell'indice.<\/p>\n
Se avessimo utilizzato questa funzionalit\u00e0 e aggiunto il valore dell'email all'interno dell'indice, Postgres non avrebbe bisogno di cercare nella heap della tabella il valore email<\/code>. Vediamo se funziona:<\/p>\n
pagila=# CREATE INDEX idx_cust2 ON customer(active) INCLUDE (email);\nCREATE INDEX\npagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                                    QUERY PLAN\n----------------------------------------------------------------------------------\n Index Only Scan using idx_cust2 on customer  (cost=0.28..12.29 rows=15 width=32)\n   Index Cond: (active = 0)\n(2 rows)<\/code><\/pre>\n
\n\u00abIndex Only Scan<\/code>» ci dice che ora la richiesta pu\u00f2 essere soddisfatta solo con l'indice, evitando tutte le operazioni di I\/O su disco per leggere il heap della tabella.<\/p>\n
Oggi gli indici coprenti sono disponibili solo per gli alberi B. Tuttavia, in questo caso, gli sforzi per la manutenzione saranno maggiori.<\/p>\n
Utilizzo di indici parziali<\/h3>\n
\nGli indici parziali indicizzano solo un sottoinsieme delle righe della tabella. Questo consente di risparmiare spazio sugli indici e di eseguire scansioni pi\u00f9 rapidamente.<\/p>\n
Supponiamo che dobbiamo ottenere un elenco degli indirizzi email dei nostri clienti della California. La query sar\u00e0:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nche ha un piano di query che prevede la scansione di entrambe le tabelle unite:\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                              QUERY PLAN\n----------------------------------------------------------------------\n Hash Join  (cost=15.65..32.22 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=15.54..15.54 rows=9 width=4)\n         ->  Seq Scan on address a  (cost=0.00..15.54 rows=9 width=4)\n               Filter: (district = 'California'::text)\n(6 rows)<\/code><\/pre>\n
\nCosa ci daranno gli indici normali:<\/p>\n
pagila=# CREATE INDEX idx_address1 ON address(district);\nCREATE INDEX\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                                      QUERY PLAN\n---------------------------------------------------------------------------------------\n Hash Join  (cost=12.98..29.55 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=12.87..12.87 rows=9 width=4)\n         ->  Bitmap Heap Scan on address a  (cost=4.34..12.87 rows=9 width=4)\n               Recheck Cond: (district = 'California'::text)\n               ->  Bitmap Index Scan on idx_address1  (cost=0.00..4.34 rows=9 width=0)\n                     Index Cond: (district = 'California'::text)\n(8 rows)<\/code><\/pre>\n
\nScansione address<\/code> \u00e8 stata sostituita dalla scansione dell'indice idx_address1<\/code>, e poi \u00e8 stata scansionata l'heap address<\/code>.<\/p>\n
Poich\u00e9 questa \u00e8 una query frequente e deve essere ottimizzata, possiamo utilizzare un indice parziale che indicizza solo quelle righe con indirizzi in cui il distretto \u2018California\u2019<\/code>:<\/p>\n
pagila=# CREATE INDEX idx_address2 ON address(address_id) WHERE district='California';\nCREATE INDEX\npagila=# EXPLAIN SELECT c.email FROM customer c\npagila-# JOIN address a ON c.address_id = a.address_id\npagila-# WHERE a.district = 'California';\n                                           QUERY PLAN\n------------------------------------------------------------------------------------------------\n Hash Join  (cost=12.38..28.96 rows=9 width=32)\n   Hash Cond: (c.address_id = a.address_id)\n   ->  Seq Scan on customer c  (cost=0.00..14.99 rows=599 width=34)\n   ->  Hash  (cost=12.27..12.27 rows=9 width=4)\n         ->  Index Only Scan using idx_address2 on address a  (cost=0.14..12.27 rows=9 width=4)\n(5 rows)<\/code><\/pre>\n
\nOra la query legge solo idx_address2<\/code> e non tocca la tabella address<\/code>.<\/p>\n
Utilizzo di indici multivalore (Multi-Value Indexes)<\/h3>\n
\nAlcune colonne da indicizzare potrebbero non contenere un tipo di dato scalare. Tipi di colonne come jsonb<\/code>, arrays<\/code> e tsvector<\/code> possono contenere valori composti o multipli. Se devi indicizzare colonne di questo tipo, di solito \u00e8 necessario cercare in tutti i singoli valori di queste colonne.<\/p>\n
Proviamo a trovare i titoli di tutti i film che contengono tagli di doppiaggi non riusciti. Nella tabella film<\/code> c'\u00e8 una colonna di testo chiamata special_features<\/code>. Se un film ha questa \u00abcaratteristica speciale\u00bb, allora nella colonna \u00e8 presente un elemento sotto forma di array di testo Behind The Scenes<\/code>. Per trovare tutti questi film dobbiamo selezionare tutte le righe con \u00abBehind The Scenes\u00bb in qualsiasi <\/b>valore dell'array special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nL'operatore di contenimento @><\/code> verifica se la parte destra \u00e8 un sottoinsieme della parte sinistra.<\/p>\n
Piano della query:<\/p>\n
pagila=# EXPLAIN SELECT title FROM film\npagila-# WHERE special_features @> '{\"Behind The Scenes\"}';\n                           QUERY PLAN\n-----------------------------------------------------------------\n Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)\n   Filter: (special_features @> '{\"Behind The Scenes\"}'::text[])\n(2 rows)<\/code><\/pre>\n
\nChe richiede una scansione completa del heap a un costo di 67.<\/p>\n
Vediamo se un indice B-tree ci pu\u00f2 aiutare:<\/p>\n
pagila=# CREATE INDEX idx_film1 ON film(special_features);\nCREATE INDEX\npagila=# EXPLAIN SELECT title FROM film\npagila-# WHERE special_features @> '{\"Behind The Scenes\"}';\n                           QUERY PLAN\n-----------------------------------------------------------------\n Seq Scan on film  (cost=0.00..67.50 rows=5 width=15)\n   Filter: (special_features @> '{\"Behind The Scenes\"}'::text[])\n(2 rows)<\/code><\/pre>\n
\nL'indice non \u00e8 stato nemmeno considerato. L'indice B-tree non si accorge dell'esistenza di singoli elementi nei valori indicizzati.<\/p>\n
Abbiamo bisogno di un indice GIN.<\/p>\n
pagila=# CREATE INDEX idx_film2 ON film USING GIN(special_features);\nCREATE INDEX\npagila=# EXPLAIN SELECT title FROM film\npagila-# WHERE special_features @> '{\"Behind The Scenes\"}';\n                                QUERY PLAN\n---------------------------------------------------------------------------\n Bitmap Heap Scan on film  (cost=8.04..23.58 rows=5 width=15)\n   Recheck Cond: (special_features @> '{\"Behind The Scenes\"}'::text[])\n   ->  Bitmap Index Scan on idx_film2  (cost=0.00..8.04 rows=5 width=0)\n         Index Cond: (special_features @> '{\"Behind The Scenes\"}'::text[])\n(4 rows)<\/code><\/pre>\n
\nL'indice GIN supporta il confronto di singoli valori con valori composti indicizzati, quindi il costo del piano di query diminuir\u00e0 di pi\u00f9 della met\u00e0.<\/p>\n
Eliminiamo la duplicazione degli indici.<\/h3>\n
\nGli indici si accumulano nel tempo e a volte un nuovo indice pu\u00f2 contenere la stessa definizione di uno dei precedenti. Per ottenere definizioni di indici in formato leggibile per l'uomo, \u00e8 possibile utilizzare la vista del catalogo pg_indexes<\/code>. Sar\u00e0 inoltre facile trovare definizioni duplicate:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nEcco il risultato quando eseguito sul database pagila di esempio:\npagila=#   SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\npagila-#     FROM pg_indexes\npagila-# GROUP BY defn\npagila-#   HAVING count(*) > 1;\n                                indexes                                 |                                defn\n------------------------------------------------------------------------+------------------------------------------------------------------\n {payment_p2017_01_customer_id_idx,idx_fk_payment_p2017_01_customer_id} | CREATE INDEX  ON public.payment_p2017_01 USING btree (customer_id\n {payment_p2017_02_customer_id_idx,idx_fk_payment_p2017_02_customer_id} | CREATE INDEX  ON public.payment_p2017_02 USING btree (customer_id\n {payment_p2017_03_customer_id_idx,idx_fk_payment_p2017_03_customer_id} | CREATE INDEX  ON public.payment_p2017_03 USING btree (customer_id\n {idx_fk_payment_p2017_04_customer_id,payment_p2017_04_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_04 USING btree (customer_id\n {payment_p2017_05_customer_id_idx,idx_fk_payment_p2017_05_customer_id} | CREATE INDEX  ON public.payment_p2017_05 USING btree (customer_id\n {idx_fk_payment_p2017_06_customer_id,payment_p2017_06_customer_id_idx} | CREATE INDEX  ON public.payment_p2017_06 USING btree (customer_id\n(6 righe)\n<\/code><\/pre>\n
<\/p>\n
Indici di sovraccarico (Superset Indexes)<\/h3>\n
\nPotrebbe succedere che accumuliate molti indici, uno dei quali indicizza un insieme di colonne che sono indicizzate da altri indici. Questo pu\u00f2 essere sia desiderabile che non \u2014 un sovraccarico pu\u00f2 portare a scansionare solo tramite indici, il che \u00e8 positivo, ma pu\u00f2 anche occupare troppo spazio, oppure la query per cui \u00e8 stato creato questo sovraccarico non \u00e8 pi\u00f9 utilizzata.<\/p>\n
Se avete bisogno di automatizzare la definizione di tali indici, potete iniziare da pg_index<\/a><\/noindex> dalla tabella pg_catalog<\/code>.<\/p>\n
Indici non utilizzati<\/h3>\n
\nCon lo sviluppo delle applicazioni che utilizzano database, si sviluppano anche le query utilizzate. Gli indici aggiunti in precedenza potrebbero non essere pi\u00f9 utilizzati da alcuna query. Ogni volta che viene eseguita una scansione dell'indice, viene registrato dal gestore delle statistiche, e nella vista del catalogo di sistema pg_stat_user_indexes<\/code> \u00e8 possibile vedere il valore idx_scan<\/code>, che funge da contatore cumulativo. Monitorare questo valore nel tempo (diciamo, un mese) fornir\u00e0 una buona idea di quali indici non vengono utilizzati e possono essere rimossi.<\/p>\n
Ecco una query per ottenere i contatori di scansione attuali di tutti gli indici nello schema 'public'<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\ncon un output come questo:\npagila=# SELECT relname, indexrelname, idx_scan\npagila-# FROM   pg_catalog.pg_stat_user_indexes\npagila-# WHERE  schemaname = 'public'\npagila-# LIMIT  10;\n    relname    |    indexrelname    | idx_scan\n---------------+--------------------+----------\n customer      | customer_pkey      |    32093\n actor         | actor_pkey         |     5462\n address       | address_pkey       |      660\n category      | category_pkey      |     1000\n city          | city_pkey          |      609\n country       | country_pkey       |      604\n film_actor    | film_actor_pkey    |        0\n film_category | film_category_pkey |        0\n film          | film_pkey          |    11043\n inventory     | inventory_pkey     |    16048\n(10 righe)<\/code><\/pre>\n
<\/p>\n
Ricreazione degli indici con meno blocchi<\/h3>\n
\nSpesso gli indici devono essere ricreati, ad esempio, quando aumentano di dimensioni, e la ricreazione pu\u00f2 accelerare la scansione. Inoltre, gli indici possono danneggiarsi. La modifica delle impostazioni dell'indice pu\u00f2 anche richiedere la sua ricreazione.<\/p>\n
Abilitiamo la creazione parallela degli indici<\/h3>\n
\nIn PostgreSQL 11, la creazione di un indice B-Tree \u00e8 concorrente. Pu\u00f2 essere utilizzato pi\u00f9 lavoratori che lavorano in parallelo per velocizzare il processo di creazione. Tuttavia, assicurati che queste impostazioni siano configurate correttamente:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nI valori predefiniti sono troppo bassi. Idealmente, questi numeri dovrebbero essere aumentati insieme al numero di core del processore. Leggi di pi\u00f9 in documentazione<\/a><\/noindex>.<\/p>\n
Creazione di indici in background<\/h3>\n
\nPuoi creare un indice in background utilizzando l'impostazione CONCURRENTLY<\/code> comandi CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Questa procedura di creazione dell'indice si differenzia dalla normale perch\u00e9 non richiede il blocco della tabella, il che significa che non blocca le operazioni di scrittura. D'altra parte, richiede pi\u00f9 tempo e consuma pi\u00f9 risorse.<\/p>\n
Postgres offre molte possibilit\u00e0 flessibili per la creazione di indici e modi per affrontare eventuali casi particolari, oltre a fornire strumenti per gestire il database nel caso di una crescita esplosiva della tua applicazione. Ci auguriamo che questi suggerimenti ti aiutino a rendere le tue query veloci e il database pronto a scalare.
\n
Fonte: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412 \u043c\u0438\u0440\u0435 Postgres \u0438\u043d\u0434\u0435\u043a\u0441\u044b \u043a\u0440\u0430\u0439\u043d\u0435 \u0432\u0430\u0436\u043d\u044b \u0434\u043b\u044f \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u043d\u0430\u0432\u0438\u0433\u0430\u0446\u0438\u0438 \u043f\u043e \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0443 \u0431\u0430\u0437\u044b \u0434\u0430\u043d\u043d\u044b\u0445 (\u0435\u0433\u043e \u043d\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u00ab\u043a\u0443\u0447\u0430\u00bb, heap). Postgres \u043d\u0435 \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u0438\u0432\u0430\u0435\u0442 \u0434\u043b\u044f \u043d\u0435\u0433\u043e \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0438\u0437\u0430\u0446\u0438\u044e, \u0438 \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u0430 MVCC \u043f\u0440\u0438\u0432\u043e\u0434\u0438\u0442 \u043a \u0442\u043e\u043c\u0443, \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u043d\u0430\u043a\u0430\u043f\u043b\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u043c\u043d\u043e\u0433\u043e \u0432\u0435\u0440\u0441\u0438\u0439 \u043e\u0434\u043d\u043e\u0433\u043e \u0438 \u0442\u043e\u0433\u043e \u0436\u0435 \u043a\u043e\u0440\u0442\u0435\u0436\u0430. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043e\u0447\u0435\u043d\u044c \u0432\u0430\u0436\u043d\u043e \u0443\u043c\u0435\u0442\u044c \u0441\u043e\u0437\u0434\u0430\u0432\u0430\u0442\u044c \u0438 \u0441\u043e\u043f\u0440\u043e\u0432\u043e\u0436\u0434\u0430\u0442\u044c \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u044b\u0435 \u0438\u043d\u0434\u0435\u043a\u0441\u044b \u0434\u043b\u044f \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439. \u041f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u044e \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":25931,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34419","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\udd47Sfruttiamo tutte le potenzialit\u00e0 degli indici in PostgreSQL | ProHoster","description":"Nel mondo di Postgres, gli indici sono estremamente importanti per.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","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\udd47\u0418\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u043c \u0432\u0441\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438\u043d\u0434\u0435\u043a\u0441\u043e\u0432 \u0432 PostgreSQL | ProHoster","og:description":"\u0412 \u043c\u0438\u0440\u0435 Postgres \u0438\u043d\u0434\u0435\u043a\u0441\u044b \u043a\u0440\u0430\u0439\u043d\u0435 \u0432\u0430\u0436\u043d\u044b \u0434\u043b\u044f.","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","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-31T18:58:13+00:00","article:modified_time":"2019-10-31T18:58:13+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34419","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-21 19:13:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 13:52:22","updated":"2026-01-21 19:13:20","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\/34419","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=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}