{"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\/da\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","title":{"rendered":"Optimering af strenge i ClickHouse. Yandex-foredrag.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Analyse-databasen ClickHouse h\u00e5ndterer mange forskellige strenge, hvilket forbruger ressourcer. For at forbedre systemets ydeevne tilf\u00f8jes der konstant nye optimeringer. Udvikleren af ClickHouse, Nikolaj Ko\u010detov, fort\u00e6ller om datatypen for strenge, herunder den nye type, LowCardinality, og forklarer, hvordan man kan forbedre arbejdet med strenge. <\/p>\n

\r\n \"Afspil\r\n
<\/div>\r\n <\/div><\/center>
\n\u2014 Lad os f\u00f8rst finde ud af, hvordan man kan gemme strenge.
\n<\/a><\/noindex>
\n\"Optimering
\n
\nVi har strenge datatyper. String er godt egnet som standard, og det b\u00f8r n\u00e6sten altid anvendes. Det har en lille overhead \u2014 9 byte pr. streng. Hvis vi \u00f8nsker, at str\u00e6ngernes st\u00f8rrelse skal v\u00e6re fast og kendt p\u00e5 forh\u00e5nd, er det bedre at bruge FixedString. I det kan vi angive det \u00f8nskede antal byte, det er praktisk til data som IP-adresser eller hash-funktioner. <\/p>\n

\"Optimering
\n
\nSelvf\u00f8lgelig kan der nogle gange v\u00e6re flaskehalse. Antag, at du laver en foresp\u00f8rgsel til en tabel. ClickHouse l\u00e6ser et ret stort antal data, lad os sige med en hastighed p\u00e5 100 GB\/s, mens strenge behandles i sm\u00e5 m\u00e6ngder. Vi har to tabeller, der opbevarer n\u00e6sten de samme data. Fra den anden tabel l\u00e6ser ClickHouse data hurtigere, men der l\u00e6ses tre gange f\u00e6rre strenge pr. sekund. <\/p>\n

\"Optimering
\n
\nHvis vi ser p\u00e5 st\u00f8rrelsen af de komprimerede data, vil den v\u00e6re n\u00e6sten ens. Faktisk er det de samme data, der er optaget i tabellerne \u2014 den f\u00f8rste milliard tal \u2014 forskellen er blot, at de f\u00f8rste kolonne lagrer dem som UInt64, mens de anden kolonne lagrer dem som String. P\u00e5 grund af dette tager den anden foresp\u00f8rgsel l\u00e6ngere tid at l\u00e6se data fra disken og dekomprimere dem. <\/p>\n

\"Optimering
\n
\nHer er et andet eksempel. Lad os antage, at der er et forudbestemt s\u00e6t af strenge, der er begr\u00e6nset til en konstant p\u00e5 1000 eller 10.000 og stort set aldrig \u00e6ndres. I dette tilf\u00e6lde passer datatypen Enum, i ClickHouse er der to \u2014 Enum8 og Enum16. Ved at gemme i Enum h\u00e5ndterer vi foresp\u00f8rgsler hurtigt. <\/p>\n

I ClickHouse er der hastighedsfor\u00f8gelser til GROUP BY, IN, DISTINCT og optimeringer til visse funktioner, for eksempel til sammenligning med en konstant streng. Selvf\u00f8lgelig konverteres tal i strengen ikke, men snarere konverteres den konstante streng til en Enum-v\u00e6rdi. Derefter sammenlignes alt hurtigt. <\/p>\n

Men der er ogs\u00e5 ulemper. Selv hvis vi kender det pr\u00e6cise s\u00e6t af strenge, skal det nogle gange opdateres. En ny streng er blevet tilf\u00f8jet \u2014 vi skal foretage en ALTER. <\/p>\n

\"Optimering
\n
\nALTER for Enum in ClickHouse is implemented optimally. We don\u2019t rewrite data on disk, but ALTER might lag due to Enum structures being stored in the table schema. Therefore, we have to wait for read requests from the table, for example. <\/p>\n

The question arises: can it be done better? Probably, yes. The Enum structure could be stored not in the table schema but in ZooKeeper. However, synchronization issues may arise. For example, one replica received the data while another did not, and if it has an old Enum, something might break. (In ClickHouse, we are almost finished with non-blocking ALTER requests. Once they are completely finished, we won\u2019t need to wait for read requests.)<\/p>\n

\"Optimering
\n
\nTo avoid dealing with ALTER Enum, one can use external dictionaries in ClickHouse. Just to remind you, 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. If you need to get a string, we call the dictGet function and work with it. After that, we don\u2019t have to perform an ALTER. To add something to the Enum, we insert it into the same MySQL table. <\/p>\n

However, other issues arise here. First, the syntax is inconvenient. If we want to retrieve a string, we must call dictGet. Second, some optimizations are lacking. A comparison with a constant string for dictionaries is not as fast. <\/p>\n

There may also be issues with updating. Suppose we requested a string in the cache dictionary, but it didn\u2019t make it to the cache. Then we have to wait for data to load from the external source. <\/p>\n

\"Optimering
\n
\nA general drawback 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. A dictionary can be stored locally on a disk chunk. This means we performed an Insert and recorded the dictionary. If we are working with data in memory, we can write the dictionary either in a data block, in a column chunk, or in some cache to speed up computations.<\/p>\n

Dictionary encoding of strings <\/h3>\n

\nThus, we arrived at creating a new data type in ClickHouse \u2014 LowCardinality. This is a data storage format: how they are written to disk and read, how they are represented in memory, and the schema of their processing. <\/p>\n

\"Optimering
\n
\nP\u00e5 diaset er der to kolonner. Til h\u00f8jre er r\u00e6kkerne gemt standardm\u00e6ssigt i typen String. Det er tydeligt, at dette er nogle modeller af mobiltelefoner. Til venstre er der en lignende kolonne, men i typen LowCardinality. Den best\u00e5r af et ordbog med mange forskellige strenge (strengene fra kolonnen til h\u00f8jre) og en liste af positioner (r\u00e6kke numre). <\/p>\n

Med disse to strukturer kan vi genskabe den oprindelige kolonne. Der er ogs\u00e5 en omvendt indeks \u2014 en hash-tabel, som hj\u00e6lper med at finde positionen i ordbogen baseret p\u00e5 en streng. Den er n\u00f8dvendig for at fremskynde visse foresp\u00f8rgsler. For eksempel, hvis vi \u00f8nsker at sammenligne, s\u00f8ge efter en streng i vores kolonne eller fusionere dem. <\/p>\n

LowCardinality er en parameteriseret datatype. Den kan v\u00e6re enten et tal, eller noget, der gemmes som et tal, eller en streng, eller Nullable af dem. <\/p>\n

\"Optimering
\n
\nS\u00e6rligheden ved LowCardinality er, at den kan gemmes til visse funktioner. P\u00e5 diaset ses et eksempel p\u00e5 en foresp\u00f8rgsel. I den f\u00f8rste linje har jeg oprettet en kolonne af typen LowCardinality fra String, og kaldte den S. Derefter spurgte jeg om dens navn \u2014 ClickHouse sagde, at det er LowCardinality fra String. Alt korrekt.<\/p>\n

Den tredje linje er n\u00e6sten den samme, blot har vi kaldt funktionen length. I ClickHouse returnerer funktionen length datatypen UInt64. Men vi endte med LowCardinality fra UInt64. Hvad er meningen?<\/p>\n

\"Optimering
\n
\nI ordbogen blev navne p\u00e5 mobiltelefoner gemt, vi anvendte funktionen length. Nu har vi en tilsvarende ordbog, der kun best\u00e5r af tal \u2014 det er l\u00e6ngderne af strengene. Kolonnen med positioner er ikke \u00e6ndret. I sidste ende behandlede vi f\u00e6rre data, og sparede tid p\u00e5 foresp\u00f8rgslen. <\/p>\n

Der kan v\u00e6re andre optimeringer, for eksempel tilf\u00f8jelse af en simpel cache. Ved beregning af funktionsv\u00e6rdien kan man huske den og lave en tilsvarende, uden at beregne den igen. <\/p>\n

Der kan ogs\u00e5 laves en optimering til GROUP BY, fordi vores kolonne med ordbogen allerede er delvist aggregeret \u2014 det muligt hurtigere at beregne v\u00e6rdierne af hashfunktioner og omtrent finde den bucket, hvor man kan placere den n\u00e6ste r\u00e6kke. Derudover kan man specialisere visse aggregatfunktioner, for eksempel uniq, da den kun kan modtage ordbogen, mens positionerne forbliver ur\u00f8rte \u2014 s\u00e5 vil alt fungere hurtigere. De f\u00f8rste to optimeringer er allerede tilf\u00f8jet i ClickHouse.<\/p>\n

\"Optimering
\n
\nHvad hvis vi opretter en kolonne med vores datatype og inds\u00e6tter mange d\u00e5rlige, forskellige strenge? Vil vores hukommelse ikke blive overfyldt? Nej, der er to specielle indstillinger i ClickHouse til dette. Den f\u00f8rste er low_cardinality_max_dictionary_size. Det er den maksimale st\u00f8rrelse af ordbogen, der kan skrives til disk. Inds\u00e6ttelsen foreg\u00e5r p\u00e5 f\u00f8lgende m\u00e5de: n\u00e5r vi inds\u00e6tter data, modtager vi en str\u00f8m af strenge, og fra dem danner vi en stor samlet ordbog. Hvis ordbogen bliver st\u00f8rre end v\u00e6rdien af indstillingen, skriver vi den nuv\u00e6rende ordbog til disk, og de \u00f8vrige strenge opbevares et sted 'ved siden af', t\u00e6ttere p\u00e5 indeksene. Resultatet er, at vi aldrig vil genberegne den store ordbog og f\u00e5r ikke hukommelsesproblemer. <\/p>\n

Den anden indstilling hedder low_cardinality_use_single_dictionary_for_part. Forestil dig, at i det tidligere skema, n\u00e5r vi indsatte data, blev vores ordbog overfyldt, og vi skrev den til disk. Sp\u00f8rgsm\u00e5let opst\u00e5r, hvorfor ikke danne endnu en pr\u00e6cis samme ordbog? <\/p>\n

N\u00e5r den er overfyldt, vil vi igen skrive den til disk og begynde at danne den tredje. Denne indstilling deaktiverer faktisk denne mulighed som standard. <\/p>\n

Mange ordb\u00f8ger kan faktisk v\u00e6re nyttige, hvis vi \u00f8nsker at inds\u00e6tte et vis antal strenge, men tilf\u00e6ldigt indsatte 'skrald'. Lad os sige, at vi f\u00f8rst indsatte d\u00e5rlige strenge, og derefter indsatte gode. S\u00e5 ville ordbogen blive delt op i mange sm\u00e5 ordb\u00f8ger. Nogle af dem vil have 'skrald', men de sidste vil have gode strenge. Og hvis vi l\u00e6ser, lad os sige, kun den seneste granule, vil alt stadig fungere hurtigt. <\/p>\n

\"Optimering
\n
\nF\u00f8r vi taler om fordelene ved LowCardinality, vil jeg straks sige, at vi n\u00e6ppe vil opn\u00e5 en reduktion af dataene p\u00e5 disken (selv om det kan ske), fordi ClickHouse komprimerer dataene. Der er en standardmulighed - LZ4. Derudover kan man komprimere med ZSTD. Men begge algoritmer implementerer allerede ordbogscompression, s\u00e5 vores eksterne ordbog i ClickHouse vil ikke v\u00e6re s\u00e6rlig nyttig. <\/p>\n

For the sake of argument, 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 is clear that LowCardinality(String) has compressed them better. String is slightly worse, but this is likely due to the short strings we hold their lengths, which take up a lot of space and are poorly compressed. <\/p>\n

If we take PhoneModel, there are 48,000 \u2014 already more, and the differences between String and LowCardinality(String) are almost negligible. For the URL, we also saved just 2 GB \u2014 I don\u2019t think we should rely on this. <\/p>\n

Performance Speed Assessment<\/h3>\n

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

Now let's assess the performance speed. To evaluate this, I used a dataset describing taxi rides in New York. It tilg\u00e6ngelig<\/a><\/noindex> is on GitHub. It contains just over one billion rides. It reflects location, start and end time of the ride, payment method, number of passengers, and even the type of taxi \u2014 green, yellow, and Uber. <\/p>\n

\"Optimering
\n
\nI made the first query quite simple \u2014 I asked where taxis are most frequently ordered from. To do this, we need to take the location from where the orders were placed, group it by that, and calculate the count function. Here\u2019s what ClickHouse returns. <\/p>\n

\"Optimering
\n
\nTo measure the query processing speed, I created three tables with the same data, but 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 its GROUP BY optimization. <\/p>\n

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

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

N\u00e5r man arbejder med Enum er der et mere globalt problem. Hvis vi \u00f8nsker at optimere det, skal vi g\u00f8re det i hver eneste del af koden. Lad os antage, at vi har skrevet en ny funktion \u2014 man skal n\u00f8dvendigvis finde en optimering for Enum. Men i LowCardinality er alt optimeret som standard.<\/p>\n

\"Optimering
\n
\nLad os se p\u00e5 den seneste foresp\u00f8rgsel, som er mere kunstig. Vi vil blot beregne hash-funktionen for vores placering. Hash-funktionen er en ret langsom foresp\u00f8rgsel, da den tager tid, s\u00e5 alt vil blive tre gange langsommere.<\/p>\n

\"Optimering
\n
\nLowCardinality arbejder stadig hurtigere, selvom der ikke er filtrering. Dette skyldes, at vores funktioner kun arbejder over ordlisten. Hash-beregningsfunktionen har et argument \u2014 den kan behandle f\u00e6rre data og kan ogs\u00e5 returnere LowCardinality. <\/p>\n

\"Optimering
\n
\nVores globale plan er at opn\u00e5 en driftshastighed, der ikke er lavere end String i alle tilf\u00e6lde og bevare hastigheden. Og m\u00e5ske vil vi en dag erstatte String med LowCardinality, du opdaterer ClickHouse, og alt vil fungere lidt hurtigere.
\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\udd47Optimering af strenge i ClickHouse. Rapport fra Yandex | ProHoster","description":"Den analytiske DBMS ClickHouse behandler mange forskellige strenge og forbruger ressourcer. For at fremskynde systemets ydeevne tilf\u00f8jes der konstant nye optimeringer.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/74737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=74737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/74737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/74738"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=74737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=74737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=74737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}