{"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\/sl\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","title":{"rendered":"Optimizacija nizov v ClickHouse. Predavanje Yandexa","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Analiti\u010dna SODB ClickHouse obdeluje veliko razli\u010dnih nizov, kar porablja vire. Da bi pospe\u0161ili delovanje sistema, se nenehno dodajajo nove optimizacije. Razvijalec ClickHouse Nikolaj Ko\u010detov govori o nizu podatkov, vklju\u010dno z novim tipom, LowCardinality, in pojasnjuje, kako lahko pospe\u0161imo delo z nizi. <\/p>\n

\r\n \"Predvajaj\r\n
<\/div>\r\n <\/div><\/center>
\n\u2014 Najprej se pogovorimo o tem, kako lahko shranjujemo nize.
\n<\/a><\/noindex>
\n\"Optimizacija
\n
\nImamo nize podatkov. String je privzeto dobro odmerjen, zato ga je skoraj vedno vredno uporabiti. Ima majhen Overhead \u2014 9 bajtov na en niz. \u010ce \u017eelimo, da je velikost nizov fiksna in znana vnaprej, je bolje uporabiti FixedString. V njem lahko dolo\u010dimo potrebno \u0161tevilo bajtov, kar je priro\u010dno za podatke, kot so IP-naslovi ali hash-funkcije. <\/p>\n

\"Optimizacija
\n
\nSeveda, v\u010dasih kaj upo\u010dasni delovanje. Recimo, da izvajate poizvedbo v tabeli. ClickHouse bere kar veliko podatkov, recimo s hitrostjo 100 GB\/s, pri tem pa obdeluje malo nizov. Imamo dve tabeli, ki hranita skoraj enake podatke. Iz druge tabele ClickHouse bere podatke z ve\u010djo hitrostjo, a na sekundo se preberejo trije krat manj nizov. <\/p>\n

\"Optimizacija
\n
\n\u010ce pogledamo na velikost stisnjenih podatkov, je skoraj enaka. V resnici so v tabelah zapisani isti podatki \u2014 prvi milijard \u0161tevil \u2014 le da je v prvem stolpcu zapisan kot UInt64, v drugem pa kot String. Zaradi tega drugi poizvedba dlje bere podatke z diska in jih razpakira. <\/p>\n

\"Optimizacija
\n
\nTukaj je \u0161e en primer. Predpostavimo, da obstaja vnaprej znan nabor nizov, ki je omejen na 1000 ali 10 000 in skoraj nikoli ne spremeni. V tem primeru nam ustreza tip podatkov Enum, v ClickHouse pa sta dva \u2014 Enum8 in Enum16. S shranjevanjem v Enum hitro obdelujemo poizvedbe. <\/p>\n

V ClickHouse so pospe\u0161itve za GROUP BY, IN, DISTINCT in optimizacije za nekatere funkcije, na primer za primerjavo s konstantnim nizom. Seveda se \u0161tevilke v nizu ne pretvarjajo, nasprotno, konstantni niz se pripelje do vrednosti Enum. Po tem se vse hitro primerja. <\/p>\n

Toda obstajajo tudi slabosti. Tudi \u010de poznamo natan\u010den nabor nizov, ga je v\u010dasih treba dopolniti. Pri\u0161la je nova vrstica \u2014 moramo izvesti ALTER. <\/p>\n

\"Optimizacija
\n
\nALTER za Enum v ClickHouse je optimiziran. Ne prepisujemo podatke na disku, vendar pa lahko ALTER upo\u010dasni delovanje zaradi shranjevanja struktur Enum v shemi same tabele. Zato moramo po\u010dakati na zahteve za branje iz tabele, na primer. <\/p>\n

Postavlja se vpra\u0161anje, ali lahko to izbolj\u0161amo? Verjetno ja. Strukturo Enum je mogo\u010de shraniti ne v shemi tabele, ampak v ZooKeeperju. Vendar se lahko pojavijo te\u017eave s sinhronizacijo. Na primer, ena replika je prejela podatke, druga pa ne, in \u010de ima starej\u0161i Enum, se lahko nekaj pokvari. (V ClickHouse smo skoraj kon\u010dali z neblo\u010de\u010dimi ALTER poizvedbami. Ko jih bomo dokon\u010dali, ne bo treba \u010dakati na zahteve za branje.)<\/p>\n

\"Optimizacija
\n
\nDa se izognemo te\u017eavam z ALTER Enum, lahko uporabimo zunanje slovarje ClickHouse. Spomnim, da je to struktura podatkov key-value znotraj ClickHouse, s katero lahko pridobimo podatke iz zunanjih virov, na primer iz tabel MySQL. <\/p>\n

V slovarju ClickHouse shranjujemo ve\u010d razli\u010dnih nizov, v tabeli pa so njihovi identifikatorji v obliki \u0161tevilk. \u010ce potrebujemo niz, pokli\u010demo funkcijo dictGet in delamo z njim. Po tem nam ni treba izvesti ALTER. Da dodamo nekaj v Enum, ga vstavimo v isto tabelo MySQL. <\/p>\n

Toda tu se pojavijo druge te\u017eave. Najprej neprijetna sintaksa. \u010ce \u017eelimo pridobiti niz, moramo poklicati dictGet. Drugi\u010d, pomanjkanje nekaterih optimizacij. Primerjava s stalnim nizom za slovarje ni tako hitra. <\/p>\n

Lahko pa se pojavijo te\u017eave z posodabljanjem. Predpostavimo, da smo zahtevali niz v slovarju s predpomnilnikom, vendar v predpomnilnik ni pri\u0161el. Takrat moramo po\u010dakati, da se podatki nalo\u017eijo iz zunanjega vira. <\/p>\n

\"Optimizacija
\n
\nSplo\u0161na pomanjkljivost obeh metod je, da vse klju\u010de shranjujemo na enem mestu in jih sinhroniziramo. Zakaj ne bi shranili slovarjev lokalno? Brez sinhronizacije ni te\u017eav. Slovar lahko shranimo lokalno v delu na disku. Torej smo izvedli Insert, zapisali slovar. \u010ce delamo s podatki v pomnilniku, lahko slovar zapi\u0161emo v blok podatkov, ali v del stolpca, ali v nekak\u0161en predpomnilnik, da pospe\u0161imo izra\u010dune.<\/p>\n

Slojno kodiranje nizov <\/h3>\n

\nTako smo pri\u0161li do ustvarjanja novega tipa podatkov v ClickHouse - LowCardinality. To je format shranjevanja podatkov: kako se zapisujejo na disk in kako se berejo, kako so predstavljeni v pomnilniku in shema njihove obdelave. <\/p>\n

\"Optimizacija
\n
\nNa diapozitivu se nalaze dva stupca. Desno se redovi standardno pohranjuju kao String. Vidljivo je da su to neki modeli mobilnih telefona. S lijeve strane je identi\u010dan stupac, samo tipa LowCardinality. Sastoji se od rje\u010dnika s mno\u0161tvom razli\u010ditih redova (redovi iz desnog stupca) i popisa pozicija (brojevi redova). <\/p>\n

Pomo\u0107u ove dvije strukture mo\u017ee se obnoviti izvorni stupac. Tako\u0111er postoji obratni indeks \u2014 hash-tablica koja poma\u017ee prona\u0107i poziciju u rje\u010dniku prema redu. Ona je potrebna za ubrzavanje nekih upita. Na primjer, ako \u017eelimo usporediti, potra\u017eiti red u na\u0161em stupcu ili ih spojiti. <\/p>\n

LowCardinality je parametrijski tip podataka. Mo\u017ee biti ili broj, ili ne\u0161to \u0161to se pohranjuje u obliku broja, ili niz, ili Nullable od njih. <\/p>\n

\"Optimizacija
\n
\nPosebnost LowCardinality je u tome \u0161to se mo\u017ee pohraniti za neke funkcije. Na diapozitivu je prikazan primjer upita. U prvom redu sam stvorio stupac tipa LowCardinality od String, nazvao ga S. Nadalje, upitao sam njegovo ime \u2014 ClickHouse je rekao da je to LowCardinality od String. Sve je to\u010dno.<\/p>\n

Tre\u0107i red je gotovo identi\u010dan, samo \u0161to smo pozvali funkciju length. U ClickHouse funkcija length vra\u0107a tip podataka UInt64. No, postali smo LowCardinality od UInt64. Koja je svrha?<\/p>\n

\"Optimizacija
\n
\nU rje\u010dniku su bila pohranjena imena mobilnih telefona, primijenili smo funkciju length. Sada imamo odgovaraju\u0107i rje\u010dnik, sastavljen samo od brojeva \u2014 to su duljine nizova. Stupac s pozicijama nije se promijenio. Na kraju smo obradili manje podataka i u\u0161tedjeli na vremenu upita. <\/p>\n

Mogu postojati i druge optimizacije, kao \u0161to je dodavanje jednostavnog cache-a. Tijekom izra\u010dunavanja vrijednosti funkcije mo\u017ee se zapamtiti i stvoriti ista, ne izra\u010dunavati ponovno. <\/p>\n

Tako\u0111er se mo\u017ee napraviti optimizacija GROUP BY, jer je na\u0161 stupac s rje\u010dnikom ve\u0107 djelomi\u010dno agregiran \u2014 mo\u017ee se br\u017ee izra\u010dunati vrijednost hash-funkcija i otprilike prona\u0107i bucket u koji \u0107e se staviti sljede\u0107i red. Tako\u0111er se mogu specijalizirati neke agregatne funkcije, poput uniq, jer se mo\u017ee poslati samo rje\u010dnik, dok pozicije ostaju netaknute \u2014 tako \u0107e sve raditi br\u017ee. Prve dvije optimizacije ve\u0107 smo dodali u ClickHouse.<\/p>\n

\"Optimizacija
\n
\nKaj, \u010de ustvarimo stolpec s na\u0161imi tipi podatkov in vanj vstavimo veliko slabih razli\u010dnih vrstic? Ali se na\u0161a pomnilnika ne bo prepolnila? Ne, ClickHouse ima za to dve posebni nastavitvi. Prva je low_cardinality_max_dictionary_size. To je najve\u010dja velikost slovarja, ki se lahko shrani na disk. Vstavljanje poteka tako, da, ko vstavljamo podatke, pride do nas tok vrstic, iz katerih oblikujemo velik skupni slovar. Ko slovar postane ve\u010dji od vrednosti nastavitve, zapi\u0161emo trenutni slovar na disk, preostale vrstice pa shranimo nekje \u201ena strani\u201c, blizu indeksov. Tako nikoli ne pre\u0161tejemo velikega slovarja in nimamo te\u017eav s pomnilnikom. <\/p>\n

Druga nastavitev se imenuje low_cardinality_use_single_dictionary_for_part. Predstavljajte si, da se je v prej\u0161njem sistemu, ko smo vstavili podatke, na\u0161 slovar prepolnil in smo ga zapisali na disk. Pojavi se vpra\u0161anje, zakaj zdaj ne bi oblikovali \u0161e enega enakega slovarja? <\/p>\n

Ko se bo prepolnil, ga spet zapi\u0161emo na disk in za\u010dnemo oblikovati tretjega. Ta nastavitev pravzaprav privzeto onemogo\u010da to mo\u017enost. <\/p>\n

Dejansko je veliko slovarjev lahko koristnih, \u010de \u017eelimo vstaviti neko mno\u017eico vrstic, a smo naklju\u010dno vstavili \"odpadke\". Recimo, da smo najprej vstavili slabe vrstice, nato pa dobre. Takrat se bo slovar razdelil na veliko manj\u0161ih slovarjev. Del njih bo z \"odpadki\", toda zadnji bodo z dobrimi vrsticami. In \u010de preberemo, recimo, samo zadnjo granulo, bo vse \u0161e vedno delovalo hitro. <\/p>\n

\"Optimizacija
\n
\nPreden govorimo o prednostih LowCardinality, takoj povem, da verjetno ne bomo dosegli zmanj\u0161anja podatkov na disku (\u010deprav se to lahko zgodi), ker ClickHouse stisne podatke. Obstaja privzeta mo\u017enost \u2014 LZ4. Prav tako lahko izvedemo stiskanje z ZSTD. Toda oba algoritma \u017ee izvajata slovarsko stiskanje, zato na\u0161 zunanji slovar ClickHouse ne bo veliko pomagal. <\/p>\n

Da ne bi bio neosnovan, uzeo sam neke podatke iz metrike \u2014 String, LowCardinality(String) i Enum \u2014 i sa\u010duvao ih u razli\u010ditim tipovima podataka. Rezultat su tri kolone u kojima je zabele\u017eeno milijardu redova. U prvoj koloni, CodePage, ima ukupno 62 vrednosti. I vidimo da je LowCardinality(String) postigao bolje kompresovanje. String je ne\u0161to slabiji, ali to je verovatno zbog toga \u0161to su stringovi kratki, \u010duvamo njihove du\u017eine, a one zauzimaju mnogo prostora, slabo se kompresuju. <\/p>\n

Ako uzmemo PhoneModel, ima ih 48 hiljada \u2014 ve\u0107 vi\u0161e, i razlike izme\u0111u String i LowCardinality(String) gotovo da nema. Tako\u0111e, za URL smo u\u0161tedeli samo 2 GB \u2014 mislim da ne treba da se oslanjamo na to. <\/p>\n

Procena brzine rada<\/h3>\n

\n\"Optimizacija
\nLink sa slajda<\/a><\/noindex><\/b><\/p>\n

Sada \u0107emo proceniti brzinu rada. Da bismo to uradili, koristio sam dataset sa opisima taksi vo\u017enji u Njujorku. To je je na voljo<\/a><\/noindex> na GitHub-u. U njemu je ne\u0161to vi\u0161e od milijardu vo\u017enji. Tu su prikazane lokacija, vreme po\u010detka i zavr\u0161etka vo\u017enje, na\u010din pla\u0107anja, broj putnika i \u010dak vrsta taksija \u2014 zelena, \u017euta i Uber. <\/p>\n

\"Optimizacija
\n
\nPrvi upit sam napravio prili\u010dno jednostavnim \u2014 pitao sam gde se naj\u010de\u0161\u0107e naru\u010duju taksiji. Za to je potrebno uzeti lokaciju sa koje su naru\u010deni, grupisati je po njoj i prebrojati funkciju count. ClickHouse daje neki rezultat. <\/p>\n

\"Optimizacija
\n
\nDa bismo izmerili brzinu obrade upita, napravio sam tri tabele sa istim podacima, ali za na\u0161u po\u010detnu lokaciju koristio tri razli\u010dita tipa podataka \u2014 String, LowCardinality i Enum. LowCardinality i Enum su bili pet puta br\u017ei od String. Enum je br\u017ei zato \u0161to radi sa brojevima. LowCardinality \u2014 zato \u0161to je implementirana optimizacija GROUP BY. <\/p>\n

\"Optimizacija
\n
\nHajde da jo\u0161 malo zakomplikujemo upit \u2014 pitamo gdje se nalazi najpopularniji park u Njujorku. Ponovo \u0107emo to meriti prema tome gde se naj\u010de\u0161\u0107e naru\u010duju taksiji, ali \u0107emo filtrirati samo one lokacije gde se nalazi re\u010d \"park\". Tako\u0111e, dodajemo funkciju like. <\/p>\n

\"Optimizacija
\n
\nGledamo vreme \u2014 vidimo da je Enum iznenada po\u010deo usporavati. Uz to, radi jo\u0161 sporije od standardnog tipa podataka String. To se de\u0161ava zato \u0161to funkcija like nije optimizovana za Enum. Moramo da pretvaramo na\u0161e stringove iz Enum u obi\u010dne stringove \u2014 radimo vi\u0161e posla. LowCardinality(String) nije tako\u0111e podrazumevano optimizovan, ali tu like radi nad re\u010dnikom, pa je upit ubrzan u pore\u0111enju sa String. <\/p>\n

Pri delu z Enum obstaja bolj globalen problem. \u010ce ga \u017eelimo optimizirati, moramo to storiti na vsakem mestu v kodi. Recimo, da smo napisali novo funkcijo \u2014 nujno je potrebno razviti optimizacijo za Enum. V LowCardinality pa je vse privzeto optimizirano.<\/p>\n

\"Optimizacija
\n
\nPoglejmo zadnji poizvedbo, ki je bolj umetna. Preprosto bomo izra\u010dunali hash funkcijo na\u0161e lokacije. Hash funkcija je precej po\u010dasen poizvedba, traja dolgo, zato se vse upo\u010dasni za pribli\u017eno trikrat.<\/p>\n

\"Optimizacija
\n
\nLowCardinality \u0161e vedno deluje hitreje, \u010deprav tukaj ni filtriranja. To se dogaja, ker na\u0161e funkcije delujejo samo nad slovarjem. Funkcija za izra\u010dun hasha ima en argument \u2014 obravnava lahko manj podatkov in tudi vra\u010da LowCardinality. <\/p>\n

\"Optimizacija
\n
\nNa\u0161 globalni na\u010drt je dose\u010di hitrost dela, ki ni ni\u017eja od String v vseh primerih, in ohraniti pospe\u0161ke. In morda bomo enkrat zamenjali String z LowCardinality, vi boste posodobili ClickHouse in vse bo delovalo nekoliko hitreje.
\n
Izvor: 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\udd47Optimizacija nizov v ClickHouse. Predavanje Yandexa | ProHoster","description":"Analiti\u010dna DB klikHouse obravnava \u0161tevilne razli\u010dne vrstice, kar porablja vire. Da bi pospe\u0161ili delovanje sistema, se nenehno dodajajo nove optimizacije.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/74737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=74737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/74737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/74738"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=74737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=74737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=74737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}