Halló, íbúar Khabrovsk. Eins og venjulega höldum við áfram að deila áhugaverðu efni áður en ný námskeið hefjast. Í dag, sérstaklega fyrir þig, höfum við birt grein um Google Cloud Spanner samhliða setningu námskeiðsins .
Upphaflega birt í .
Sem fyrirtæki sem býður upp á margs konar skýjatengdar POS-lausnir fyrir smásala, veitingamenn og netseljendur um allan heim, notar Lightspeed nokkrar mismunandi gerðir gagnagrunnspalla fyrir margs konar viðskipta-, greiningar- og leitarnotkunartilvik. Hver þessara gagnagrunnsvettvanga hefur sína styrkleika og veikleika. Þess vegna, þegar Google kynnti Cloud Spanner á markaðinn - efnilega eiginleika sem eru óséðir í heimi tengslagagnagrunna, eins og nánast ótakmarkaðan láréttan sveigjanleika og 99,999% þjónustustigssamning (SLA), — við gátum ekki misst af tækifærinu til að fá það í hendurnar!
Til að veita yfirgripsmikið yfirlit yfir reynslu okkar af Cloud Spanner, sem og matsviðmiðunum sem við notuðum, munum við fjalla um eftirfarandi efni:
- Matsviðmið okkar
- Cloud Spanner í hnotskurn
- Mat okkar
- Niðurstöður okkar
1. Matsviðmið okkar
Áður en farið er ofan í saumana á Cloud Spanner, líkt og mun og öðrum lausnum á markaðnum, skulum við fyrst tala um helstu notkunartilvikin sem við höfðum í huga þegar við skoðuðum hvar ætti að nota Cloud Spanner í innviði okkar:
- Í staðinn fyrir (ríkjandi) hefðbundna SQL gagnagrunnslausn
- Hvernig á að OLTP lausn með OLAP stuðningi
Ath: Til að einfalda og auðvelda samanburð ber þessi grein Cloud Spanner saman við MySQL afbrigði af GCP Cloud SQL og Amazon AWS RDS lausnafjölskyldum.
Notkun Cloud Spanner í staðinn fyrir hefðbundna SQL gagnagrunnslausn
Í umhverfinu hefðbundin gagnagrunna, þegar viðbragðstími gagnagrunnsfyrirspurnar nálgast eða jafnvel fer yfir fyrirfram skilgreinda umsóknarþröskuld (aðallega vegna fjölgunar notenda og/eða beiðna), eru nokkrar leiðir til að stytta svartímann niður í viðunandi mörk. Hins vegar fela flestar þessar lausnir í sér handvirkt inngrip.
Til dæmis er fyrsta skrefið sem þarf að taka að skoða hinar ýmsu frammistöðutengdu gagnagrunnsfæribreytur og stilla þær þannig að þær passi best við notkunarmynstur forrita. Ef þetta er ekki nóg geturðu valið að skala gagnagrunninn lóðrétt eða lárétt.
Lóðrétt stærðarstærð forrits felur í sér uppfærslu á tilviki netþjónsins, venjulega með því að bæta við fleiri örgjörvum/kjarna, meira vinnsluminni, hraðari geymslu o.s.frv. Að bæta við fleiri vélbúnaðarauðlindum hefur í för með sér aukna afköst gagnagrunnsins, mæld fyrst og fremst í viðskiptum eftir annað, og viðskiptaleynd fyrir OLTP kerfi. Venslagagnagrunnskerfi (sem nota fjölþráða nálgun) eins og MySQL mælikvarða vel lóðrétt.
Það eru nokkrir ókostir við þessa nálgun, en sá augljósasti er hámarks netþjónastærð á markaðnum. Þegar mörkum stærsta netþjónstilviksins er náð er aðeins einn valkostur eftir: lárétt stærðarstærð.
Lárétt kvörðun er nálgun þar sem fleiri netþjónum er bætt við þyrping, helst auka afköst línulega eftir því sem fjölda netþjóna er bætt við. Meirihluti hefðbundin Gagnagrunnskerfi mælist ekki vel lárétt eða mælist alls ekki. Til dæmis getur MySQL skalað lárétt fyrir lestraraðgerðir með því að bæta við þrælalesendum, en getur ekki skalað lárétt fyrir skrif.
Á hinn bóginn, vegna eðlis þess, getur Cloud Spanner auðveldlega skalað lárétt með lágmarks íhlutun.
Fullkomið DBMS sem þjónusta verður að meta frá mismunandi sjónarhornum. Sem grunnur tókum við vinsælustu DBMS í skýinu - fyrir Google, GCP Cloud SQL og fyrir Amazon, AWS RDS. Í mati okkar lögðum við áherslu á eftirfarandi flokka:
- Eiginleikakortlagning: umfang SQL, DDL, DML; tengisöfn/tengi, viðskiptastuðningur og svo framvegis.
- Þróunarstuðningur: auðveld þróun og prófun.
- Stjórnunarstuðningur: tilvikastjórnun - til dæmis að stækka/minnka og uppfæra tilvik; SLA, öryggisafrit og endurheimt; öryggi/aðgangseftirlit.
Notkun Cloud Spanner sem OLAP-virkja OLTP lausn
Þó að Google haldi því ekki beinlínis fram að Cloud Spanner sé hannað fyrir greiningarvinnslu, þá deilir það nokkrum eiginleikum með öðrum vélum eins og Apache Impala & Kudu og YugaByte, sem eru hannaðar fyrir OLAP vinnuálag.
Jafnvel þó að það væru aðeins litlar líkur á því að Cloud Spanner innihélt stöðuga HTAP (hybrid viðskipta-/greiningarvinnslu) vél með (meira eða minna) nothæfu OLAP eiginleikasetti, þá teljum við að það væri verðugt athygli okkar.
Með þetta í huga skoðuðum við eftirfarandi flokka:
- Gagnahleðsla, vísitölur og skipting stuðning
- Query Performance og DML
2. Cloud Spanner í hnotskurn
Google Spanner er clustered relational database management system (RDBMS) sem Google notar fyrir nokkrar eigin þjónustur. Google gerði það almennt aðgengilegt notendum Google Cloud Platform snemma árs 2017.
Hér eru nokkrar af Cloud Spanner eiginleikum:
- Mjög stöðugur skalanlegur RDBMS þyrping: Notar tímasamstillingu vélbúnaðar til að tryggja samræmi gagna.
- Stuðningur við færslur yfir töflur: Færslur geta spannað margar töflur - ekki endilega takmarkað við eina töflu (ólíkt Apache HBase eða Apache Kudu).
- Töflur byggðar á aðallykla: Allar töflur verða að hafa yfirlýstan aðallykil (PC), sem getur samanstandað af mörgum dálkum í töflunni. Töflugögn eru geymd í tölvuröð, sem gerir þau mjög skilvirk og fljótleg fyrir tölvuleit. Eins og önnur PC-undirstaða kerfi, verður innleiðingin að vera fyrirmynd með fyrirfram hönnuð notkunartilvik í huga til að ná fram .
- Röndótt töflur: Töflur geta verið líkamlegar háðar hvort öðru. Hægt er að passa línur í undirtöflu við línur í yfirtöflu. Þessi nálgun flýtir fyrir leitinni að samböndum sem hægt er að bera kennsl á á meðan á gagnalíkanaferlinu stendur, svo sem samstaðsetningu viðskiptavina og reikninga þeirra.
- Vísitölur: Cloud Spanner styður aukavísitölur. Vísitalan samanstendur af verðtryggðu dálkunum og öllum PC dálkum. Ef þess er óskað getur vísitalan einnig innihaldið aðra óverðtryggða dálka. Hægt er að flétta vísitölunni við foreldratöfluna til að flýta fyrir fyrirspurnum. Nokkrar takmarkanir gilda um vísitölur, svo sem hámarksfjölda viðbótardálka sem geymdir eru í vísitölunni. Einnig gætu fyrirspurnir í gegnum vísitölur ekki verið eins einfaldar og í öðrum RDBMS.
„Cloud Spanner velur vísitölu sjálfkrafa aðeins í einstaka tilfellum. Sérstaklega velur Cloud Spanner ekki sjálfkrafa aukavísitölu ef fyrirspurn biður um dálka sem ekki eru geymdir í '.
- Þjónustustigssamningur (SLA): Dreifing á einu svæði með SLA upp á 99,99%; fjölsvæða dreifing með 99,999% SLA. Þó að SLA sjálft sé bara samningur og ekki trygging af neinu tagi, þá tel ég að fólkið hjá Google hafi erfið gögn til að gera svo sterkar kröfur. (Til viðmiðunar þýðir 99,999% 26,3 sekúndur af þjónustuleysi á mánuði.)
- Meira:
Ath: Apache Tephra verkefnið bætir auknum viðskiptastuðningi við Apache HBase (einnig nú útfært í Apache Phoenix sem beta).
3. Mat okkar
Þannig að við höfum öll lesið fullyrðingar Google um kosti Cloud Spanner - nánast ótakmarkaða lárétta mælikvarða á meðan viðhaldið er mikilli samkvæmni og mjög háu SLA. Þótt þessar kröfur séu í öllum tilvikum mjög erfiðar í framkvæmd var markmið okkar ekki að hrekja þær. Í staðinn skulum við einbeita okkur að öðru sem flestum notendum gagnagrunns er sama um: jöfnuð og notagildi.
Við metum Cloud Spanner sem staðgengil fyrir Sharded MySQL
Google Cloud SQL og Amazon AWS RDS, tvær af vinsælustu OLTP DBMS á skýjamarkaðnum, eru með mjög mikið úrval af eiginleikum. Hins vegar, til að stækka þessa gagnagrunna umfram stærð eins hnúts, þarftu að framkvæma forritaskiptingu. Þessi nálgun skapar aukna flókið bæði fyrir forrit og stjórnun. Við skoðuðum hvernig Spanner passar inn í atburðarásina að sameina margar shards í eitt tilvik og hvaða eiginleikum (ef einhverjum) gæti þurft að fórna.
SQL, DML og DDL stuðningur, sem og tengi og bókasöfn?
Í fyrsta lagi, þegar þú byrjar með hvaða gagnagrunn sem er, þarftu að búa til gagnalíkan. Ef þú heldur að þú getir tengt JDBC Spanner við uppáhalds SQL tólið þitt, muntu komast að því að þú getur spurt gögnin þín með því, en þú getur ekki notað þau til að búa til töflu eða breyta (DDL) eða neinni innsetningu/uppfærslu/eyðingu aðgerðir (DML). Opinber JDBC Google styður ekki annað hvort þessara.
"Ökumenn styðja ekki DML eða DDL yfirlýsingar eins og er."
Skrúfjárn skjöl
Ástandið er ekki betra með GCP vélinni - þú getur aðeins sent SELECT fyrirspurnir. Sem betur fer er JDBC bílstjóri með stuðningi fyrir DML og DDL frá samfélaginu, þar á meðal viðskipti . Þó að þessi bílstjóri sé afar gagnlegur kemur skortur á eigin JDBC bílstjóri Google á óvart. Sem betur fer býður Google nokkuð breiðan stuðning fyrir viðskiptavinasöfn (byggt á gRPC): C#, Go, Java, node.js, PHP, Python og Ruby.
Næstum skylda notkun sérsniðinna API-a Cloud Spanner (vegna skorts á DDL og DML í JDBC) hefur í för með sér nokkrar takmarkanir fyrir tengd kóðasvæði eins og tengingarhópa eða gagnagrunnsbindingaramma (t.d. Spring MVC). Venjulega, þegar þú notar JDBC, er þér frjálst að velja uppáhalds tengilaugina þína (t.d. HikariCP, DBCP, C3PO, osfrv.) sem er prófaður og virkar vel. Þegar um er að ræða sérsniðin Spanner API verðum við að treysta á ramma/bindandi laugar/lotur sem við höfum búið til sjálf.
Aðallykillinn (PC) miðlægur hönnun gerir Cloud Spanner kleift að vera mjög fljótur þegar aðgangur er að gögnum í gegnum tölvu, en kynnir einnig nokkur fyrirspurnarvandamál.
- Þú getur ekki uppfært aðallykilgildið; Þú verður fyrst að eyða færslunni af upprunalegu tölvunni og setja hana aftur inn með nýja gildinu. (Þetta er svipað og aðrar tölvumiðaðar gagnagrunns-/geymsluvélar.)
- Allar UPDATE og DELETE setningar verða að tilgreina PC í WHERE, þess vegna getur ekki verið tómt DELETE allar setningar - það verður alltaf að vera undirfyrirspurn, til dæmis: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Skortur á valmöguleika fyrir sjálfvirka aukningu eða eitthvað álíka sem setur röð fyrir PC reitinn. Til að þetta virki þarf að búa til samsvarandi gildi á umsóknarhliðinni.
Aukavísitölur?
Google Cloud Spanner hefur innbyggðan stuðning fyrir aukavísitölur. Þetta er mjög góður eiginleiki sem er ekki alltaf til staðar í annarri tækni. Apache Kudu styður alls ekki aukavísitölur eins og er og Apache HBase styður ekki vísitölur beint, en getur bætt þeim við í gegnum Apache Phoenix.
Vísitölur í Kudu og HBase geta verið gerðar fyrirmyndir sem sérstaka töflu með mismunandi samsetningu frumlykla, en atómvirkni aðgerða sem gerðar eru á móðurtöflunni og tengdum vísitölutöflum verður að gera á umsóknarstigi og er ekki léttvægt að útfæra rétt.
Eins og fram kemur í Cloud Spanner endurskoðuninni geta vísitölur þess verið frábrugðnar MySQL vísitölum. Þess vegna ætti að gæta sérstakrar varúðar við smíði fyrirspurna og prófílgreiningar til að tryggja að rétt vísitala sé notuð þar sem þess er þörf.
Fulltrúar?
Mjög vinsæll og gagnlegur hlutur í gagnagrunni eru skoðanir. Þau geta verið gagnleg fyrir fjölda notkunartilvika; Tvö uppáhaldslögin mín eru rökræna abstraktlagið og öryggislagið. Því miður styður Cloud Spanner EKKI skoðanir. Hins vegar takmarkar þetta okkur aðeins að hluta vegna þess að það er engin nákvæmni fyrir aðgangsheimildir á dálkstigi þar sem skoðanir gætu verið raunhæf lausn.
Sjáðu Cloud Spanner skjölin fyrir kafla sem útskýrir kvóta og takmarkanir (), það er einn sérstaklega sem getur verið erfiður fyrir sum forrit: Cloud Spanner út úr kassanum hefur að hámarki 100 gagnagrunna í hvert tilvik. Augljóslega getur þetta verið stór flöskuháls fyrir gagnagrunn sem er hannaður til að stækka í yfir 100 gagnagrunna. Sem betur fer, eftir að hafa talað við tæknilega fulltrúa Google okkar, komumst við að því að hægt er að hækka þessi mörk í næstum hvaða gildi sem er í gegnum þjónustudeild Google.
Þróunarstuðningur?
Cloud Spanner býður upp á ágætis stuðning við forritunarmál til að vinna með API þess. Opinberlega studd bókasöfn eru á sviðum C#, Go, Java, node.js, PHP, Python og Ruby. Skjölin eru nokkuð ítarleg, en eins og með aðra háþróaða tækni er samfélagið frekar lítið miðað við vinsælustu gagnagrunnstæknina, sem getur leitt til þess að meiri tími fer í að leysa sjaldgæfari notkunartilvik eða vandamál.
Svo hvað með að styðja við staðbundna þróun?
Við höfum ekki fundið leið til að búa til Cloud Spanner tilvik á staðnum. Það næsta sem við komumst var Docker mynd. , sem er svipað í meginatriðum, en mjög ólíkt í framkvæmd. Til dæmis getur CockroachDB notað PostgreSQL JDBC. Þar sem þróunarumhverfið ætti að vera eins nálægt framleiðsluumhverfinu og mögulegt er, er Cloud Spanner ekki tilvalið þar sem það verður að treysta á fullt Spanner tilvik. Til að spara kostnað geturðu valið eitt svæðisdæmi.
Stuðningur stjórnvalda?
Það er mjög einfalt að búa til Cloud Spanner dæmi. Þú þarft bara að velja á milli þess að búa til fjölsvæða eða eins svæðistilvik, tilgreina svæði/svæði og fjölda hnúta. Eftir innan við mínútu verður tilvikið þitt komið í gang.
Nokkrar grunntölur eru aðgengilegar beint frá Spann-síðunni í Google Console. Ítarlegri skoðanir eru fáanlegar í gegnum Stackdriver, þar sem þú getur líka stillt mæligildi og viðvörunarstefnur.
Aðgangur að auðlindum?
MySQL býður upp á umfangsmiklar og mjög nákvæmar stillingar fyrir notendaheimildir/hlutverk. Þú getur auðveldlega stillt aðgang að tiltekinni töflu, eða jafnvel bara undirmengi dálka hennar. Cloud Spanner notar tól Google Identity & Access Management (IAM), sem gerir þér aðeins kleift að stilla stefnur og heimildir á mjög háu stigi. Nákvæmasti valkosturinn er upplausn á gagnagrunnsstigi, sem passar ekki inn í flest framleiðslutilvik. Þessi takmörkun neyðir þig til að bæta við viðbótaröryggisráðstöfunum við kóðann þinn, innviði eða hvort tveggja til að koma í veg fyrir óleyfilega notkun á Spanner auðlindum.
Afrit?
Til að setja það einfaldlega, það eru engin afrit í Cloud Spanner. Þótt miklar SLA kröfur Google geti tryggt að þú tapir ekki gögnum vegna vélbúnaðar- eða gagnagrunnsbilana, mannlegra mistaka, forritsgalla osfrv. Við þekkjum öll regluna: mikið framboð kemur ekki í staðinn fyrir góða öryggisafritunarstefnu. Eins og er, eina leiðin til að taka öryggisafrit af gögnum er að streyma þeim forritunarlega úr gagnagrunni í sérstakt geymsluumhverfi.
Fyrirspurn um árangur?
Við notuðum Yahoo! til að hlaða gögnum og prófa fyrirspurnir. Cloud Serving Benchmark. Taflan hér að neðan sýnir YCSB vinnuálag B með 95% leshlutfalli til 5%.
* Álagsprófið var keyrt á n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB minni) og prófunartilvikið var aldrei flöskuháls í prófunum.
** Hámarksfjöldi þráða í einu YCSB tilviki er 400. Alls þurfti að keyra sex samhliða tilvik af YCSB prófum til að fá samtals 2400 þræði.
Þegar litið er á viðmiðunarniðurstöðurnar, sérstaklega samsetningu örgjörvaálags og TPS, getum við greinilega séð að Cloud Spanner mælist nokkuð vel. Mikið álag sem skapast af miklum fjölda þráða er á móti miklum fjölda hnúta í Cloud Spanner þyrpingunni. Þó að töfin líti frekar út, sérstaklega þegar keyrt er með 2400 þræði, getur verið nauðsynlegt að endurprófa með 6 minni tilfellum af tölvuvélinni til að fá nákvæmari tölur. Hvert tilvik mun keyra eitt YCSB próf í stað eins stórs CE tilvik með 6 samhliða prófum. Þannig verður auðveldara að greina á milli Cloud Spanner biðtíma og leynd sem bætt er við með nettengingunni milli Cloud Spanner og CE tilviksins sem keyrir prófið.
Hvernig virkar Cloud Spanner sem OLAP?
Skipting?
Að skipta gögnum í líkamlega og/eða rökfræðilega sjálfstæða hluta, sem kallast skipting, er mjög vinsælt hugtak sem finnst í flestum OLAP vélum. Skipting getur verulega bætt árangur fyrirspurna og viðhald gagnagrunns. Að fara dýpra í skiptinguna væri sérstök grein(ir), svo við skulum bara nefna mikilvægi þess að hafa skiptingar- og undirskiptingarkerfi. Hæfni til að skipta gögnum niður í skipting og jafnvel lengra í undirskipti er lykillinn að frammistöðu greiningarfyrirspurna.
Cloud Spanner styður ekki skipting sem slík. Það skiptir gögnum innbyrðis í svokallaða hættu-s byggt á aðallyklasviðum. Skipting fer fram sjálfkrafa til að jafna álagið í Cloud Spanner klasa. Mjög gagnlegur eiginleiki Cloud Spanner er að skipta grunnálagi móðurborðsins (tafla sem er ekki fléttað saman við aðra). Spanner skynjar sjálfkrafa hvort það inniheldur hættu gögn sem eru lesin oftar en gögn í öðrum hættu-ah, og getur ákveðið frekari aðskilnað. Þannig geta fleiri hnútar tekið þátt í beiðni, sem einnig eykur afköst í raun.
Hleður gögnum?
Cloud Spanner aðferðin fyrir magngögn er sú sama og fyrir venjulega hleðslu. Til að ná hámarksárangri þarftu að fylgja nokkrum leiðbeiningum, þar á meðal:
- Raðaðu gögnunum þínum eftir aðallykil.
- Deilið þeim með 10*fjölda hnúta aðskildum hlutum.
- Búðu til sett af vinnuverkefnum sem hlaða gögnum samhliða.
Þessi gagnahleðsla notar alla Cloud Spanner hnúta.
Við notuðum YCSB vinnuálag A til að búa til gagnasafn með 10M línum.
* Álagsprófið var keyrt á n1-standard-32 tölvuvélinni (32 vCPU, 120 GB minni) og prófunartilvikið var aldrei flöskuháls í prófunum.
** Ekki er mælt með uppsetningu á einum hnút fyrir neitt framleiðsluálag.
Eins og getið er hér að ofan vinnur Cloud Spanner sjálfkrafa úr skiptingum út frá álagi þeirra, þannig að niðurstöður batna eftir nokkrar samfelldar prófendurtekningar. Niðurstöðurnar sem birtar eru hér eru bestu niðurstöður sem við fengum. Þegar litið er á tölurnar hér að ofan getum við séð hvernig Cloud Spanner skalast (vel) þegar fjöldi hnúta í þyrpingunni eykst. Tölurnar sem skera sig úr eru afar lág meðaltöf, sem er í andstöðu við niðurstöður fyrir blandað vinnuálag (95% lesið og 5% skrifar) eins og lýst er í kaflanum hér að ofan.
Skala?
Að fjölga og fækka Cloud Spanner hnútum er verkefni með einum smelli. Ef þú vilt hlaða gögnum hratt gætirðu íhugað að auka tilvikið þitt að hámarki (í okkar tilfelli voru það 25 hnútar á US-EAST svæðinu) og fækka síðan fjölda hnúta sem eru gjaldgengir fyrir venjulega álag þitt þegar öll gögn eru komin inn gagnagrunninn, sem vísar til 2TB/hnútatakmarkanna.
Við vorum minnt á þessi mörk jafnvel með miklu minni gagnagrunni. Eftir nokkrar keyrslur af álagsprófum var gagnagrunnurinn okkar um 155 GB að stærð og þegar hann var minnkaður í 1 hnúttilvik fengum við eftirfarandi villu:
Okkur tókst að minnka úr 25 í 2 tilvik, en við vorum fastir við tvo hnúta.
Að auka og fækka fjölda hnúta í Cloud Spanner þyrpingu er hægt að gera sjálfvirkt með því að nota REST API. Þetta getur verið sérstaklega gagnlegt til að draga úr auknu kerfisálagi á annasömum vinnutíma.
Afköst OLAP fyrirspurna?
Við ætluðum upphaflega að eyða umtalsverðum tíma í mat okkar á Spanner í þessum hluta. Eftir nokkrar SELECT COUNTS áttuðum við okkur strax á því að prófun yrði stutt og að Spanner væri EKKI hentug vél fyrir OLAP. Burtséð frá fjölda hnúta í þyrpingunni, einfaldlega að velja fjölda raða í 10M röð töflu tók á milli 55 og 60 sekúndur. Að auki mistókst allar fyrirspurnir sem kröfðust meira minnis til að geyma milliniðurstöður með OOM-villu.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Sumar tölur fyrir TPC-H fyrirspurnir má finna í grein Todd Lipcon , glærur 42 og 43. Þessar tölur eru í samræmi við okkar eigin niðurstöður (því miður).
4. Ályktanir okkar
Miðað við núverandi stöðu eiginleika Cloud Spanner er erfitt að ímynda sér að það sé einföld skipti fyrir núverandi OLTP lausn þína, sérstaklega þegar þarfir þínar vaxa úr henni. Umtalsverðum tíma þyrfti að eyða í að byggja upp lausn í kringum galla Cloud Spanner.
Þegar við byrjuðum að meta Cloud Spanner bjuggumst við við að stjórnunareiginleikar þess væru á pari við, eða að minnsta kosti ekki of langt frá, öðrum Google SQL lausnum. En það kom okkur á óvart algjör skortur á afritum og mjög takmarkaðri stjórn á aðgangi að auðlindum. Svo ekki sé minnst á ekkert útsýni, ekkert staðbundið þróunarumhverfi, óstuddar raðir, JDBC án DML og DDL stuðning, og svo framvegis.
Svo hvert fer einhver sem þarf að skala viðskiptagagnagrunn? Það virðist ekki vera ein lausn á markaðnum sem hentar öllum notkunartilfellum. Það eru margar lokaðar og opinn uppspretta lausnir (sumar þeirra eru nefndar í þessari grein), hver með sína styrkleika og veikleika, en engin þeirra býður upp á SaaS með 99,999% SLA og mikilli samkvæmni. Ef há SLA er aðalmarkmið þitt og þú ert ekki hneigður til að smíða sérsniðna multi-ský lausn, getur Cloud Spanner verið lausnin sem þú ert að leita að. En þú ættir að vera meðvitaður um allar takmarkanir þess.
Til að vera sanngjarn, var Cloud Spanner aðeins gefið út fyrir almenning vorið 2017, svo það er eðlilegt að búast við því að sumir af núverandi göllum þess gætu að lokum hverfa (vonandi), og þegar þeir gera það gæti það verið leikbreyting. Þegar öllu er á botninn hvolft er Cloud Spanner ekki bara aukaverkefni fyrir Google. Google notar það sem grunn fyrir aðrar Google vörur. Og þegar Google skipti nýlega út Megastore í Google Cloud Storage fyrir Cloud Spanner, gerði það Google Cloud Storage kleift að verða mjög samkvæmur lista yfir hluti á heimsvísu (sem er samt ekki raunin fyrir ).
Svo, það er enn von... við vonum.
Það er allt og sumt. Eins og höfundur greinarinnar höldum við líka áfram að vona, en hvað finnst þér um þetta? Skrifaðu í athugasemdir
Hvetjum alla til að heimsækja okkar þar sem við munum segja þér ítarlega frá námskeiðinu frá OTUS.
Heimild: www.habr.com