Sveiki, chabrovitai. Tradiciškai ir toliau dalinamės įdomia medžiaga naujų kursų pradžios išvakarėse. Šiandien, ypač jums, išvertėme straipsnį apie „Google Cloud Spanner“, skirtą sutampa su kurso pradžia .
Iš pradžių paskelbta m .
Kaip įmonė, siūlanti įvairius debesies pagrindu veikiančius POS sprendimus mažmenininkams, restoranų savininkams ir internetiniams prekybininkams visame pasaulyje, „Lightspeed“ naudoja kelių skirtingų tipų duomenų bazių platformas įvairiems operacijų, analizės ir paieškos naudojimo atvejams. Kiekviena iš šių duomenų bazių platformų turi savo stipriąsias ir silpnąsias puses. Todėl kai „Google“ rinkai pristatė „Cloud Spanner“ – daug žadančių funkcijų, kurios dar nematytos reliacinių duomenų bazių pasaulyje, pavyzdžiui, praktiškai neribotas horizontalus mastelio keitimas ir 99,999 % paslaugų lygio sutartis (SLA) , Negalėjome praleisti progos turėti ją savo rankose!
Norėdami išsamiai apžvelgti savo patirtį naudojant „Cloud Spanner“ ir taikytus vertinimo kriterijus, apžvelgsime šias temas:
- Mūsų vertinimo kriterijai
- Debesų veržliaraktis trumpai
- Mūsų įvertinimas
- Mūsų išvados
1. Mūsų vertinimo kriterijai
Prieš pasinerdami į „Cloud Spanner“ specifiką, jo panašumus ir skirtumus su kitais rinkoje esančiais sprendimais, pirmiausia pakalbėkime apie pagrindinius naudojimo atvejus, į kuriuos turėjome omenyje svarstant, kur įdiegti „Cloud Spanner“ savo infrastruktūroje:
- Kaip (vyraujančio) tradicinio SQL duomenų bazės sprendimo pakaitalas
- Kaip OLTP sprendimas su OLAP palaikymu
Pastaba: Kad būtų lengviau palyginti, šiame straipsnyje Cloud Spanner lyginamas su GCP Cloud SQL ir Amazon AWS RDS sprendimų šeimų MySQL variantais.
„Cloud Spanner“ naudojimas kaip tradicinio SQL duomenų bazės sprendimo pakaitalas
Aplinkoje tradicinis duomenų bazėse, kai atsako laikas į duomenų bazės užklausą priartėja prie iš anksto nustatytų taikomųjų programų slenksčių ar net juos viršija (visų pirma dėl vartotojų ir (arba) užklausų skaičiaus padidėjimo), yra keletas būdų, kaip sumažinti atsakymo laiką iki priimtino lygio. Tačiau dauguma šių sprendimų apima rankinį įsikišimą.
Pavyzdžiui, pirmiausia reikia peržiūrėti įvairius su našumu susijusius duomenų bazės parametrus ir suderinti juos taip, kad jie geriausiai atitiktų programos naudojimo scenarijus. Jei to nepakanka, galite pasirinkti duomenų bazės mastelį vertikaliai arba horizontaliai.
Padidinus taikomąją programą reikia atnaujinti serverio egzempliorių, paprastai pridedant daugiau procesorių / branduolių, daugiau RAM, greitesnės saugyklos ir kt. Pridėjus daugiau aparatinės įrangos išteklių, padidėja duomenų bazės našumas, pirmiausia matuojamas operacijomis per sekundę, ir operacijų delsa OLTP sistemoms. Reliacinės duomenų bazių sistemos (kurios naudoja kelių gijų metodą), pvz., MySQL, gerai apskaičiuojamos vertikaliai.
Šis metodas turi keletą trūkumų, tačiau akivaizdžiausias yra maksimalus serverio dydis rinkoje. Pasiekus didžiausią serverio egzempliorių ribą, lieka tik vienas kelias: padidinti mastelį.
Scale-out yra metodas, kuris prideda daugiau serverių į klasterį, kad idealiai padidintų našumą tiesiškai, kai pridedama daugiau serverių. Dauguma tradicinis duomenų bazių sistemų mastelis netinkamas arba visai nekeičiamas. Pavyzdžiui, „MySQL“ gali sumažinti skaitymo mastelį, pridėdama vergų skaitytuvų, bet negali sumažinti rašymo mastelio.
Kita vertus, dėl savo pobūdžio „Cloud Spanner“ gali lengvai keisti mastelį horizontaliai su minimaliu įsikišimu.
Visas funkcijas DBVS kaip paslauga turi būti vertinama iš skirtingų perspektyvų. Kaip pagrindą pasirinkome populiariausias DBVS debesyje – „Google“, GCP Cloud SQL ir „Amazon“, AWS RDS. Vertindami daugiausia dėmesio skyrėme šioms kategorijoms:
- Funkcijos atvaizdavimas: SQL apimtis, DDL, DML; jungčių bibliotekos/jungtys, operacijų palaikymas ir pan.
- Kūrimo palaikymas: paprastas kūrimas ir testavimas.
- Administravimo palaikymas: egzempliorių valdymas, pvz., padidinimas / sumažinimas ir egzempliorių atnaujinimas; SLA, atsarginė kopija ir atkūrimas; saugumo / prieigos kontrolė.
„Cloud Spanner“ naudojimas kaip OLAP įgalintas OLTP sprendimas
Nors „Google“ aiškiai nenurodo, kad „Cloud Spanner“ yra skirta analizei, ji dalijasi kai kuriais atributais su kitais varikliais, pvz., „Apache Impala & Kudu“ ir „YugaByte“, skirtais OLAP darbo krūviams.
Net jei būtų tik maža tikimybė, kad „Cloud Spanner“ įtrauks nuoseklų išplėstinį HTAP (hibridinio transakcinio / analitinio apdorojimo) variklį su (daugiau ar mažiau) tinkamu OLAP funkcijų rinkiniu, manome, kad tai nusipelno mūsų dėmesio.
Atsižvelgdami į tai, pažvelgėme į šias kategorijas:
- Duomenų įkėlimas, indeksai ir skaidymo palaikymas
- Užklausos našumas ir DML
2. Debesų veržliaraktis trumpai
„Google Spanner“ yra sugrupuota reliacinės duomenų bazės valdymo sistema (RDBMS), kurią „Google“ naudoja kelioms savo paslaugoms. „Google“ padarė ją viešai prieinamą „Google Cloud Platform“ naudotojams 2017 m. pradžioje.
Štai keletas „Cloud Spanner“ atributų:
- Labai nuoseklus, keičiamo dydžio RDBMS klasteris: naudoja aparatinės įrangos laiko sinchronizavimą, kad užtikrintų duomenų nuoseklumą.
- Kryžminių lentelių operacijų palaikymas: operacijos gali apimti kelias lenteles – nebūtinai apsiriboja viena lentele (skirtingai nei Apache HBase ar Apache Kudu).
- Pirminiu raktu pagrįstos lentelės: visose lentelėse turi būti nurodytas pirminis raktas (PC), kurį gali sudaryti keli lentelės stulpeliai. Lenteliniai duomenys saugomi kompiuterio tvarka, todėl jie yra labai efektyvūs ir greiti paieškoms kompiuteriu. Kaip ir kitų kompiuterinių sistemų atveju, norint pasiekti, diegimas turi būti modeliuojamas pagal išankstinius naudojimo atvejus .
- Dryžuotos lentelės: lentelės gali turėti fizinę priklausomybę viena nuo kitos. Antrinės lentelės eilutes galima suderinti su pagrindinės lentelės eilutėmis. Šis metodas pagreitina ryšių, kuriuos galima nustatyti duomenų modeliavimo etape, paiešką, pavyzdžiui, pateikiant klientus ir jų sąskaitas faktūras kartu.
- Indeksai: „Cloud Spanner“ palaiko antrinius indeksus. Indeksą sudaro indeksuoti stulpeliai ir visi kompiuterio stulpeliai. Pasirinktinai indekse gali būti ir kitų neindeksuotų stulpelių. Indeksą galima įterpti į pirminę lentelę, kad užklausos būtų greičiau. Indeksams taikomi keli apribojimai, pvz., maksimalus papildomų stulpelių, kuriuos galima saugoti indekse, skaičius. Be to, užklausos per indeksus gali būti ne tokios paprastos kaip kitose RDBVS.
„Cloud Spanner automatiškai pasirenka indeksą tik retais atvejais. Visų pirma, „Cloud Spanner“ automatiškai nepasirenka antrinio indekso, jei užklausa reikalauja stulpelių, kurie nėra saugomi ".
- Paslaugos lygio sutartis (SLA): diegimas viename regione su 99,99 % SLA; diegimas keliuose regionuose su 99,999 % SLA. Nors pats SLA yra tik susitarimas, o ne jokia garantija, manau, kad „Google“ žmonės turi tam tikrų duomenų, kad galėtų pareikšti tokį tvirtą teiginį. (Pavyzdžiui, 99,999 % reiškia 26,3 sekundės paslaugos prastovos per mėnesį.)
- Daugiau:
Pastaba: „Apache Tephra“ projektas prideda pažangų operacijų palaikymą „Apache HBase“ (taip pat dabar įdiegtas „Apache Phoenix“ kaip beta versija).
3. Mūsų vertinimas
Taigi, visi perskaitėme „Google“ pareiškimus apie „Cloud Spanner“ pranašumus – praktiškai neribotą horizontalų mastelį išlaikant aukštą nuoseklumą ir labai aukštą SLA. Nors šiuos teiginius bet kuriuo atveju įgyvendinti itin sunku, mūsų tikslas nebuvo jų paneigti. Vietoj to, sutelkime dėmesį į kitus dalykus, kurie rūpi daugumai duomenų bazių naudotojų: pariteto ir naudojimo patogumo.
„Cloud Spanner“ įvertinome kaip „Sharded MySQL“ pakaitalą
„Google Cloud SQL“ ir „Amazon AWS RDS“, dvi populiariausios OLTP duomenų bazės debesų rinkoje, turi labai didelį funkcijų rinkinį. Tačiau norint padidinti šių duomenų bazių mastelį, viršijantį vieno mazgo dydį, turite atlikti programų padalijimą. Šis metodas sukuria papildomą sudėtingumą tiek programoms, tiek administravimui. Pažiūrėjome, kaip „Spanner“ tinka kelių skeveldrų sujungimo į vieną egzempliorių scenarijui ir kokių funkcijų (jei tokių yra) gali tekti paaukoti.
SQL, DML ir DDL, taip pat jungties ir bibliotekų palaikymas?
Pirmiausia, pradedant nuo bet kurios duomenų bazės, reikia sukurti duomenų modelį. Jei manote, kad galite prijungti JDBC veržliaraktį prie savo mėgstamo SQL įrankio, pamatysite, kad su juo galite pateikti duomenų užklausą, bet negalite jo naudoti kurdami lentelę ar naujinimą (DDL) ar bet kokį įterpimą / atnaujinimą / ištrynimą. operacijos (DML). Oficialus Google JDBC taip pat nepalaiko.
"Šiuo metu tvarkyklės nepalaiko DML arba DDL teiginių."
Veržliarakčio dokumentacija
Su GCP konsole situacija ne ką geresnė – galite siųsti tik SELECT užklausas. Laimei, bendruomenėje yra JDBC tvarkyklė su DML ir DDL palaikymu, įskaitant operacijas . Nors ši tvarkyklė yra labai naudinga, stebina tai, kad „Google“ neturi JDBC tvarkyklės. Laimei, „Google“ siūlo gana platų klientų bibliotekos palaikymą (pagal gRPC): C#, Go, Java, node.js, PHP, Python ir Ruby.
Beveik privalomas tinkintų „Cloud Spanner“ API naudojimas (dėl DDL ir DML trūkumo JDBC sistemoje) sukelia tam tikrų apribojimų susijusioms kodo sritims, pvz., ryšių telkimui arba duomenų bazių susiejimo sistemoms (pvz., Spring MVC). Paprastai, kai naudojate JDBC, galite laisvai pasirinkti savo mėgstamą ryšio telkinį (pvz., HikariCP, DBCP, C3PO ir kt.), kuris yra patikrintas ir veikia gerai. Pasirinktinių veržliarakčių API atveju turime pasikliauti sistemomis / įrišimo / seansų telkiniais, kuriuos sukūrėme patys.
Į pirminį raktą (asmeninį kompiuterį) orientuotas dizainas leidžia „Cloud Spanner“ labai greitai pasiekti duomenis per kompiuterį, tačiau taip pat atsiranda tam tikrų užklausų problemų.
- Negalite atnaujinti pirminio rakto vertės; Pirmiausia turite ištrinti pradinį kompiuterio įrašą ir iš naujo įterpti jį su nauja verte. (Tai panašu į kitus kompiuteriui skirtus duomenų bazių / saugyklų variklius.)
- Visi sakiniai UPDATE ir DELETE turi nurodyti kompiuterį WHERE, todėl negali būti tuščių DELETE visų teiginių – visada turi būti antrinė užklausa, pvz.: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Trūksta automatinio padidinimo parinkties ar kažko panašaus, kuris nustato kompiuterio lauko seką. Kad tai veiktų, atitinkama reikšmė turi būti sukurta programos pusėje.
Antriniai indeksai?
„Google Cloud Spanner“ turi integruotą antrinių indeksų palaikymą. Tai labai graži funkcija, kuri ne visada yra kitose technologijose. „Apache Kudu“ šiuo metu visiškai nepalaiko antrinių indeksų, o „Apache HBase“ nepalaiko indeksų tiesiogiai, bet gali juos pridėti per „Apache Phoenix“.
„Kudu“ ir „HBase“ indeksus galima modeliuoti kaip atskirą lentelę su skirtinga pirminių raktų sudėtimi, tačiau operacijų, atliekamų pirminėje lentelėje ir susijusiose indeksų lentelėse, atomiškumas turi būti atliktas programos lygiu ir nėra trivialus tinkamai įgyvendinti.
Kaip minėta „Cloud Spanner“ apžvalgoje, jo indeksai gali skirtis nuo „MySQL“ indeksų. Taigi, užklausų kūrimo ir profiliavimo metu reikia būti ypač atsargiems, kad būtų užtikrinta, jog ten, kur reikia, būtų naudojamas teisingas indeksas.
Atstovavimas?
Labai populiarus ir naudingas objektas duomenų bazėje yra rodiniai. Jie gali būti naudingi daugeliu atvejų; Mano du mėgstamiausi yra loginės abstrakcijos sluoksnis ir saugos sluoksnis. Deja, „Cloud Spanner“ nepalaiko rodinių. Tačiau tai mus riboja tik iš dalies, nes nėra stulpelių lygio prieigos leidimų detalumo, kai rodiniai gali būti priimtinas sprendimas.
„Cloud Spanner“ dokumentacijoje rasite skyrių, kuriame išsamiai aprašomos kvotos ir apribojimai (), yra viena, kuri gali sukelti problemų kai kurioms programoms: „Cloud Spanner“ yra ne daugiau kaip 100 duomenų bazių vienam egzemplioriui. Akivaizdu, kad tai gali būti pagrindinė kliūtis duomenų bazei, kuri skirta daugiau nei 100 duomenų bazių. Laimei, pasikalbėję su „Google“ techniniu atstovu, sužinojome, kad per „Google“ palaikymą šią ribą galima padidinti iki beveik bet kokios vertės.
Parama vystymuisi?
„Cloud Spanner“ siūlo gana tinkamą programavimo kalbos palaikymą darbui su savo API. Oficialiai palaikomos bibliotekos yra C#, Go, Java, node.js, PHP, Python ir Ruby srityse. Dokumentacija yra gana išsami, tačiau, kaip ir su kitomis pažangiausiomis technologijomis, bendruomenė yra gana maža, palyginti su populiariausiomis duomenų bazių technologijomis, todėl gali tekti daugiau laiko praleisti retesniems naudojimo atvejams ar problemoms spręsti.
Taigi kaip dėl vietos plėtros paramos?
Neradome būdo sukurti „Cloud Spanner“ egzempliorių vietoje. Artimiausias mums yra Docker vaizdas kuris iš principo panašus, bet praktiškai labai skiriasi. Pavyzdžiui, CockroachDB gali naudoti PostgreSQL JDBC. Kadangi kūrimo aplinka turėtų būti kuo artimesnė gamybos aplinkai, „Cloud Spanner“ nėra ideali, nes reikia pasikliauti visu veržliarakčio egzemplioriumi. Norėdami sutaupyti išlaidų, galite pasirinkti vieną regiono egzempliorių.
Administracinė pagalba?
Sukurti „Cloud Spanner“ egzempliorių yra labai paprasta. Jums tereikia pasirinkti, ar sukurti kelių regionų ar vieno regiono egzempliorių, nurodyti regioną (-us) ir mazgų skaičių. Mažiau nei per minutę egzempliorius bus parengtas ir paleistas.
Keletas elementarių metrikų yra tiesiogiai pasiekiamos „Google Console“ veržliarakčio puslapyje. Išsamesni rodiniai pasiekiami naudojant „Stackdriver“, kur taip pat galite nustatyti metrikos slenksčius ir įspėjimų politiką.
Prieiga prie išteklių?
„MySQL“ siūlo plačius ir labai detalius vartotojo leidimų / vaidmenų nustatymus. Galite lengvai tinkinti prieigą prie konkrečios lentelės ar net tik jos stulpelių poaibio. „Cloud Spanner“ naudoja „Google“ tapatybės ir prieigos valdymo (IAM) įrankį, kuris leidžia nustatyti tik labai aukšto lygio politiką ir leidimus. Labiausiai detalizuota parinktis yra duomenų bazės lygio leidimas, kuris netinka daugeliu gamybos atvejų. Šis apribojimas verčia jūsų kodą, infrastruktūrą arba abu pridėti papildomų saugos priemonių, kad išvengtumėte neteisėto veržliarakčio išteklių naudojimo.
Atsarginės kopijos?
Paprasčiau tariant, „Cloud Spanner“ nėra atsarginių kopijų. Nors aukšti Google SLA reikalavimai gali užtikrinti, kad neprarasite jokių duomenų dėl aparatinės įrangos ar duomenų bazės gedimų, žmogiškųjų klaidų, programos defektų ir kt. Visi žinome taisyklę: aukštas pasiekiamumas nepakeičia išmaniosios atsarginės kopijos strategijos. Šiuo metu vienintelis būdas kurti atsargines duomenų kopijas – programiškai juos srautu perduoti iš duomenų bazės į atskirą saugojimo aplinką.
Klausti našumo?
Duomenims įkelti ir užklausoms tikrinti naudojome „Yahoo!“. Debesų aptarnavimo etalonas. Toliau pateiktoje lentelėje parodytas B YCSB darbo krūvis su 95 % skaitymo ir 5 % rašymo santykiu.
* Apkrovos testas buvo atliktas naudojant n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB atminties), o bandomasis pavyzdys niekada nebuvo bandymų kliūtis.
** Didžiausias gijų skaičius viename YCSB egzemplioriuje yra 400. Iš viso reikėjo paleisti šešis lygiagrečius YCSB testų egzempliorius, kad iš viso būtų gauta 2400 gijų.
Žvelgdami į etaloninius rezultatus, ypač į procesoriaus apkrovos ir TPS derinį, aiškiai matome, kad „Cloud Spanner“ yra gana gerai keičiamas. Didelę apkrovą, kurią sukuria daugybė gijų, kompensuoja daug mazgų Cloud Spanner klasteryje. Nors delsa atrodo gana didelė, ypač kai veikia 2400 gijų, norint gauti tikslesnius skaičius, gali prireikti pakartotinai išbandyti su 6 mažesniais skaičiavimo variklio egzemplioriais. Kiekvienas egzempliorius vykdys vieną YCSB testą, o ne vieną didelį CE egzempliorių su 6 lygiagrečiais bandymais. Taip lengviau atskirti „Cloud Spanner“ užklausų delsas ir delsas, pridėtas tinklo ryšio tarp „Cloud Spanner“ ir CE egzemplioriaus, vykdančio testą.
Kaip „Cloud Spanner“ veikia kaip OLAP?
Skirstymas?
Duomenų padalijimas į fiziškai ir (arba) logiškai nepriklausomus segmentus, vadinamus skaidiniais, yra labai populiari koncepcija, randama daugumoje OLAP variklių. Skirsniai gali labai pagerinti užklausų našumą ir duomenų bazės priežiūrą. Toliau gilintis į skaidymą būtų atskiras (-i) straipsnis (-iai), todėl paminėkime tik skaidymo schemos ir subskirstymo svarbą. Galimybė padalyti duomenis į skaidinius ir dar toliau į poskyrius yra raktas į analitines užklausas.
„Cloud Spanner“ nepalaiko skaidinių per se. Jis išskiria duomenis viduje į vadinamuosius skilimas-s remiantis pirminių raktų diapazonais. Skirstymas atliekamas automatiškai, kad būtų subalansuota „Cloud Spanner“ klasterio apkrova. Labai patogi „Cloud Spanner“ funkcija yra pagrindinės lentelės (lentelės, kuri nėra perkelta į kitą) bazinės apkrovos padalijimas. Veržliaraktis automatiškai nustato, ar jame yra skilimas duomenis, kurie skaitomi dažniau nei duomenys kituose skilimas-ah, ir gali nuspręsti dėl tolesnio išsiskyrimo. Taigi, užklausoje gali būti įtraukta daugiau mazgų, o tai taip pat efektyviai padidina pralaidumą.
Įkeliami duomenys?
Masinių duomenų „Cloud Spanner“ metodas yra toks pat kaip ir įprasto įkėlimo metodas. Norėdami pasiekti maksimalų našumą, turite laikytis tam tikrų gairių, įskaitant:
- Rūšiuokite duomenis pagal pirminį raktą.
- Padalinkite juos iš 10*mazgų skaičius atskiri skyriai.
- Sukurkite darbuotojo užduočių, kurios lygiagrečiai įkelia duomenis, rinkinį.
Šis duomenų įkėlimas naudoja visus „Cloud Spanner“ mazgus.
10 mln. eilučių duomenų rinkiniui generuoti panaudojome A YCSB darbo krūvį.
* Apkrovos testas buvo atliktas naudojant n1-standard-32 skaičiavimo variklį (32 vCPU, 120 GB atminties), o bandomasis pavyzdys niekada nebuvo bandymų kliūtis.
** 1 mazgo sąranka nerekomenduojama jokiam gamybiniam darbo krūviui.
Kaip minėta aukščiau, „Cloud Spanner“ automatiškai apdoroja padalijimus, priklausomai nuo jų apkrovos, todėl rezultatai pagerėja po kelių bandymo iteracijų iš eilės. Čia pateikti rezultatai yra geriausi mūsų gauti rezultatai. Žvelgdami į aukščiau pateiktus skaičius, matome, kaip „Cloud Spanner“ mastelis (gerai) didėjant mazgų skaičiui klasteryje. Skaičiai, kurie išsiskiria, yra labai mažas vidutinis delsos laikas, o tai skiriasi nuo mišraus darbo krūvio (95 % skaitymo ir 5 % rašymo) rezultatų, kaip aprašyta aukščiau esančiame skyriuje.
Mastelio keitimas?
„Cloud Spanner“ mazgų skaičiaus padidinimas ir mažinimas yra užduotis vienu spustelėjimu. Jei norite greitai įkelti duomenis, galbūt norėsite apsvarstyti galimybę maksimaliai padidinti egzempliorių (mūsų atveju tai buvo 25 mazgai JAV ir Rytų regione) ir po visų duomenų sumažinti normaliai apkrovai tinkamų mazgų skaičių. duomenų bazėje, nepamirštant 2 TB/mazgo limito.
Apie šią ribą mums buvo priminta net ir turėdami daug mažesnę duomenų bazę. Po kelių apkrovos bandymų mūsų duomenų bazė buvo maždaug 155 GB dydžio, o sumažinus iki 1 mazgo egzemplioriaus, gavome šią klaidą:
Pavyko sumažinti nuo 25 iki 2 atvejų, bet įstrigome ties dviem mazgais.
„Cloud Spanner“ klasterio mazgų skaičiaus padidinimas ir mažinimas gali būti automatizuotas naudojant REST API. Tai gali būti ypač naudinga norint sumažinti padidėjusį sistemos apkrovą užimtomis valandomis.
OLAP užklausos našumas?
Iš pradžių planavome daug laiko skirti Spanner įvertinimui šioje dalyje. Po kelių SELECT COUNT iš karto supratome, kad testas bus trumpas ir veržliaraktis NEBUS tinkamas variklis OLAP. Nepriklausomai nuo mazgų skaičiaus klasteryje, paprasčiausiai pasirinkti eilučių skaičių 10 mln. eilučių lentelėje užtruko 55–60 sekundžių. Be to, bet kuri užklausa, kuriai reikėjo daugiau atminties tarpiniams rezultatams išsaugoti, nepavyko dėl OOM klaidos.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Kai kuriuos TPC-H užklausų skaičius rasite Toddo Lipcono straipsnyje , 42 ir 43 skaidrės. Šie skaičiai atitinka mūsų pačių rezultatus (deja).
4. Mūsų išvados
Atsižvelgiant į dabartinę „Cloud Spanner“ funkcijų būklę, sunku jį vertinti kaip paprastą esamo OLTP sprendimo pakaitalą, ypač kai jūsų poreikiai jį perauga. Reikėtų praleisti daug laiko kuriant sprendimą dėl „Cloud Spanner“ trūkumų.
Kai pradėjome vertinti „Cloud Spanner“, tikėjomės, kad jos valdymo funkcijos atitiks kitus „Google SQL“ sprendimus arba bent jau netoli nuo jų. Tačiau mus nustebino visiškas atsarginių kopijų trūkumas ir labai ribota prieigos prie išteklių kontrolė. Jau nekalbant apie jokių rodinių, jokios vietinės kūrimo aplinkos, nepalaikomų sekų, JDBC be DML ir DDL palaikymo ir pan.
Taigi, kur kreiptis tiems, kuriems reikia keisti operacijų duomenų bazę? Atrodo, kad rinkoje dar nėra vieno sprendimo, kuris tiktų visiems naudojimo atvejams. Yra daug uždarojo ir atvirojo kodo sprendimų (kai kurie iš jų paminėti šiame straipsnyje), kiekvienas turi savo stipriąsias ir silpnąsias puses, tačiau nė vienas iš jų nesiūlo SaaS su 99,999% SLA ir aukštu nuoseklumo laipsniu. Jei jūsų pagrindinis tikslas yra aukštas SLA ir nesate linkę kurti savo sprendimo keliems debesims, „Cloud Spanner“ gali būti jūsų ieškomas sprendimas. Tačiau turėtumėte žinoti apie visus jo apribojimus.
Teisybės dėlei reikia pasakyti, kad „Cloud Spanner“ buvo išleistas visuomenei tik 2017 m. pavasarį, todėl pagrįstai galima tikėtis, kad kai kurie dabartiniai jo trūkumai galiausiai išnyks (tikiuosi), o kai taip atsitiks, tai gali pakeisti žaidimą. Galų gale, „Cloud Spanner“ nėra tik šalutinis „Google“ projektas. „Google“ jį naudoja kaip kitų „Google“ produktų pagrindą. Ir kai „Google“ neseniai „Google Cloud Storage“ „Megastore“ pakeitė „Cloud Spanner“, „Google Cloud Storage“ tapo labai nuosekliu objektų sąrašuose pasauliniu mastu (to vis dar nėra ).
Taigi, vilties dar yra... tikimės.
Tai viskas. Kaip ir straipsnio autorius, mes taip pat ir toliau tikimės, bet ką apie tai manote jūs? Rašyk komentaruose
Kviečiame visus apsilankyti pas mus kuriame išsamiai papasakosime apie kursą iš OTUS.
Šaltinis: www.habr.com