{"id":74737,"date":"2020-03-20T08:43:14","date_gmt":"2020-03-20T05:43:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa"},"modified":"2020-03-20T08:43:14","modified_gmt":"2020-03-20T05:43:14","slug":"optimizacziya-strok-v-clickhouse-doklad-yandeksa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","title":{"rendered":"Optimalisering av rader i ClickHouse. Forelesning fra Yandex","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Analytisk DB ClickHouse h\u00e5ndterer mange forskjellige strenger og bruker ressurser. For \u00e5 akselerere systemet legges det hele tiden til nye optimaliseringer. Utvikler av ClickHouse, Nikolai Kochetov, snakker om datatypen for strenger, inkludert den nye typen, LowCardinality, og forklarer hvordan man kan gj\u00f8re operasjoner med strenger raskere. <\/p>\n

\r\n \"Spill\r\n
<\/div>\r\n <\/div><\/center>
\n\u2014 La oss f\u00f8rst se p\u00e5 hvordan vi kan lagre strenger.
\n<\/a><\/noindex>
\n\"Optimalisering
\n
\nVi har datatyper for strenger. String fungerer godt som standard, og det b\u00f8r nesten alltid brukes. Det har en liten Overhead \u2014 9 byte per streng. Hvis vi \u00f8nsker at st\u00f8rrelsen p\u00e5 strenger skal v\u00e6re fast og kjent p\u00e5 forh\u00e5nd, er det bedre \u00e5 bruke FixedString. I den kan vi spesifisere \u00f8nsket antall byte, og den er praktisk for data som IP-adresser eller hash-funksjoner. <\/p>\n

\"Optimalisering
\n
\nSelvf\u00f8lgelig hender det noen ganger at noe er tregt. La oss si at du gj\u00f8r en foresp\u00f8rsel til en tabell. ClickHouse leser ganske mye data, si med en hastighet p\u00e5 100 GB\/s, mens antallet strenger som behandles er ganske lite. Vi har to tabeller som lagrer nesten identiske data. Fra den andre tabellen leser ClickHouse data raskere, men antallet strenger som leses per sekund er tre ganger lavere. <\/p>\n

\"Optimalisering
\n
\nHvis vi ser p\u00e5 st\u00f8rrelsen av de komprimerte dataene, vil de vise seg \u00e5 v\u00e6re nesten like. I virkeligheten er det skrevet de samme dataene i tabellene \u2014 den f\u00f8rste milliarden tall \u2014 bare i den f\u00f8rste kolonnen er de skrevet som UInt64, mens i den andre kolonnen er de skrevet som String. P\u00e5 grunn av dette bruker den andre foresp\u00f8rselen lengre tid p\u00e5 \u00e5 lese data fra disken og dekomprimere dem. <\/p>\n

\"Optimalisering
\n
\nHer er et annet eksempel. Anta at det er et forh\u00e5ndsbekjent sett med strenger, begrenset av en konstant p\u00e5 1000 eller 10 000 og som praktisk talt aldri endres. I dette tilfellet passer datatypen Enum for oss, i ClickHouse er det to \u2014 Enum8 og Enum16. Ved \u00e5 lagre i Enum kan vi raskt behandle foresp\u00f8rslene. <\/p>\n

I ClickHouse finnes det akselerasjoner for GROUP BY, IN, DISTINCT og optimaliseringer for visse funksjoner, for eksempel for sammenligning med en konstant streng. Selvf\u00f8lgelig konverteres ikke tall i strengen, men derimot konverteres den konstante strengen til verdien Enum. Etter dette blir alt raskt sammenlignet. <\/p>\n

Men det finnes ogs\u00e5 ulemper. Selv om vi vet det eksakte settet av strenger, m\u00e5 det noen ganger oppdateres. En ny streng har kommet \u2014 vi m\u00e5 utf\u00f8re ALTER. <\/p>\n

\"Optimalisering
\n
\nALTER for Enum in ClickHouse is implemented optimally. We do not rewrite data on disk, but ALTER operations can be slow due to the fact that Enum structures are stored in the table\u2019s schema. Therefore, we must wait for read requests from the table, for example. <\/p>\n

This raises the question: can it be done better? Probably, yes. You could store the Enum structure not in the table schema, but in ZooKeeper. However, this could create synchronization issues. For instance, one replica may have received the data while another has not, and if it has an old Enum, something could break. (In ClickHouse, we have almost completed non-blocking ALTER queries. Once we finish them, there will be no need to wait for read requests.)<\/p>\n

\"Optimalisering
\n
\nTo avoid dealing with ALTER Enum, you can use ClickHouse external dictionaries. Recall that this is a key-value data structure within ClickHouse that allows you to retrieve data from external sources, such as MySQL tables. <\/p>\n

In the ClickHouse dictionary, we store many different strings, while in the table, we store their identifiers as numbers. When we need to fetch a string, we call the dictGet function and work with it. After that, we don\u2019t need to perform an ALTER operation. To add something to the Enum, we insert it into the same MySQL table. <\/p>\n

However, this introduces other problems. First, there\u2019s inconvenient syntax. If we want to get a string, we have to call dictGet. Second, there\u2019s a lack of certain optimizations. Comparing with a constant string for dictionaries is not as fast. <\/p>\n

There could also be issues with updates. Suppose we requested a string from the cache dictionary, but it didn\u2019t get into the cache. Then we must wait for the data to load from the external source. <\/p>\n

\"Optimalisering
\n
\nThe overall disadvantage of both methods is that we store all keys in one place and synchronize them. So why not store dictionaries locally? No synchronization means no problems. You can store the dictionary locally in a chunk on disk. That is, we perform an Insert, write the dictionary. If we work with data in memory, we can store the dictionary either in a data block, or in a column chunk, or in some cache to speed up computations.<\/p>\n

Dictionary encoding of strings <\/h3>\n

\nThus, we have come to create a new data type in ClickHouse \u2014 LowCardinality. This is a data storage format: how it is written to disk, how it is read, how it is represented in memory, and the scheme of its processing. <\/p>\n

\"Optimalisering
\n
\nLysbildet inneholder to kolonner. Til h\u00f8yre lagres radene standardmessig, som Streng. Det er tydelig at dette er noen mobiltelefonmodeller. Til venstre er det en identisk kolonne, men i LowCardinality-type. Den best\u00e5r av et ordbok med mange forskjellige strenger (strengene fra kolonnen til h\u00f8yre) og en liste med posisjoner (radnumre). <\/p>\n

Med disse to strukturene kan man gjenskape den opprinnelige kolonnen. Det finnes ogs\u00e5 en omvendt omvendt indeks \u2014 en hash-tabell som hjelper med \u00e5 finne posisjonen i ordboken basert p\u00e5 strengen. Den er n\u00f8dvendig for \u00e5 akselerere enkelte foresp\u00f8rseler. For eksempel, hvis vi \u00f8nsker \u00e5 sammenligne, s\u00f8ke etter en streng i kolonnen v\u00e5r eller sl\u00e5 dem sammen. <\/p>\n

LowCardinality er en parameterisk datatype. Den kan v\u00e6re enten et tall, eller noe som lagres som et tall, eller en streng, eller Nullable av dem. <\/p>\n

\"Optimalisering
\n
\nSpesialiteten til LowCardinality er at den kan lagres for enkelte funksjoner. P\u00e5 lysbildet vises et eksempel p\u00e5 en foresp\u00f8rsel. I den f\u00f8rste linjen laget jeg en kolonne av LowCardinality av Streng, jeg kalte den S. Deretter spurte jeg om navnet, \u2014 ClickHouse sa at det var LowCardinality av Streng. Det stemmer.<\/p>\n

Den tredje linjen er nesten lik, bare at vi kalte funksjonen length. I ClickHouse returnerer length-funksjonen datatypen UInt64. Men vi fikk LowCardinality av UInt64. Hva er meningen?<\/p>\n

\"Optimalisering
\n
\nI ordboken ble navnene p\u00e5 mobiltelefonene lagret, vi brukte funksjonen length. N\u00e5 har vi f\u00e5tt en tilsvarende ordbok best\u00e5ende bare av tall \u2014 dette er lengdene p\u00e5 strenger. Kolonnen med posisjoner forble uendret. I resultatet behandlet vi mindre data, sparte tid p\u00e5 foresp\u00f8rselen. <\/p>\n

Det kan ogs\u00e5 v\u00e6re andre optimaliseringer, for eksempel ved \u00e5 legge til en enkel cache. N\u00e5r man beregner verdien av funksjonen, kan man huske den og lage en lignende uten \u00e5 beregne p\u00e5 nytt. <\/p>\n

Det kan ogs\u00e5 gj\u00f8res en optimalisering av GROUP BY, fordi kolonnen v\u00e5r med ordboken allerede er delvis aggregert \u2014 det kan v\u00e6re raskere \u00e5 beregne verdien av hash-funksjoner og omtrentlig finne b\u00f8ttet der neste rad kan plasseres. Det er ogs\u00e5 mulig \u00e5 spesialisere enkelte aggregeringsfunksjoner, for eksempel uniq, ettersom vi kun kan sende ordboken til den, mens posisjonene forblir ur\u00f8rt \u2014 slik vil alt fungere raskere. De f\u00f8rste to optimaliseringene har vi allerede lagt til i ClickHouse.<\/p>\n

\"Optimalisering
\n
\nHva om vi lager en kolonne med v\u00e5r datatype og setter inn mange d\u00e5rlige, forskjellige strenger? Vil ikke minnet v\u00e5rt bli overfylt? Nei, for dette har ClickHouse to spesielle innstillinger. Den f\u00f8rste er low_cardinality_max_dictionary_size. Dette er den maksimale st\u00f8rrelsen p\u00e5 et ordforr\u00e5d som kan skrives til disk. Innsetting skjer slik: n\u00e5r vi setter inn data, f\u00e5r vi en str\u00f8m av strenger, og av dem danner vi et stort felles ordforr\u00e5d. Hvis ordforr\u00e5det blir st\u00f8rre enn innstillingsverdien, skriver vi det n\u00e5v\u00e6rende ordforr\u00e5det til disk, mens de andre strengene blir \u00abliggende\u00bb ved siden av indeksene. Resultatet blir at vi aldri m\u00e5 gjenberegne et stort ordforr\u00e5d og f\u00e5r ikke problemer med minnet. <\/p>\n

Den andre innstillingen kalles low_cardinality_use_single_dictionary_for_part. Tenk deg at i det forrige scenariet, n\u00e5r vi satte inn data, ble ordforr\u00e5det v\u00e5rt overfylt, og vi skrev det til disk. Sp\u00f8rsm\u00e5let oppst\u00e5r, hvorfor ikke lage et annet n\u00f8yaktig likt ordforr\u00e5d? <\/p>\n

N\u00e5r det blir overfylt, skriver vi det igjen til disk og begynner \u00e5 danne et tredje. Denne innstillingen deaktiverer som standard denne muligheten. <\/p>\n

Faktisk kan mange ordforr\u00e5d v\u00e6re nyttige, hvis vi vil sette inn en viss mengde strenger, men tilfeldig har satt inn \u00abs\u00f8ppel\u00bb. Si at vi f\u00f8rst satte inn d\u00e5rlige strenger, og deretter satte inn gode. Da vil ordforr\u00e5det deles opp i mange sm\u00e5 ordforr\u00e5d. Noen av dem vil ha \u00abs\u00f8ppel\u00bb, men de siste vil ha gode strenger. Og hvis vi leser bare den siste granulen, vil alt ogs\u00e5 fungere raskt. <\/p>\n

\"Optimalisering
\n
\nF\u00f8r vi snakker om fordelene med LowCardinality, skal jeg straks si at vi neppe vil oppn\u00e5 en reduksjon av dataene p\u00e5 disken (selv om det kan hende), fordi ClickHouse komprimerer dataene. Det er en standardmulighet \u2014 LZ4. Det er ogs\u00e5 mulig \u00e5 gj\u00f8re komprimering med ZSTD. Men begge algoritmene implementerer allerede ordkomprimering, s\u00e5 v\u00e5rt eksterne ordforr\u00e5d i ClickHouse vil ikke v\u00e6re til stor hjelp. <\/p>\n

For the sake of being concrete, I took some data from the metrics \u2014 String, LowCardinality(String), and Enum \u2014 and saved them in different data types. This resulted in three columns containing one billion rows. In the first column, CodePage, there are only 62 values. It's clear that LowCardinality(String) compresses them better. String is slightly worse, but that's likely due to the short strings; we store their lengths, which takes up a lot of space and compresses poorly. <\/p>\n

Taking PhoneModel as an example, there are 48 thousand of them \u2014 already more, and the differences between String and LowCardinality(String) are negligible. We also saved just 2 GB for URLs \u2014 I think it\u2019s not worth relying on. <\/p>\n

Performance Evaluation<\/h3>\n

\n\"Optimalisering
\nLink from the slide<\/a><\/noindex><\/b><\/p>\n

Now let\u2019s evaluate the performance. To do this, I used a dataset describing taxi rides in New York. It\u2019s tilgjengelig<\/a><\/noindex> on GitHub. It has just over a billion rides. It includes the location, start and end time of the ride, payment method, number of passengers, and even the type of taxi \u2014 green, yellow, or Uber. <\/p>\n

\"Optimalisering
\n
\nMy first query was quite simple \u2014 I asked where taxis are most frequently ordered from. For this, we need to take the location from which the taxi was ordered, GROUP BY it, and count the function count. Here\u2019s what ClickHouse outputs. <\/p>\n

\"Optimalisering
\n
\nTo measure the query processing speed, I created three tables with the same data, but I used three different data types for our starting location \u2014 String, LowCardinality, and Enum. LowCardinality and Enum turned out to be five times faster than String. Enum is faster because it works with numbers. LowCardinality is faster due to the GROUP BY optimization. <\/p>\n

\"Optimalisering
\n
\nLet\u2019s complicate the query a bit more \u2014 let\u2019s ask where the most popular park in New York is located. Again, we will measure this by where taxis are most frequently ordered, but we will filter only those locations that contain the word \u201cpark.\u201d We will also add the like function. <\/p>\n

\"Optimalisering
\n
\nLooking at the time \u2014 we see that Enum suddenly started to lag. In fact, it works even slower than the standard data type String. This happens because the like function is not optimized for Enum at all. We have to convert our strings from Enum to regular strings \u2014 we\u2019re doing more work. LowCardinality(String) is also not optimized by default, but there, like operates on the dictionary, so the query is accelerated compared to String. <\/p>\n

N\u00e5r vi arbeider med Enum, er det et mer overordnet problem. Hvis vi \u00f8nsker \u00e5 optimalisere det, m\u00e5 vi gj\u00f8re det p\u00e5 hver eneste plass i koden. La oss si at vi har skrevet en ny funksjon \u2013 vi m\u00e5 absolutt finne en optimalisering for Enum. I LowCardinality er alt optimalisert som standard.<\/p>\n

\"Optimalisering
\n
\nLa oss se p\u00e5 den siste foresp\u00f8rselen, som er mer kunstig. Vi vil bare beregne hash-funksjonen for plasseringen v\u00e5r. Hash-funksjonen er en ganske treig foresp\u00f8rsel som tar tid, s\u00e5 alt vil bli tre ganger langsommere.<\/p>\n

\"Optimalisering
\n
\nLowCardinality fungerer fortsatt raskere, selv om det ikke er noen filtrering her. Dette skjer fordi funksjonene v\u00e5re kun arbeider med ordboken. Hash-beregningsfunksjonen har \u00e9n parameter \u2013 den kan behandle mindre data og kan ogs\u00e5 returnere LowCardinality. <\/p>\n

\"Optimalisering
\n
\nV\u00e5r globale plan er \u00e5 oppn\u00e5 en hastighet som ikke er lavere enn String i alle tilfeller, og \u00e5 opprettholde forbedringer. Og kanskje en dag vil vi erstatte String med LowCardinality, du oppdaterer ClickHouse, og alt vil fungere litt raskere.
\n
Kilde: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0421\u0423\u0411\u0414 ClickHouse \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044f \u0440\u0435\u0441\u0443\u0440\u0441\u044b. \u0414\u043b\u044f \u0443\u0441\u043a\u043e\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438. \u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a ClickHouse \u041d\u0438\u043a\u043e\u043b\u0430\u0439 \u041a\u043e\u0447\u0435\u0442\u043e\u0432 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442 \u043e \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043e \u043d\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435, LowCardinality, \u0438 \u043e\u0431\u044a\u044f\u0441\u043d\u044f\u0435\u0442, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0443\u0441\u043a\u043e\u0440\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043e \u0441\u0442\u0440\u043e\u043a\u0430\u043c\u0438. \u2014 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u0434\u0430\u0432\u0430\u0439\u0442\u0435 \u0440\u0430\u0437\u0431\u0435\u0440\u0435\u043c\u0441\u044f, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u0438. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u044b\u0435 \u0442\u0438\u043f\u044b \u0434\u0430\u043d\u043d\u044b\u0445. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":74738,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-74737","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\udd47Optimalisering av strenger i ClickHouse. Foredrag fra Yandex | ProHoster","description":"Den analytiske databasen ClickHouse behandler mange ulike strenger og forbruker ressurser. For \u00e5 akselerere systemets ytelse legges det stadig til nye optimaliseringer.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","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\u041e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0442\u0440\u043e\u043a \u0432 ClickHouse. \u0414\u043e\u043a\u043b\u0430\u0434 \u042f\u043d\u0434\u0435\u043a\u0441\u0430 | ProHoster","og:description":"\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0421\u0423\u0411\u0414 ClickHouse \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044f \u0440\u0435\u0441\u0443\u0440\u0441\u044b. \u0414\u043b\u044f \u0443\u0441\u043a\u043e\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438.","og:url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","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-03-20T05:43:14+00:00","article:modified_time":"2020-03-20T05:43:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"74737","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-02-28 17:23:10","updated":"2022-09-27 14:48:44","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\/74737","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=74737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/74737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/74738"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=74737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=74737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=74737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}