{"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\/no\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Vi utnytter alle muligheter med indekser i PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Vi
\nI Postgres-verden er indekser ekstremt viktige for effektiv navigering i databaselagringen (den kalles \"heap\"). Postgres st\u00f8tter ikke for klustring, og MVCC-arkitekturen f\u00f8rer til at mange versjoner av den samme tuppen akkumuleres. Derfor er det veldig viktig \u00e5 kunne lage og vedlikeholde effektive indekser for \u00e5 st\u00f8tte applikasjoner.<\/p>\n

Jeg vil gjerne gi deg noen tips for optimalisering og forbedring av indekbruk.<\/p>\n

Merk: Sp\u00f8rsm\u00e5lene nedenfor fungerer p\u00e5 en uendret eksempelbase av dataene pagila<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Bruk av dekkende indekser (Covering Indexes)<\/h3>\n

\nLa oss se p\u00e5 en foresp\u00f8rsel for \u00e5 hente e-postadresser for inaktive brukere. I tabellen customer<\/code> finnes det en kolonne active<\/code>, og foresp\u00f8rselen blir enkel:<\/p>\n

pagila=# EXPLAIN SELECT email FROM customer WHERE active=0;\n                        QUERY PLAN\n-----------------------------------------------------------\n Sekvensiell skanning p\u00e5 customer  (cost=0.00..16.49 rows=15 width=32)\n   Filter: (active = 0)\n(2 rows)<\/code><\/pre>\n
\nI foresp\u00f8rselen aktiveres en full sekvensiell skanning av tabellen customer<\/code>. La oss opprette en indeks for kolonnen 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 Indeks-skanne ved bruk av idx_cust1 p\u00e5 customer  (cost=0.28..12.29 rows=15 width=32)\n   Indeksbetingelse: (active = 0)\n(2 rows)<\/code><\/pre>\n
\nHjalp, det p\u00e5f\u00f8lgende skanningen omdannet til «index scan<\/code>«. Dette betyr at Postgres skanner indeksen «idx_cust1<\/code>«, og deretter fortsetter \u00e5 s\u00f8ke i heapen for \u00e5 lese verdier fra andre kolonner (i dette tilfellet kolonne email<\/code>), som kreves av foresp\u00f8rselen.<\/p>\n
I PostgreSQL 11 ble dekkende indekser introdusert. De gj\u00f8r det mulig \u00e5 inkludere en eller flere ekstra kolonner i indeksen selv - deres verdier lagres i datalagringen av indeksen.<\/p>\n
Hvis vi hadde brukt denne muligheten og lagt til e-postverdien i indeksen, ville ikke Postgres trengt \u00e5 s\u00f8ke i heapen i tabellen for verdien email<\/code>. La oss se om dette fungerer:<\/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 Indeks bare skanne ved bruk av idx_cust2 p\u00e5 customer (cost=0.28..12.29 rows=15 width=32)\n   Indeksbetingelse: (active = 0)\n(2 rows)<\/code><\/pre>\n
\n«Indeks bare skanne<\/code>» forteller oss at foresp\u00f8rselen n\u00e5 bare trenger indeksen, noe som bidrar til \u00e5 unng\u00e5 alle disk I\/O-operasjoner for \u00e5 lese heapen.<\/p>\n
I dag er de dekkende indeksene kun tilgjengelige for B-tr\u00e6r. Men i s\u00e5 fall vil vedlikeholdskostnadene v\u00e6re h\u00f8yere.<\/p>\n
Bruk av delvise indekser<\/h3>\n
\nDelvise indekser indekserer kun en undergruppe av radene i tabellen. Dette sparer plass og gj\u00f8r skanningene raskere.<\/p>\n
La oss si at vi trenger \u00e5 f\u00e5 en liste over e-postadresser til kundene v\u00e5re fra California. Sp\u00f8rsm\u00e5let vil v\u00e6re slik:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nmed en sp\u00f8rringsplan som involverer \u00e5 skanne begge tabellene som er koblet sammen:\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
\nHva gir oss vanlige indekser:<\/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
\nSkanning address<\/code> ble erstattet med indeksskanne idx_address1<\/code>, og deretter ble en haug skannet address<\/code>.<\/p>\n
Siden dette er en hyppig sp\u00f8rring og m\u00e5 optimaliseres, kan vi bruke en delvis indeks som indekserer bare de radene med adresser der distriktet \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
\nN\u00e5 leser sp\u00f8rringen kun idx_address2<\/code> og ber\u00f8rer ikke tabellen address<\/code>.<\/p>\n
Bruk av multivalue-indekser (Multi-Value Indexes)<\/h3>\n
\nNoen kolonner som m\u00e5 indekseres, kan mangle skalar datatyper. Kolonnetyper som jsonb<\/code>, arrays<\/code> og tsvector<\/code> kan inneholde sammensatte eller multiv\u00e6rdi verdier. Hvis du m\u00e5 indeksere slike kolonner, m\u00e5 man vanligvis s\u00f8ke blant alle de individuelle verdiene i disse kolonnene.<\/p>\n
La oss pr\u00f8ve \u00e5 finne titlene p\u00e5 alle filmer som inneholder klipp fra mislykkede dublinger. I tabellen film<\/code> finnes det en tekstkolonne som heter special_features<\/code>. Hvis filmen har dette \"s\u00e6rlige trekket\", inneholder kolonnen et element i form av et tekstarray Behind The Scenes<\/code>. For \u00e5 s\u00f8ke etter alle slike filmer m\u00e5 vi velge alle rader med \"Behind The Scenes\" uansett verdier i arrayet. <\/b>SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}'; special_features<\/code>:<\/p>\n
Containment-operat\u00f8ren<\/code><\/pre>\n
\n@> sjekker om h\u00f8yre side er et delsett av venstre side.<\/code> Sp\u00f8rringsplan:<\/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)<\/p>\n
Som ber om en full skanning av bunken, med en kostnad p\u00e5 67.<\/code><\/pre>\n
\nLa oss se om en vanlig B-tre indeks kan hjelpe oss:<\/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)<\/p>\n
Indeksen ble ikke engang vurdert. B-tre indeksen er ikke klar over eksisterende elementer i de indekserte verdiene.<\/code><\/pre>\n
\nVi trenger en GIN-indeks.<\/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)<\/p>\n
GIN-indeksen st\u00f8tter samsvar av individuelle verdier med indekserte sammensatte verdier, noe som reduserer kostnaden for sp\u00f8rringsplanen med mer enn halvparten.<\/code><\/pre>\n
\nVi eliminerer duplisering av indekser.<\/p>\n
Fjerner duplisering av indekser<\/h3>\n
\nIndekser samles over tid, og noen ganger kan et nytt indeks ha samme definisjon som en av de tidligere. For \u00e5 f\u00e5 SQL-definisjoner av indekser som er menneskelig lesbare, kan man bruke katalogvisningen pg_indexes<\/code>. Du vil ogs\u00e5 kunne enkelt finne like definisjoner:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nOg her er resultatet n\u00e5r det kj\u00f8res p\u00e5 den originale pagila-databasen:\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 rows)\n<\/code><\/pre>\n
<\/p>\n
Indekser for overmengder (Superset Indexes)<\/h3>\n
\nDet kan hende at du har samlet mange indekser, der en av dem indekserer en overmenge av kolonner som andre indekserer. Dette kan v\u00e6re \u00f8nskelig eller ikke \u2014 overmengden kan f\u00f8re til at det bare skannes gjennom indeksene, noe som er bra, men det kan ogs\u00e5 ta for mye plass, eller foresp\u00f8rselen som overmengden var ment \u00e5 optimalisere, kan allerede ikke v\u00e6re i bruk.<\/p>\n
Hvis du trenger \u00e5 automatisere identifiseringen av slike indekser, s\u00e5 kan du begynne med pg_index<\/a><\/noindex> fra tabellen pg_catalog<\/code>.<\/p>\n
Ubrukte indekser<\/h3>\n
\nEtter hvert som applikasjoner som bruker databaser utvikler seg, utvikler ogs\u00e5 de foresp\u00f8rslene de bruker seg. Indekser som ble lagt til tidligere, kan allerede ikke v\u00e6re i bruk av noen foresp\u00f8rsel. Hver gang en indeks skannes, blir den merket av statistikkbehandleren, og i systemkatalogen pg_stat_user_indexes<\/code> kan man se verdien idx_scan<\/code>, som er en kumulativ teller. \u00c5 spore dette tallet over en viss periode (for eksempel en m\u00e5ned) vil gi en god forst\u00e5else av hvilke indekser som ikke brukes og kan fjernes.<\/p>\n
Her er foresp\u00f8rselen for \u00e5 hente de n\u00e5v\u00e6rende skannerne til alle indekser i skjemaet 'public'<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nmed utdata som dette:\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 rader)<\/code><\/pre>\n
<\/p>\n
Rekonstruksjon av indekser med f\u00e6rre l\u00e5ser<\/h3>\n
\nOfte m\u00e5 indekser rekonstruktureres, for eksempel n\u00e5r de vokser i st\u00f8rrelse, og rekonstruksjon kan \u00f8ke skanningshastigheten. Indekser kan ogs\u00e5 bli \u00f8delagt. Endring av indeksets parametere kan ogs\u00e5 kreve rekonstruksjon.<\/p>\n
Vi aktiverer parallell indeksering<\/h3>\n
\nI PostgreSQL 11 er oppretting av B-Tree-indekser parallelt. For \u00e5 akselerere prosessen kan flere arbeidere jobbe parallelt. S\u00f8rg imidlertid for at disse konfigurasjonsparameterne er riktig satt:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nStandardverdiene er for sm\u00e5. Ideelt sett b\u00f8r disse tallene \u00f8kes i takt med antall prosessorkjerner. Les mer i dokumentasjonen<\/a><\/noindex>.<\/p>\n
Bakgrunnsindeksering<\/h3>\n
\nDu kan opprette en indeks i bakgrunnen ved \u00e5 bruke parameteren CONCURRENTLY<\/code> kommandoer CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Denne prosedyren for indeksskapelse skiller seg fra den vanlige ved at den ikke krever \u00e5 l\u00e5se tabellen, og dermed blokkerer den ikke skriveoperasjoner. P\u00e5 den annen side tar den mer tid og bruker flere ressurser.<\/p>\n
Postgres gir mange fleksible muligheter for opprettelse av indekser og l\u00f8sninger for spesifikke tilfeller, samt gir metoder for databaseadministrasjon i tilfelle eksplosiv vekst av applikasjonen din. Vi h\u00e5per disse tipsene vil hjelpe deg \u00e5 gj\u00f8re foresp\u00f8rslene raske og forberede databasen for skalering.
\n
Kilde: 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\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\udd47Vi utnytter alle muligheter med indekser i PostgreSQL | ProHoster","description":"I en verden av Postgres er indekser ekstremt viktige for.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}