{"id":69568,"date":"2020-02-20T15:24:23","date_gmt":"2020-02-20T12:24:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/google-cloud-spanner-horoshij-plohoj-zloj"},"modified":"2020-03-03T16:14:50","modified_gmt":"2020-03-03T13:14:50","slug":"google-cloud-spanner-horoshij-plohoj-zloj","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","title":{"rendered":"Google Cloud Spanner: dober, slab, grd","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><b><i>Pozdravljeni, Habr\u010dani. Tradicionalno nadaljujemo z deljenjem zanimivih vsebin pred za\u010detkom novih te\u010dajev. Danes smo posebej za vas prevedli \u010dlanek o Google Cloud Spanner, priredili pa smo ga ob za\u010detku te\u010daja. <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\">\u00abAWS za razvijalce\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: dober, slab, grd\" src=\"\/wp-content\/uploads\/2020\/02\/b27b8a09543d10b078480c317553ca46.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Prvotno objavljeno na <noindex><a rel=\"nofollow\" href=\"https:\/\/www.lightspeedhq.com\/blog\/\">blogu Lightspeed HQ<\/a><\/noindex>.<\/i><\/p>\n<p>Kot podjetje, ki ponuja vrsto obla\u010dnih POS re\u0161itev za trgovce, restavracije in spletne prodajalce po vsem svetu, Lightspeed uporablja ve\u010d razli\u010dnih vrst platform baz podatkov za \u0161tevilne transakcijske, analiti\u010dne in iskalne primere. Vsaka od teh platform baz podatkov ima svoje prednosti in slabosti. Ko je Google predstavil Cloud Spanner z obetavnimi funkcijami, neviden v svetu relacijskih baz podatkov, kot so skoraj neomejena horizontalna raz\u0161irljivost in 99,999% pogodba o nivoju storitev (SLA), nismo mogli zamuditi prilo\u017enosti, da jo dobimo v na\u0161e roke!<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nDa bi dali celovit pregled na\u0161ega izkustva s Cloud Spanner ter meril, ki smo jih uporabili, bomo obravnavali naslednje teme:<\/p>\n<ol>\n<li>Na\u0161a merila<\/li>\n<li>Cloud Spanner v dveh besedah<\/li>\n<li>Na\u0161a ocena<\/li>\n<li>Na\u0161i zaklju\u010dki<\/li>\n<\/ol>\n<p>\n<img decoding=\"async\" alt=\"Google Cloud Spanner: dober, slab, grd\" src=\"\/wp-content\/uploads\/2020\/02\/29ed599362fb189283faa9215c18297a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>1. Na\u0161a merila<\/h2>\n<p>\nPreden se poglobimo v zna\u010dilnosti Cloud Spanner ter njegove podobnosti in razlike z drugimi re\u0161itvami na trgu, najprej spregovorimo o osnovnih uporabnih primerih, ki smo jih imeli v mislih, ko smo razmi\u0161ljali o tem, kje implementirati Cloud Spanner v na\u0161i infrastrukturi:<\/p>\n<ul>\n<li>Kot zamenjavo (prevladujo\u010dega) tradicionalnega re\u0161itve za SQL bazo podatkov<\/li>\n<li>Kot OLTP re\u0161itev z podporo OLAP<\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><i><b>Opomba:<\/b> Za poenostavitev in udobje primerjave ta \u010dlanek primerja Cloud Spanner z razli\u010dicami MySQL dru\u017eine re\u0161itev GCP Cloud SQL in Amazon AWS RDS.<\/i><\/p><\/blockquote>\n<p><\/p>\n<h4>Uporaba Cloud Spanner kot zamenjave tradicionalnega re\u0161itve za SQL bazo podatkov<\/h4>\n<p>\nV okolju <i>tradicionalnih <\/i>baz podatkov, ko \u010das odziva na poizvedbo v bazo podatkov pribli\u017ea ali celo prese\u017ee vnaprej dolo\u010dene mejne vrednosti aplikacije (predvsem zaradi pove\u010danega \u0161tevila uporabnikov in\/ali poizvedb), obstaja ve\u010d na\u010dinov za zmanj\u0161anje \u010dasa odziva na sprejemljive ravni. Vseeno pa ve\u010dina teh re\u0161itev vklju\u010duje ro\u010dno posredovanje.<\/p>\n<p>Na primer, prvi korak, ki ga je treba narediti, je, da se osredoto\u010dite na razli\u010dne parametre baze podatkov, povezane z zmogljivostjo, in jih prilagodite, da se \u010dim bolje ujemajo s scenariji uporabe aplikacij. \u010ce to ne zadostuje, lahko izberete vertikalno ali horizontalno skaliranje baze podatkov.<\/p>\n<p>Vertikalno skaliranje aplikacije pomeni nadgradnjo instance stre\u017enika, obi\u010dajno z dodajanjem ve\u010d procesorjev\/jedrov, ve\u010d RAM-a, hitrej\u0161ih shranjevanj itd. Dodajanje ve\u010d strojnih virov prina\u0161a pove\u010danje zmogljivosti baze podatkov, merjeno predvsem v transakcijah na sekundo in zakasnitvah transakcij za sisteme OLTP. Relacijski sistemi podatkovnih baz (ki uporabljajo ve\u010dnitni pristop), kot je MySQL, se dobro vertikalno skalirajo.<\/p>\n<p>Ta pristop ima ve\u010d pomanjkljivosti, najobstojnej\u0161a pa je najve\u010dja velikost stre\u017enika na trgu. Ko dose\u017eete mejo najve\u010dje instance stre\u017enika, ostane le \u0161e ena pot: horizontalno skaliranje.<\/p>\n<p>Horizontalno skaliranje je pristop, pri katerem se klastru dodajajo novi stre\u017eniki, da se idealno linearno pove\u010duje zmogljivost z dodajanjem \u0161tevila stre\u017enikov. Ve\u010dina <i>tradicionalnih <\/i>sistemov podatkovnih baz slabo horizontalno skalira ali pa se sploh ne skalira. Na primer, MySQL se lahko horizontalno skalira za operacije branja, tako da doda slave-bralnike, ne more pa se horizontalno skalirati za operacije pisanja.<\/p>\n<p>Po drugi strani pa lahko Cloud Spanner zaradi svoje narave enostavno horizontalno skalira z minimalnim posegom.<\/p>\n<p>Funkcionalna<i> baza podatkov kot storitev<\/i> mora biti ocenjena z razli\u010dnih vidikov. Kot osnovo smo vzeli najpopularnej\u0161o obla\u010dno bazo podatkov \u2014 Google, GCP Cloud SQL in Amazon, AWS RDS. Pri na\u0161i oceni smo se osredoto\u010dili na naslednje kategorije:<\/p>\n<ul>\n<li>Ujemanje funkcij: raz\u0161iritev SQL, DDL, DML; knji\u017enice povezav\/konectorji, podpora transakcijam in tako naprej.<\/li>\n<li>Podpora razvoju: enostavnost razvoja in testiranja.<\/li>\n<li>Podpora za upravljanje: upravljanje primeri \u2014 na primer, navzgor\/navzdol skaliranje in nadgradnja primerov; SLA, varnostno kopiranje in obnova; varnost\/nadzor dostopa.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Uporaba Cloud Spanner kot re\u0161itve OLTP s podporo OLAP<\/h4>\n<p>\n\u010ceprav Google izrazito ne trdi, da je Cloud Spanner namenjen analiti\u010dnemu obdelovanju, deli nekatere lastnosti z drugimi mehanizmi, kot sta Apache Impala &amp; Kudu in YugaByte, ki so namenjeni OLAP obremenitvam.<\/p>\n<p>Tudi \u010de bi obstajala le majhna verjetnost, da je Cloud Spanner vklju\u010dil dosledno horizontalno raz\u0161irljiv HTAP (hibridna transakcijska\/analiti\u010dna obdelava) z (bolj ali manj) uporabnim nizom funkcij OLAP, menimo, da bi to zaslu\u017eilo na\u0161o pozornost.<\/p>\n<p>Ob tem v mislih smo preu\u010dili naslednje kategorije:<\/p>\n<ul>\n<li>Nalaganje podatkov, indeksi in podpora za particioniranje<\/li>\n<li>U\u010dinkovitost poizvedb in DML<\/li>\n<\/ul>\n<p><\/p>\n<h2>2. Cloud Spanner v dveh besedah<\/h2>\n<p>\nGoogle Spanner je klasterski sistem za upravljanje relacijskih podatkovnih baz (RDBMS), ki ga Google uporablja za ve\u010d svojih storitev. Google ga je odprl za uporabnike Google Cloud Platform na za\u010detku leta 2017.<\/p>\n<p>Tukaj je nekaj lastnosti Cloud Spanner:<\/p>\n<ul>\n<li>Mo\u010dno dosledno raz\u0161irljiv klaster RDBMS: uporablja strojno sinhronizacijo \u010dasa za zagotavljanje doslednosti podatkov.<\/li>\n<li>Podpora za transakcije preko tabel: transakcije lahko zajemajo ve\u010d tabel \u2014 ni nujno omejiti se na eno samo tabelo (za razliko od Apache HBase ali Apache Kudu).<\/li>\n<li>Tabele na osnovi primarnega klju\u010da: vse tabele morajo imeti dolo\u010den primarni klju\u010d (PK), ki je lahko sestavljen iz ve\u010d stolpcev tabele. Podatki v tabeli so shranjeni po PK, kar omogo\u010da zelo u\u010dinkovito in hitro iskanje po PK. Kot druge sisteme, ki temeljijo na PK, je treba implementacijo oblikovati ob upo\u0161tevanju vnaprej na\u010drtovanih uporabni\u0161kih primerov, da se dose\u017ee <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/docs\/schema-and-data-model\">najbolj\u0161a zmogljivost<\/a><\/noindex>.<\/li>\n<li>Izmenjive tabele: tabele mogu imati fizi\u010dke zavisnosti jedna od druge. Redovi podtabele mogu biti povezani sa redovima roditeljske tabele. Ovaj pristup ubrzava pretra\u017eivanje odnosa koji se mogu definisati u fazi modeliranja podataka, na primer, prilikom zajedni\u010dkog sme\u0161taja klijenata i njihovih faktura.<\/li>\n<li>Indeksi: Cloud Spanner podr\u017eava sekundarne indekse. Indeks se sastoji od indeksiranih kolona i svih kolona PK. Ako je potrebno, indeks mo\u017ee sadr\u017eavati i druge neindeksirane kolone. Indeks mo\u017ee biti izmenjen u odnosu na roditeljsku tabelu za ubrzavanje upita. Na indekse se primenjuju odre\u0111ena ograni\u010denja, kao \u0161to je maksimalan broj dodatnih kolona koje se \u010duvaju u indeksu. Tako\u0111e, upiti preko indeksa mogu biti manje direktni nego u drugim RDBMS-ovima.<\/li>\n<\/ul>\n<p>\n<i>\u201eCloud Spanner automatski bira indeks samo u retkim slu\u010dajevima. Konkretno, Cloud Spanner ne bira sekundarni indeks automatski ako upit zahteva bilo koje kolone koje nisu sa\u010duvane u <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/docs\/secondary-indexes\">indeksu <\/a><\/noindex>\u00bb.<\/i><\/p>\n<ul>\n<li>Sporazum o nivou usluge (SLA): implementacija u jednoj regiji sa SLA od 99,99%; vi\u0161eregionalne implementacije sa SLA od 99,999%. Iako je sam sporazum o nivou usluge samo sporazum, a ne neka garancija, verujem da zaposleni u Google-u zaista imaju neke ta\u010dne podatke da bi mogli da daju tako ozbiljno tvrdnju. (Za informacije, 99,999% zna\u010di 26,3 sekunde nedostupnosti usluge mese\u010dno.)<\/li>\n<li>Vi\u0161e: <noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/\">https:\/\/cloud.google.com\/spanner\/<\/a><\/noindex><\/li>\n<\/ul>\n<p><\/p>\n<blockquote><p><i><b>Opomba:<\/b> Projekat Apache Tephra dodaje pro\u0161irenu podr\u0161ku za transakcije u Apache HBase (tako\u0111e sada implementiran u Apache Phoenix kao beta verzija).<\/i><\/p><\/blockquote>\n<p><\/p>\n<h2>3. Na\u0161a ocena<\/h2>\n<p>\nDakle, svi smo \u010ditali tvrdnje Google-a o prednostima Cloud Spanner-a \u2014 prakti\u010dno neograni\u010deno horizontalno skaliranje uz visok nivo doslednosti i veoma visok SLA. Iako su ovi zahtevi, u svakom slu\u010daju, izuzetno te\u0161ki za postizanje, na\u0161 cilj nije bio da ih opovrgavamo. Umesto toga, fokusirajmo se na druge stvari koje brinu ve\u0107inu korisnika baza podataka: jasno\u0107a i jednostavnost kori\u0161\u0107enja.<\/p>\n<h4>Oceni smo Cloud Spanner kao zamenu za Sharded MySQL<\/h4>\n<p>\nGoogle Cloud SQL in Amazon AWS RDS sta najbolj priljubljena OLTP podatkovna skladi\u0161\u010da na trgu oblakov in imata zelo \u0161iroko izbiro funkcij. Vendar pa, da bi lahko skalirali te podatkovne baze preko velikosti enega vozli\u0161\u010da, morate izvajati delitev aplikacij. Tak\u0161en pristop prina\u0161a dodatno kompleksnost tako za aplikacije kot za upravljanje. Oglejali smo si, kako Spanner ustreza scenariju zdru\u017eitve ve\u010d segmentov v en instan\u010dni model in katere funkcije (\u010de sploh) boste morda morali opustiti.<\/p>\n<h4>Podpora za SQL, DML in DDL, pa tudi za priklju\u010dek in knji\u017enice?<\/h4>\n<p>\nNajprej, ko za\u017eenete katero koli podatkovno bazo, morate ustvariti podatkovni model. \u010ce menite, da lahko pove\u017eete JDBC Spanner s svojim najljub\u0161im SQL orodjem, boste odkrili, da lahko podatke dostopate z njegovo pomo\u010djo, vendar ne morete uporabljati za ustvarjanje tabel ali spreminjanje (DDL) ali katerekoli operacije vstavljanja\/posodabljanja\/brisanja (DML). Uradni JDBC iz Google ne podpira nobenega od obeh.<\/p>\n<blockquote><p><i>\u201eTrenutno gonilniki ne podpirajo DML ali DDL operacij.\u201c<\/i><br \/>\nDokumentacija Spanner<\/p><\/blockquote>\n<p>\nS konzolo GCP situacija ni bolj\u0161a - lahko po\u0161iljate le SELECT poizvedbe. Na sre\u010do obstaja JDBC gonilnik s podporo za DML in DDL iz skupnosti, vklju\u010dno s transakcijami. <noindex><a rel=\"nofollow\" href=\"http:\/\/github.com\/olavloite\/spanner-jdbc\">github.com\/olavloite\/spanner-jdbc<\/a><\/noindex>. \u010ceprav je ta gonilnik izjemno koristen, presene\u010da odsotnost lastnega JDBC gonilnika od Google. Na sre\u010do Google ponuja precej \u0161iroko podporo za odjemalske knji\u017enice (na podlagi gRPC): C#, Go, Java, node.js, PHP, Python in Ruby.<\/p>\n<p>Skoraj obvezna uporaba lastnih API vmesnikov Cloud Spanner (zaradi pomanjkanja DDL in DML v JDBC) prina\u0161a dolo\u010dene omejitve za povezane podro\u010dja kode, kot so skladi\u0161\u010da povezav ali ogrodja za povezovanje podatkov (na primer, Spring MVC). Na splo\u0161no pri uporabi JDBC lahko prosto izbirate svoj najljub\u0161i skladi\u0161\u010de povezav (na primer, HikariCP, DBCP, C3PO itd.), ki je testirano in dobro deluje. V primeru lastnih API Spanner moramo zaneseti na ogrodja\/skupe povezovanja\/seje, ki smo jih ustvarili sami.<\/p>\n<p>Zasnova, usmerjena na primarni klju\u010d (PK), omogo\u010da Cloud Spannerju zelo hitro dostopanje do podatkov preko PK, vendar prav tako povzro\u010da nekatere te\u017eave pri poizvedbah.<\/p>\n<ul>\n<li>Ne morete posodobiti vrednosti primarnega klju\u010da; najprej morate izbrisati zapis z izvirnim PK in ga znova vstaviti z novo vrednostjo. (To je podobno drugim PK usmerjenim bazam podatkov\/mehanizmom shranjevanja.)<\/li>\n<li>Vsi operaterji UPDATE in DELETE morajo dolo\u010diti PK v WHERE, zato ne more biti praznih operaterjev DELETE all - vedno mora biti podpoizvedba, na primer: UPDATE xxx WHERE id IN (SELECT id FROM table1)<\/li>\n<li>Pomanjkanje mo\u017enosti avtoinkrementa ali \u010desa podobnega, kar dolo\u010da zaporedje za polje PK. Da to deluje, mora ustrezna vrednost biti ustvarjena na strani aplikacije.<\/li>\n<\/ul>\n<p><\/p>\n<h4>Sekundarni indeksi?<\/h4>\n<p>\nGoogle Cloud Spanner ima vgrajeno podporo za sekundarne indekse. To je zelo prijetna funkcija, ki ni vedno prisotna v drugih tehnologijah. Apache Kudu trenutno sploh ne podpira sekundarnih indeksov, medtem ko Apache HBase ne podpira indeksov neposredno, jih pa lahko dodaja preko Apache Phoenix.<\/p>\n<p>Indekse v Kudu in HBase lahko modeliramo kot lo\u010deno tabelo z razli\u010dno sestavo primarnih klju\u010dev, vendar mora atomarnost operacij, ki jih izvajamo s star\u0161evsko tabelo in povezanimi indeksnimi tabelami, potekati na ravni aplikacij in ni trivialna pri pravilni izvedbi.<\/p>\n<p>Kot je omenjeno v pregledu Cloud Spanner, se njegovi indeksi lahko razlikujejo od indeksov MySQL. Zato je treba biti \u0161e posebej previden pri sestavljanju poizvedb in profiliranju, da zagotovimo uporabo ustreznega indeksa tam, kjer je to potrebno.<\/p>\n<h4>Pogledi?<\/h4>\n<p>\nZelo priljubljen in koristen objekt v bazi podatkov so pogledi. Lahko so koristni za veliko \u0161tevilo uporabni\u0161kih primerov; moja dva najljub\u0161a sta raven logi\u010dne abstrakcije in raven varnosti. Na \u017ealost Cloud Spanner NE podpira pogledov. Vendar nas to le delno omejuje, saj za dovoljenja \u0434\u043e\u0441\u0442\u0443\u043f\u0430 ni podrobnosti na ravni stolpcev, kjer bi lahko bili pogledi sprejemljiva re\u0161itev.<\/p>\n<p>V dokumentaciji Cloud Spanner v razdelku, ki podrobno opisuje kvote in omejitve (<noindex><a rel=\"nofollow\" href=\"https:\/\/cloud.google.com\/spanner\/quotas\">spanner\/quotas<\/a><\/noindex>), vklju\u010dno s tem, da obstaja eno, ki je lahko problemati\u010dno za nekatere aplikacije: Cloud Spanner ima privzeto omejitev najve\u010d 100 baz podatkov na instanco. O\u010ditno je, da lahko to postane resna ovira za bazo podatkov, namenjeno \u0161irjenju na ve\u010d kot 100 baz podatkov. Na sre\u010do smo po pogovoru z na\u0161im tehni\u010dnim predstavnikom Googla ugotovili, da se ta omejitev lahko pove\u010da skoraj do poljubne vrednosti prek Googleove podpore.<\/p>\n<h4>Podpora za razvoj?<\/h4>\n<p>\nCloud Spanner ponuja precej dobro podporo programskim jezikom za delo z njegovim API-jem. Uradno podprte knji\u017enice vklju\u010dujejo C#, Go, Java, node.js, PHP, Python in Ruby. Dokumentacija je dovolj podrobna, a tako kot pri drugih naprednih tehnologijah je skupnost precej majhna v primerjavi z najpopularnej\u0161imi tehnologijami baz podatkov, kar lahko povzro\u010di dalj\u0161e \u010dase re\u0161evanja manj pogostih primerov uporabe ali te\u017eav.<\/p>\n<h4>Kaj pa podpora za lokalni razvoj?<\/h4>\n<p>\nNismo na\u0161li na\u010dina za ustvarjanje instance Cloud Spanner v lokalnem okolju. Najbli\u017eje, kar smo dobili, je Docker slika. <noindex><a rel=\"nofollow\" href=\"https:\/\/hub.docker.com\/r\/cockroachdb\/cockroach\">CockroachDB<\/a><\/noindex>, ki je v osnovi podobna, a se v praksi mo\u010dno razlikuje. Na primer, CockroachDB lahko uporablja PostgreSQL JDBC. Ker mora biti razvojno okolje \u010dim bli\u017eje delovnemu okolju, Cloud Spanner ni idealen, saj se je treba zana\u0161ati na popolno instanco Spanner. Za zmanj\u0161anje stro\u0161kov lahko izberete instanco za eno regijo.<\/p>\n<h4>Podpore za administracijo?<\/h4>\n<p>\nUstvarjanje instance Cloud Spanner je zelo preprosto. Preprosto izberete med ustvarjanjem ve\u010dregijske ali instance za eno regijo, navedete regijo(e) in \u0161tevilo vozli\u0161\u010d. Kmalu po manj kot minuti bo instanca zagnana in pripravljena za delo.<\/p>\n<p>Nekatere osnovne metrike so neposredno dostopne na strani Spanner v konzoli Google. Podrobnej\u0161i pregledi so na voljo prek Stackdriverja, kjer lahko tudi nastavite mejne vrednosti metrik in politike obve\u0161\u010danja.<\/p>\n<h4>Dostop do virov?<\/h4>\n<p>\nMySQL ponuja obse\u017ene in zelo podrobne nastavitve dovoljenj\/rol uporabnikov. Enostavno je mogo\u010de nastaviti dostop do dolo\u010dene tabele ali celo le do podmno\u017eice njenih stolpcev. Cloud Spanner uporablja orodje Google Identity &amp; Access Management (IAM), ki omogo\u010da dolo\u010danje politik in dovoljenj le na zelo visoki ravni. Najbolj podroben variants je dovoljenje na ravni baze podatkov, ki ne ustreza ve\u010dini proizvodnih primerov. To omejitev vas prisili, da dodate dodatne varnostne ukrepe v va\u0161o kodo, infrastrukturo ali oboje, da prepre\u010dite nepoobla\u0161\u010den dostop do virov Spanner.<\/p>\n<h4>Varnostne kopije?<\/h4>\n<p>\nPreprosto re\u010deno, varnostne kopije v Cloud Spanner ne obstajajo. \u010ceprav visoki zahtevki Google SLA lahko zagotovijo, da ne boste izgubili podatkov zaradi okvar strojne opreme ali baz podatkov, \u010dlove\u0161kih napak, napak aplikacij itd. Vsi poznamo pravilo: visoka razpolo\u017eljivost ne nadomesti razumne strategije varnostnega kopiranja. Trenutno je edini na\u010din varnostnega kopiranja podatkov programska pretok podatkov iz baze v lo\u010deno shranjevanje.<\/p>\n<h4>U\u010dinkovitost poizvedb?<\/h4>\n<p>\nZa nalaganje podatkov in testiranje poizvedb smo uporabili Yahoo! Cloud Serving Benchmark. V spodnji tabeli je prikazana delovna obremenitev B YCSB s razmerjem branja 95 % in pisanja 5 %.<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: dober, slab, grd\" src=\"\/wp-content\/uploads\/2020\/02\/8fca14875af33c8ed3cd04b602c52b78.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>* Obremenitveni test je bil izveden na ra\u010dunalni\u0161kem motorju (CE) n1-standard-32 (32 vCPU, 120 GB pomnilnika), testni instan\u010dni nikoli ni bil ozko grlo pri testih.<\/i><br \/>\n<i>** Maksimalno \u0161tevilo niti v enem primeru YCSB je 400. Na splo\u0161no je bilo potrebno zagnati \u0161est vzporednih instanc YCSB testov, da bi dobili skupno 2400 niti.<\/i><\/p>\n<p>Gledaju\u0107i rezultate testova, posebno kombinaciju optere\u0107enja procesora i TPS-a, jasno vidimo da se Cloud Spanner prili\u010dno dobro skalira. Veliko optere\u0107enje koje stvara veliki broj niti kompenzuje se ve\u0107im brojem \u010dvorova u Cloud Spanner klasteru. Iako izgleda da je latencija prili\u010dno visoka, posebno pri radu sa 2400 niti, da bi se dobili precizniji podaci moglo bi biti potrebno ponoviti testiranje sa 6 manjim instancama ra\u010dunalnog motora. Svaka instanca \u0107e pokretati jedan YCSB test umesto jedne velike CE instance sa 6 paralelnih testova. Tako \u0107e biti lako razlikovati latencije zahteva Cloud Spanner-a i latencije koje dodaje mre\u017ena veza izme\u0111u Cloud Spanner-a i CE instance na kojoj se test izvr\u0161ava.<\/p>\n<h3>Kako Cloud Spanner funkcioni\u0161e kao OLAP?<\/h3>\n<p><\/p>\n<h4>Particionisanje?<\/h4>\n<p>\nDeljenje podataka na fizi\u010dki i\\\/ili logi\u010dki nezavisne segmente, nazvane particije, vrlo je popularna koncepcija koja je prisutna u ve\u0107ini OLAP mehanizama. Particije mogu zna\u010dajno pobolj\u0161ati performanse upita i odr\u017eavanje baze podataka. Dalje istra\u017eivanje particija bi se produbilo u poseban \u010dlanak (\u010dlanake), stoga hajde da samo pomenemo va\u017enost postojanja \u0161eme particionisanja i sub-particionisanja. Mogu\u0107nost deljenja podataka na particije, a \u010dak i dalje na sub-particije je klju\u010d za performanse analiti\u010dkih upita.<\/p>\n<p>Cloud Spanner ne podr\u017eava particije kao takve. On deli podatke unutar na takozvane <i>split<\/i>-ove na osnovu opsega primarnog klju\u010da. Deljenje se automatski vr\u0161i radi ravnote\u017ee optere\u0107enja u Cloud Spanner klasteru. Vrlo korisna funkcija Cloud Spanner-a je razdvajanje osnovnog optere\u0107enja roditeljske tabele (tabele koja se ne prepli\u0107e sa drugom). Spanner automatski odre\u0111uje da li <i>split <\/i>sadr\u017ei podatke koji se \u010ditaju \u010de\u0161\u0107e od podataka u drugim <i>split<\/i>-ima, i mo\u017ee doneti odluku o daljem deljenju. Tako sada mo\u017ee biti uklju\u010deno vi\u0161e \u010dvorova u upitu, \u0161to tako\u0111e efikasno pove\u0107ava propusnost.<\/p>\n<h4>U\u010ditavanje podataka?<\/h4>\n<p>\nNa\u010din Cloud Spanner za velike podatke je isti kao i pri uobi\u010dajenoj u\u010ditavanju. Da biste postigli maksimalnu performansu, morate slediti nekoliko preporuka, uklju\u010duju\u0107i:<\/p>\n<ul>\n<li>Sortirajte va\u0161e podatke prema primarnom klju\u010du.<\/li>\n<li>Podelite ih na 10*<i>broj \u010dvorova<\/i> odvojenih sekcija.<\/li>\n<li>Kreirajte skup radnih zadataka koji u\u010ditavaju podatke paralelno.<\/li>\n<\/ul>\n<p>\nPri takvom u\u010ditavanju podataka koriste se svi \u010dvorovi Cloud Spanner-a.<\/p>\n<p>Koristili smo optere\u0107enje A YCSB za generisanje skupa podataka od 10M redova.<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: dober, slab, grd\" src=\"\/wp-content\/uploads\/2020\/02\/89b9c0353716be2d389b3e8da82781ad.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>* Optere\u0107enje je testirano na ra\u010dunarskom motoru n1-standard-32 (32 vCPU, 120 GB RAM), a test instanca nikada nije bila usko grlo u testovima.<br \/>\n** Postavljanje na 1 \u010dvor se ne preporu\u010duje za bilo kakvo proizvodno optere\u0107enje.<\/i><\/p>\n<p>Kao \u0161to je ranije pomenuto, Cloud Spanner automatski obra\u0111uje deljenje na osnovu njihovog optere\u0107enja, tako da se rezultati pobolj\u0161avaju nakon nekoliko uzastopnih ponavljanja testa. Rezultati predstavljeni ovde su najbolji rezultati koje smo dobili. Gledaju\u0107i na gornje brojeve, mo\u017eemo videti kako Cloud Spanner (dobro) skalira sa pove\u0107anjem broja \u010dvorova u klasteru. Brojevi koji se isti\u010du predstavljaju izuzetno niske prose\u010dne latencije, \u0161to kontrastira sa rezultatima me\u0161anih optere\u0107enja (95% za \u010ditanje i 5% za pisanje), kako je opisano u prethodnom odeljku.<\/p>\n<h4>Skaliranje?<\/h4>\n<p>\nPove\u0107avanje i smanjenje broja \u010dvorova Cloud Spanner-a je zadatak koji se obavlja jednim klikom. Ako \u017eelite brzo u\u010ditati podatke, mo\u017eete razmotriti pove\u0107anje instance do maksimuma (u na\u0161em slu\u010daju to je bilo 25 \u010dvorova u regionu US-EAST), a zatim smanjiti broj \u010dvorova koji odgovaraju va\u0161em uobi\u010dajenom optere\u0107enju, nakon \u0161to su svi podaci u bazi podataka, imaju\u0107i u vidu ograni\u010denje od 2 TB\/\u010dvor.<\/p>\n<p>Podsetili smo se na ovo ograni\u010denje \u010dak i sa mnogo manjom bazom podataka. Nakon nekoliko prolaza optere\u0107enja testova, na\u0161a baza podataka imala je veli\u010dinu od oko 155 GB, a prilikom smanjenja na instancu od 1 \u010dvora dobili smo slede\u0107u gre\u0161ku:<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: dober, slab, grd\" src=\"\/wp-content\/uploads\/2020\/02\/4a46c97e7943b5105bf178316dc67433.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUspe\u0161no smo smanjili sa 25 na 2 instance, ali smo zapeli na dva \u010dvora.<\/p>\n<p>Pove\u010danje i smanjenje broja \u010dvorova u Cloud Spanner klasteru mo\u017ee se automatizovati pomo\u0107u REST API-ja. To mo\u017ee biti posebno korisno za smanjenje preoptere\u0107enja sistema tokom perioda velike aktivnosti.<\/p>\n<h4>Performanse OLAP upita?<\/h4>\n<p>\nPrvobitno smo planirali posvetiti zna\u010dajno vreme na\u0161oj proceni Spanner-a u ovom delu. Nakon nekoliko SELECT COUNT upita, odmah smo shvatili da \u0107e testiranje biti kratko i da Spanner NE\u0107e biti pogodan kao OLAP motor. Bez obzira na broj \u010dvorova u klasteru, jednostavno prebrojavanje broja redova u tabeli koja ima 10M redova trajalo je od 55 do 60 sekundi. Pored toga, svaki upit koji je zahtevao ve\u0107i obim memorije za \u010duvanje me\u0111urezultata zavr\u0161io je gre\u0161kom OOM.<\/p>\n<p><code>SELECT COUNT(DISTINCT(field0)) FROM usertable; \u2014 (10M jedinstvenih vrednosti) -&gt; SpoolingHashAggregateIterator je ponestalo memorije tokom nove linije.<\/code><\/p>\n<p>Neke brojke za TPC-H upite mogu se prona\u0107i u \u010dlanku Todda Lipkona <noindex><a rel=\"nofollow\" href=\"https:\/\/kudu.apache.org\/2017\/10\/23\/nosql-kudu-spanner-slides.html\">Nosql-kudu-spanner-slides.html<\/a><\/noindex>, slajdovi 42 i 43. Ove brojke se sla\u017eu sa na\u0161im sopstvenim rezultatima (na\u017ealost).<\/p>\n<p><img decoding=\"async\" alt=\"Google Cloud Spanner: dober, slab, grd\" src=\"\/wp-content\/uploads\/2020\/02\/d070c839bbc62b1ba1bebbaf64127e93.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>4. Na\u0161a zapa\u017eanja<\/h4>\n<p>\nUzimaju\u0107i u obzir trenutno stanje funkcija Cloud Spanner-a, te\u0161ko je zamisliti njegovu jednostavnu zamenu za postoje\u0107e OLTP re\u0161enje, posebno kada va\u0161e potrebe prevazi\u0111u njegove mogu\u0107nosti. Bilo bi potrebno ulo\u017eiti zna\u010dajno vreme kako bi se izgradilo re\u0161enje uzimaju\u0107i u obzir nedostatke Cloud Spanner-a.<\/p>\n<p>Kada smo po\u010deli evaluaciju Cloud Spanner-a, o\u010dekivali smo da \u0107e njegove funkcije upravljanja biti na nivou ili barem ne tako daleko od drugih Google SQL re\u0161enja. Me\u0111utim, bili smo iznena\u0111eni potpunim nedostatkom rezervnih kopija i veoma ograni\u010denim pristupom resursima. Da ne spominjemo nedostatak prikaza, odsustvo lokalnog razvojnog okru\u017eenja, nepodr\u017eane sekvence, JDBC bez podr\u0161ke za DML i DDL i tako dalje.<\/p>\n<p>Torej, kam naj gre tisti, ki potrebuje raz\u0161iritev transakcijske baze podatkov? Zdi se, da trenutno na trgu ni enotne re\u0161itve, ki bi ustrezala vsem primerom uporabe. Na voljo je ve\u010d re\u0161itev s closed in open source (nekatere so omenjene v tem \u010dlanku), od katerih ima vsaka svoje prednosti in slabosti, vendar nobena ne ponuja SaaS z SLA 99,999% in visoko stopnjo doslednosti. \u010ce je visok nivo SLA va\u0161a glavna prioriteta in niste nagnjeni k razvoju lastne re\u0161itve za ve\u010d obla\u010dnih okolij, bi lahko bil Cloud Spanner re\u0161itev, ki jo i\u0161\u010dete. Vendar pa morate biti obve\u0161\u010deni o vseh njegovih omejitvah.<\/p>\n<p>Za po\u0161tenost je treba omeniti, da je Cloud Spanner bil na voljo javnosti \u0161ele spomladi 2017, zato je razumljivo pri\u010dakovati, da se lahko nekateri njegovi trenutni pomanjkljivosti s\u010dasoma odpravijo (upajmo), in ko se to zgodi, bi lahko spremenili igro. Navsezadnje je Cloud Spanner ve\u010d kot le stranski projekt za Google. Google ga uporablja kot osnovo za druge Google proizvode. Ko je Google nedavno zamenjal Megastore v Google Cloud Storage z Cloud Spanner, je to omogo\u010dilo, da je Google Cloud Storage postalo strogo dosledno za sezname objektov na svetovni ravni (kar \u0161e vedno ne velja za <noindex><a rel=\"nofollow\" href=\"https:\/\/cloudplatform.googleblog.com\/2018\/02\/how-Google-Cloud-Storage-offers-strongly-consistent-object-listing-thanks-to-Spanner.html\">Amazonov<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/cloudplatform.googleblog.com\/2018\/02\/how-Google-Cloud-Storage-offers-strongly-consistent-object-listing-thanks-to-Spanner.html\">S3<\/a><\/noindex>).<\/p>\n<p>Torej, upanje \u0161e obstaja\u2026 upamo.<\/p>\n<p>S tem je vse. Tako kot avtor \u010dlanka tudi mi \u0161e naprej upamo, kaj pa vi mislite o tem? Pi\u0161ite v komentarjih.<\/p>\n<p><b>Vse zainteresirane vabimo na obisk na\u0161ega <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\">brezpla\u010dni spletni seminar<\/a><\/noindex> v okviru katerega bomo podrobno predstavili te\u010daj<noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/eoP2\/\"> \u00abAWS za razvijalce\u00bb<\/a><\/noindex> od OTUS.<\/b><br \/>\n<br \/>Izvor: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/489012\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u044c\u043d\u043e \u0434\u043b\u044f \u0432\u0430\u0441 \u043c\u044b \u043f\u0440\u0435\u0432\u0435\u043b\u0438 \u0441\u0442\u0430\u0442\u044c\u044e \u043e Google Cloud Spanner, \u043f\u0440\u0438\u0443\u0440\u043e\u0447\u0438\u0432 \u0435\u0435 \u043a \u0437\u0430\u043f\u0443\u0441\u043a\u0443 \u043a\u0443\u0440\u0441\u0430 \u00abAWS \u0434\u043b\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432\u00bb. \u041f\u0435\u0440\u0432\u043e\u043d\u0430\u0447\u0430\u043b\u044c\u043d\u043e \u043e\u043f\u0443\u0431\u043b\u0438\u043a\u043e\u0432\u0430\u043d\u043e \u0432 \u0431\u043b\u043e\u0433\u0435 Lightspeed HQ. \u041a\u0430\u043a \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u043e\u0431\u043b\u0430\u0447\u043d\u044b\u0445 POS-\u0440\u0435\u0448\u0435\u043d\u0438\u0439 \u0434\u043b\u044f \u0440\u043e\u0437\u043d\u0438\u0447\u043d\u044b\u0445 \u0442\u043e\u0440\u0433\u043e\u0432\u0446\u0435\u0432, \u0440\u0435\u0441\u0442\u043e\u0440\u0430\u0442\u043e\u0440\u043e\u0432 \u0438 \u043e\u043d\u043b\u0430\u0439\u043d-\u043f\u0440\u043e\u0434\u0430\u0432\u0446\u043e\u0432 \u043f\u043e \u0432\u0441\u0435\u043c\u0443 \u043c\u0438\u0440\u0443, Lightspeed \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":69569,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-69568","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.4 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Google Cloud Spanner: \u0445\u043e\u0440\u043e\u0448\u0438\u0439, \u043f\u043b\u043e\u0445\u043e\u0439, \u0437\u043b\u043e\u0439 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-02-20T12:24:23+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-03T13:14:50+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Google Cloud Spanner: dober, slab, grd | ProHoster","description":"\u017divjo, Habr uporabniki. Tradicionalno nadaljujemo z deljenjem zanimivega gradiva pred za\u010detkom novih te\u010dajev.","canonical_url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","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\udd47Google Cloud Spanner: \u0445\u043e\u0440\u043e\u0448\u0438\u0439, \u043f\u043b\u043e\u0445\u043e\u0439, \u0437\u043b\u043e\u0439 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0445\u0430\u0431\u0440\u043e\u0432\u0447\u0430\u043d\u0435. \u0422\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u043f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u044b\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u043c \u0432 \u043f\u0440\u0435\u0434\u0434\u0432\u0435\u0440\u0438\u0438 \u0441\u0442\u0430\u0440\u0442\u0430 \u043d\u043e\u0432\u044b\u0445 \u043a\u0443\u0440\u0441\u043e\u0432.","og:url":"https:\/\/prohoster.info\/sl\/blog\/administrirovanie\/google-cloud-spanner-horoshij-plohoj-zloj","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-02-20T12:24:23+00:00","article:modified_time":"2020-03-03T13:14:50+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"69568","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 19:20:25","updated":"2022-09-30 15:10:07","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\/69568","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=69568"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/69568\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/69569"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=69568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=69568"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=69568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}