{"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\/nl\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","title":{"rendered":"Gebruik alle mogelijkheden van indexen in PostgreSQL","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Gebruik
\nIn de wereld van Postgres zijn indexen van cruciaal belang voor effectieve navigatie door de database-opslag (de zogenaamde 'heap'). Postgres ondersteunt geen clustering ervoor, en de MVCC-architectuur zorgt ervoor dat u veel versies van dezelfde tuple accumuleert. Daarom is het heel belangrijk om effectieve indexen te kunnen cre\u00ebren en onderhouden ter ondersteuning van toepassingen.<\/p>\n

Hier zijn enkele tips voor het optimaliseren en verbeteren van het gebruik van indexen.<\/p>\n

Opmerking: de onderstaande queries werken op een ongewijzigd voorbeeld van de database pagila.<\/a><\/noindex>.<\/i>
\n<\/a><\/noindex><\/p>\n

Het gebruik van dekkende indexen (Covering Indexes)<\/h3>\n

\nLaten we een query bekijken om e-mailadressen op te halen van inactieve gebruikers. In de tabel customer<\/code> is er een kolom actief<\/code>, en de query is vrij eenvoudig:<\/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
\nIn de query wordt er een volledige sequenti\u00eble scan van de tabel aangeroepen. customer<\/code>Laten we een index aanmaken voor de kolom actief<\/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
\nHet hielp, de volgende scan werd \"index scan<\/code>\". Dit betekent dat Postgres de index \"idx_cust1<\/code>\", en vervolgens verdergaat met het zoeken in de heap-tabel om waarden van andere kolommen te lezen (in dit geval de kolom e-mail<\/code>), die de query nodig heeft.<\/p>\n
In PostgreSQL 11 zijn dekkende indexen ge\u00efntroduceerd. Deze maken het mogelijk om een of meerdere extra kolommen in de index op te nemen - hun waarden worden opgeslagen in de opslag van de index.<\/p>\n
Als we deze mogelijkheid gebruikten en de e-mailwaarde aan de index toevoegden, hoeft Postgres de waarde niet in de heap van de tabel te zoeken. e-mail<\/code>Laten we bekijken of dit werkt:<\/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>\" vertelt ons dat de query nu voldoende heeft aan alleen de index, wat helpt om alle schijfinvoeren\/uitvoeren te vermijden voor het lezen van de heap-tabel.<\/p>\n
Vandaag zijn de dekkende indexen alleen beschikbaar voor B-bomen. In dit geval zullen de onderhoudsinspanningen echter hoger zijn.<\/p>\n
Gebruik van parti\u00eble indexen<\/h3>\n
\nParti\u00eble indexen indexeren slechts een subset van de rijen in een tabel. Dit bespaart ruimte in de indexen en versnelt het scannen.<\/p>\n
Stel dat we een lijst met e-mailadressen van onze klanten uit Californi\u00eb nodig hebben. De query zou als volgt zijn:<\/p>\n
SELECT c.email FROM customer c\nJOIN address a ON c.address_id = a.address_id\nWHERE a.district = 'California';\nwat een queryplan heeft dat beide gekoppelde tabellen scant:\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
\nWat bieden gewone indexen ons:<\/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
\nScannen address<\/code> werd vervangen door indexscannen idx_address1<\/code>, en vervolgens werd een heap gescand address<\/code>.<\/p>\n
Aangezien dit een veel voorkomende query is en geoptimaliseerd moet worden, kunnen we een parti\u00eble index gebruiken die slechts die rijen met adressen indexeert waarin het district \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
\nNu leest de query alleen idx_address2<\/code> en raakt de tabel niet aan address<\/code>.<\/p>\n
Gebruik van meervoudige indexen (Multi-Value Indexes)<\/h3>\n
\nSommige kolommen die geindexeerd moeten worden, bevatten mogelijk geen scalair datatypes. Kolomtypes zoals jsonb<\/code>, arrays<\/code> en tsvector<\/code> kunnen samengestelde of meervoudige waarden bevatten. Als je dergelijke kolommen wilt indexeren, moet je meestal naar alle afzonderlijke waarden in deze kolommen zoeken.<\/p>\n
Laten we de titels van alle films proberen te vinden die fragmenten van mislukte dubaties bevatten. In de tabel film<\/code> is er een tekstkolom die special_features<\/code>heet. Als een film dit \"speciale kenmerk\" heeft, bevat de kolom een element in de vorm van een tekstarray Behind The Scenes<\/code>. Om al deze films te vinden, moeten we alle rijen selecteren met \"Behind The Scenes\" bij elke <\/b>waarde van de array special_features<\/code>:<\/p>\n
SELECT title FROM film WHERE special_features @> '{\"Behind The Scenes\"}';<\/code><\/pre>\n
\nDe containment-operator @><\/code> controleert of de rechterkant een subset is van de linkerkant.<\/p>\n
De query-planning:<\/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
\nDie een volledige scan van de heap met een kostenwaarde van 67 opvraagt.<\/p>\n
Laten we kijken of een gewone B-tree-index ons kan helpen:<\/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
\nDe index werd zelfs niet overwogen. De B-tree-index vermoedt niet het bestaan van afzonderlijke elementen in de geindexeerde waarden.<\/p>\n
We hebben een GIN-index nodig.<\/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
\nDe GIN-index ondersteunt het matchen van afzonderlijke waarden met geindexeerde samengestelde waarden, waardoor de kosten van de query-planning met meer dan de helft kunnen worden verlaagd.<\/p>\n
We verminderen de duplicatie van indices.<\/h3>\n
\nIndexen accumuleren zich in de loop van de tijd en soms kan een nieuwe index dezelfde definitie bevatten als een van de vorige. Voor leesbare SQL-definities van indexen kunt u de catalogusweergave gebruiken. pg_indexes<\/code>. U kunt ook gemakkelijk identieke definities vinden:<\/p>\n
 SELECT array_agg(indexname) AS indexes, replace(indexdef, indexname, '') AS defn\n    FROM pg_indexes\nGROUP BY defn\n  HAVING count(*) > 1;\nEn hier is het resultaat wanneer het wordt uitgevoerd op de stock pagila database:\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
Superset Indexes<\/h3>\n
\nHet kan zijn dat u veel indexen heeft, waarvan er \u00e9\u00e9n een superset van kolommen indexeert die door andere indexen worden ge\u00efndexeerd. Dit kan zowel wenselijk als ongewenst zijn \u2014 een superset kan leiden tot het scannen alleen op indexen, wat goed is, maar het kan ook te veel ruimte innemen, of de query waarvoor dit superset was bedoeld, wordt al niet meer gebruikt.<\/p>\n
Als u het identificeren van dergelijke indexen wilt automatiseren, kunt u beginnen met pg_index<\/a><\/noindex> uit de tabel pg_catalog<\/code>.<\/p>\n
Ongebruikte indexen<\/h3>\n
\nNaarmate applicaties die databases gebruiken zich ontwikkelen, ontwikkelen ook de query's die ze gebruiken. Eerder toegevoegde indexen kunnen nu door geen enkele query meer worden toegepast. Bij elke indexscan wordt deze gemarkeerd door de statistiekbeheerder, en in de systeemcatalogusweergave pg_stat_user_indexes<\/code> kan de waarde bekeken worden idx_scan<\/code>, die een cumulatieve teller is. Het bijhouden van deze waarde gedurende een bepaalde periode (bijvoorbeeld een maand) biedt een goed inzicht in welke indexen niet worden gebruikt en kunnen worden verwijderd.<\/p>\n
Hier is een verzoek om de huidige scanstatistieken van alle indexen in het schema op te vragen \u2018public\u2019<\/code>:<\/p>\n
SELECT relname, indexrelname, idx_scan\nFROM   pg_catalog.pg_stat_user_indexes\nWHERE  schemaname = 'public';\nmet output zoals dit:\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 rijen)<\/code><\/pre>\n
<\/p>\n
Het opnieuw maken van indexen met minder blokkeringen<\/h3>\n
\nVaak moeten indexen opnieuw worden gemaakt, bijvoorbeeld wanneer ze in omvang toenemen, en het opnieuw maken kan het scannen versnellen. Ook kunnen indexen beschadigd raken. Wijziging van indexparameters kan ook vereisen dat de index opnieuw wordt gemaakt.<\/p>\n
We schakelen parallel indexcreatie in<\/h3>\n
\nIn PostgreSQL 11 is de creatie van een B-Tree-index concurrent. Om het proces van aanmaken te versnellen, kunnen verschillende parallelle werkers worden gebruikt. Zorg er echter voor dat deze configuratieparameters correct zijn ingesteld:<\/p>\n
SET max_parallel_workers = 32;\nSET max_parallel_maintenance_workers = 16;<\/code><\/pre>\n
\nDe standaardwaarden zijn te laag. Idealiter moeten deze cijfers toenemen met het aantal CPU-kernen. Lees meer in de documentatie<\/a><\/noindex>.<\/p>\n
Achtergrondindexcreatie<\/h3>\n
\nU kunt een index op de achtergrond aanmaken door de parameter CONCURRENTLY<\/code> van de opdrachten. CREATE INDEX<\/code>:<\/p>\n
pagila=# CREATE INDEX CONCURRENTLY idx_address1 ON address(district);\nCREATE INDEX<\/code><\/pre>\n
Deze procedure voor het aanmaken van een index verschilt van de gewone doordat deze geen blokkering van de tabel vereist, wat betekent dat deze ook geen schrijfbewerkingen blokkeert. Aan de andere kant duurt het langer en verbruikt het meer middelen.<\/p>\n
Postgres biedt veel flexibele mogelijkheden voor het aanmaken van indexen en manieren om te gaan met specifieke situaties, alsook beheermethoden voor de database in het geval van een explosieve groei van uw applicatie. We hopen dat deze tips u helpen om uw query's snel te houden en de database klaar te maken voor schaling.
\n
Bron: 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\udd47Maximaliseer de voordelen van indexen in PostgreSQL | ProHoster","description":"In de wereld van Postgres zijn indexen extreem belangrijk voor.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/ispolzuem-vse-vozmozhnosti-indeksov-v-postgresql","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/34419","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=34419"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/34419\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/25931"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=34419"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=34419"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=34419"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}