Hallo, Khabrovites. Tradisioneel gaan ons voort om interessante materiaal te deel op die vooraand van die begin van nuwe kursusse. Vandag, spesiaal vir jou, het ons 'n artikel oor Google Cloud Spanner vertaal, tyd om saam te val met die bekendstelling van die kursus .
Oorspronklik gepubliseer in .
As 'n maatskappy wat 'n verskeidenheid wolkgebaseerde POS-oplossings vir kleinhandelaars, restaurateurs en aanlynhandelaars regoor die wêreld bied, gebruik Lightspeed verskeie verskillende tipes databasisplatforms vir 'n verskeidenheid transaksionele, analitiese en soekgebruiksgevalle. Elkeen van hierdie databasisplatforms het sy eie sterk- en swakpunte. Daarom, toe Google Cloud Spanner aan die mark bekendgestel het - belowende kenmerke wat nie in die wêreld van relasionele databasisse gesien word nie, soos feitlik onbeperkte horisontale skaalbaarheid en 'n 99,999% diensvlakooreenkoms (SLA) , Ons kon nie die geleentheid laat verbygaan om haar in ons hande te hê nie!
Om 'n omvattende oorsig te gee van ons ervaring met Cloud Spanner, sowel as die evalueringskriteria wat ons gebruik het, sal ons die volgende onderwerpe dek:
- Ons evalueringskriteria
- Wolksleutel in 'n neutedop
- Ons beoordeling
- Ons bevindings
1. Ons evalueringskriteria
Voordat ons in die besonderhede van Cloud Spanner, die ooreenkomste en verskille daarvan met ander oplossings op die mark ingaan, kom ons praat eers oor die belangrikste gebruiksgevalle wat ons in gedagte gehad het toe ons oorweeg het waar om Cloud Spanner in ons infrastruktuur te ontplooi:
- As 'n plaasvervanger vir die (heersende) tradisionele SQL-databasisoplossing
- As 'n OLAP-geaktiveerde OLTP-oplossing
Let wel: Vir gemak van vergelyking, vergelyk hierdie artikel Cloud Spanner met die MySQL-variante van die GCP Cloud SQL- en Amazon AWS RDS-oplossingfamilies.
Gebruik Cloud Spanner as 'n plaasvervanger vir 'n tradisionele SQL-databasisoplossing
In die omgewing tradisioneel databasisse, wanneer die reaksietyd vir 'n databasisnavraag voorafbepaalde toepassingsdrempels nader of selfs oorskry (hoofsaaklik as gevolg van 'n toename in die aantal gebruikers en/of versoeke), is daar verskeie maniere om die reaksietyd tot aanvaarbare vlakke te verminder. Die meeste van hierdie oplossings behels egter handmatige ingryping.
Byvoorbeeld, die eerste stap om te neem is om na die verskillende prestasieverwante databasisinstellings te kyk en dit in te stel om die beste by toepassingsgebruikscenariopatrone te pas. As dit nie genoeg is nie, kan jy kies om die databasis vertikaal of horisontaal te skaal.
Om 'n toepassing op te skaal behels die opdatering van die bedienerinstansie, tipies deur meer verwerkers/kerne, meer RAM, vinniger berging, ens. Relasionele databasisstelsels (wat 'n multi-threaded benadering gebruik) soos MySQL skaal goed vertikaal.
Daar is verskeie nadele aan hierdie benadering, maar die mees voor die hand liggende is die maksimum bedienergrootte op die mark. Sodra die grootste bedienerinstansie-limiet bereik is, is daar net een pad oor: skaal uit.
Uitskaal is 'n benadering wat meer bedieners by 'n groep voeg om die werkverrigting liniêr te verhoog namate meer bedieners bygevoeg word. Meerderheid tradisioneel databasisstelsels skaal nie goed nie of skaal glad nie. MySQL kan byvoorbeeld uitskaal vir leesbewerkings deur slawelesers by te voeg, maar kan nie uitskaal vir skryfbewerkings nie.
Aan die ander kant, as gevolg van die aard daarvan, kan Cloud Spanner maklik horisontaal skaal met minimale ingryping.
Volledige kenmerk DBMS as 'n diens moet vanuit verskillende perspektiewe geëvalueer word. As basis het ons die gewildste DBBS in die wolk geneem - vir Google, GCP Cloud SQL en vir Amazon, AWS RDS. In ons evaluering het ons op die volgende kategorieë gefokus:
- Kenmerkkartering: SQL-omvang, DDL, DML; verbindingsbiblioteke/verbindings, transaksieondersteuning, ensovoorts.
- Ontwikkelingsondersteuning: Gemak van ontwikkeling en toetsing.
- Administrasie-ondersteuning: Gevallebestuur soos op-/afskaal en opgradering van gevalle; SLA, rugsteun en herstel; sekuriteit/toegangsbeheer.
Gebruik Cloud Spanner as 'n OLAP-geaktiveerde OLTP-oplossing
Alhoewel Google nie uitdruklik sê dat Cloud Spanner vir analise is nie, deel dit wel sommige eienskappe met ander enjins soos Apache Impala & Kudu en YugaByte wat ontwerp is vir OLAP-werkladings.
Selfs al was daar net 'n klein kans dat Cloud Spanner 'n konsekwente HTAP (Hybrid Transactional/Analytic Processing)-enjin met 'n (min of meer) bruikbare OLAP-kenmerkstel ingesluit het, dink ons dit sal ons aandag verdien.
Met dit in gedagte het ons na die volgende kategorieë gekyk:
- Data laai, indekse en partisie ondersteuning
- Soek prestasie en DML
2. Wolksleutel in 'n neutedop
Google Spanner is 'n gegroepeerde relasionele databasisbestuurstelsel (RDBMS) wat Google vir verskeie van sy eie dienste gebruik. Google het dit vroeg in 2017 publiek beskikbaar gestel aan gebruikers van Google Wolkplatform.
Hier is 'n paar van die Cloud Spanner-kenmerke:
- Hoogs konsekwente, skaalbare RDBMS-groepering: gebruik hardeware tydsinchronisasie om datakonsekwentheid te verseker.
- Ondersteuning vir kruistabeltransaksies: Transaksies kan oor verskeie tabelle strek - nie noodwendig beperk tot 'n enkele tabel nie (anders as Apache HBase of Apache Kudu).
- Primêre sleutelgebaseerde tabelle: Alle tabelle moet 'n verklaarde primêre sleutel (PC) hê, wat uit veelvuldige tabelkolomme kan bestaan. Tabeldata word in rekenaarvolgorde gestoor, wat dit baie doeltreffend en vinnig maak vir rekenaarsoektogte. Soos met ander rekenaar-gebaseerde stelsels, moet die implementering gemodelleer word teen vooropgestelde gebruiksgevalle om te bereik .
- Gestreepte tabelle: Tabelle kan fisiese afhanklikhede van mekaar hê. Die rye van die kindtabel kan ooreenstem met die rye van die ouertabel. Hierdie benadering versnel die soektog na verhoudings wat by die datamodelleringstadium bepaal kan word, byvoorbeeld wanneer kliënte en hul fakture bymekaar geplaas word.
- Indekse: Cloud Spanner ondersteun sekondêre indekse. 'n Indeks bestaan uit geïndekseerde kolomme en alle rekenaarkolomme. Opsioneel kan die indeks ook ander nie-geïndexeerde kolomme bevat. Die indeks kan met die ouertabel verweef word om navrae te bespoedig. Verskeie beperkings geld vir indekse, soos die maksimum aantal bykomende kolomme wat in 'n indeks gestoor kan word. Ook, navrae deur indekse is dalk nie so eenvoudig soos in ander RDBMS nie.
“Cloud Spanner kies slegs in seldsame gevalle outomaties 'n indeks. In die besonder, Cloud Spanner kies nie outomaties 'n sekondêre indeks as die navraag enige kolomme versoek wat nie in gestoor word nie ".
- Diensvlakooreenkoms (SLA): Enkelstreek-ontplooiing met 99,99% SLA; multi-streek-ontplooiings met 99,999% SLA. Alhoewel die SLA self net 'n ooreenkoms is en nie 'n waarborg van enige aard nie, glo ek dat Google-mense wel 'n paar harde data het om so 'n sterk eis te maak. (Vir verwysing, 99,999% beteken 26,3 sekondes se stilstandtyd per maand.)
- meer:
Let wel: Die Apache Tephra-projek voeg gevorderde transaksie-ondersteuning by Apache HBase (ook nou geïmplementeer in Apache Phoenix as 'n beta).
3. Ons assessering
So, ons het almal Google se stellings oor die voordele van Cloud Spanner gelees - feitlik onbeperkte horisontale skaal terwyl hoë konsekwentheid en 'n baie hoë SLA gehandhaaf word. Alhoewel hierdie aansprake in elk geval uiters moeilik is om te bereik, was ons doel nie om dit te weerlê nie. Kom ons fokus eerder op ander dinge waaroor die meeste databasisgebruikers omgee: pariteit en bruikbaarheid.
Ons het Cloud Spanner beoordeel as 'n plaasvervanger vir Sharded MySQL
Google Cloud SQL en Amazon AWS RDS, twee van die gewildste OLTP-databasisse in die wolkmark, het 'n baie groot kenmerkstel. Om egter hierdie databasisse verder as die grootte van 'n enkele nodus te skaal, moet u toepassingsverdeling uitvoer. Hierdie benadering skep bykomende kompleksiteit vir beide toepassings en administrasie. Ons het gekyk hoe Spanner inpas by die scenario om veelvuldige skerwe in een geval te kombineer en watter kenmerke (indien enige) dalk opgeoffer moet word.
Ondersteuning vir SQL, DML en DDL, sowel as die koppelaar en biblioteke?
Eerstens, wanneer jy met enige databasis begin, moet jy 'n datamodel skep. As jy dink jy kan JDBC Spanner aan jou gunsteling SQL-instrument koppel, sal jy vind dat jy jou data daarmee kan navraag doen, maar jy kan dit nie gebruik om 'n tabel of opdatering (DDL) of enige invoeging/bywerking/verwydering te skep nie bedrywighede (DML). Google se amptelike JDBC ondersteun ook nie.
"Drywers ondersteun nie tans DML- of DDL-stellings nie."
Spanner Dokumentasie
Die situasie is nie beter met die GCP-konsole nie - jy kan slegs SELECT-navrae stuur. Gelukkig is daar 'n JDBC-bestuurder met DML- en DDL-ondersteuning van die gemeenskap, insluitend transaksies . Alhoewel hierdie bestuurder uiters nuttig is, is die afwesigheid van Google se eie JDBC-bestuurder verbasend. Gelukkig bied Google redelike breë kliëntbiblioteekondersteuning (gebaseer op gRPC): C#, Go, Java, node.js, PHP, Python en Ruby.
Die byna verpligte gebruik van Cloud Spanner se pasgemaakte API's (weens die gebrek aan DDL en DML in JDBC) lei tot 'n paar beperkings vir verwante kodeareas soos verbindingpoel of databasisbindingsraamwerke (soos Spring MVC). Oor die algemeen, wanneer jy JDBC gebruik, is jy vry om jou gunsteling verbindingspoel (bv. HikariCP, DBCP, C3PO, ens.) te kies wat getoets is en goed werk. In die geval van pasgemaakte Spanner API's, moet ons staatmaak op raamwerke/binding/sessiepoele wat ons self geskep het.
Die primêre sleutel (PC) georiënteerde ontwerp laat Cloud Spanner baie vinnig toe om toegang tot data via die rekenaar te kry, maar stel ook 'n paar navraagkwessies bekend.
- Jy kan nie die waarde van 'n primêre sleutel opdateer nie; Jy moet eers die oorspronklike rekenaar-inskrywing uitvee en dit weer met die nuwe waarde invoeg. (Dit is soortgelyk aan ander rekenaar-georiënteerde databasis-/bergingsenjins.)
- Enige UPDATE- en DELETE-stellings moet die rekenaar in die WHERE spesifiseer, daarom kan daar nie leë DELETE alle stellings wees nie - daar moet altyd 'n subnavraag wees, byvoorbeeld: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Gebrek aan 'n outomatiese inkrementopsie of iets soortgelyks wat die volgorde vir die rekenaarveld stel. Vir dit om te werk, moet die ooreenstemmende waarde aan die toepassingskant geskep word.
Sekondêre indekse?
Google Cloud Spanner het ingeboude ondersteuning vir sekondêre indekse. Dit is 'n baie goeie kenmerk wat nie altyd in ander tegnologieë voorkom nie. Apache Kudu ondersteun tans glad nie sekondêre indekse nie, en Apache HBase ondersteun nie indekse direk nie, maar kan dit via Apache Phoenix byvoeg.
Indekse in Kudu en HBase kan gemodelleer word as 'n aparte tabel met verskillende samestelling van primêre sleutels, maar die atomiteit van die bewerkings wat op die ouertabel en verwante indekstabelle uitgevoer word, moet op die toepassingsvlak uitgevoer word en is nie triviaal om korrek te implementeer nie.
Soos genoem in die Cloud Spanner-oorsig, kan die indekse daarvan verskil van MySQL-indekse. Daarom moet spesiale sorg geneem word in die bou van navrae en profilering om te verseker dat die korrekte indeks gebruik word waar dit nodig is.
Verteenwoordiging?
'n Baie gewilde en nuttige voorwerp in 'n databasis is aansigte. Hulle kan nuttig wees vir 'n groot aantal gebruiksgevalle; my twee gunstelinge is die logiese abstraksielaag en die sekuriteitslaag. Ongelukkig ondersteun Cloud Spanner NIE aansigte nie. Dit beperk ons egter net gedeeltelik, aangesien daar geen kolomvlak-granulariteit vir toegangstoestemmings is waar aansigte 'n aanvaarbare oplossing kan wees nie.
Sien die Cloud Spanner-dokumentasie vir 'n afdeling wat kwotas en limiete uiteensit (), is daar veral een wat vir sommige toepassings problematies kan wees: Cloud Spanner uit die boks het 'n maksimum van 100 databasisse per geval. Dit kan natuurlik 'n groot struikelblok wees vir 'n databasis wat ontwerp is om tot meer as 100 databasisse te skaal. Gelukkig het ons, nadat ons met ons Google-tegniese verteenwoordiger gepraat het, uitgevind dat hierdie limiet tot byna enige waarde verhoog kan word deur Google Ondersteuning.
Ontwikkelingsondersteuning?
Cloud Spanner bied redelik ordentlike programmeertaalondersteuning om met sy API te werk. Die amptelik ondersteunde biblioteke is in die gebied van C#, Go, Java, node.js, PHP, Python en Ruby. Die dokumentasie is redelik gedetailleerd, maar soos met ander voorpunttegnologieë, is die gemeenskap redelik klein in vergelyking met die meeste gewilde databasistegnologieë, wat kan lei tot meer tyd wat aan minder algemene gebruiksgevalle of -probleme bestee word.
So wat van plaaslike ontwikkelingsondersteuning?
Ons het nie 'n manier gevind om 'n Cloud Spanner-instansie op die perseel te skep nie. Die naaste wat ons gekom het, is 'n Docker-beeld wat in beginsel soortgelyk is, maar in die praktyk baie anders is. Byvoorbeeld, CockroachDB kan PostgreSQL JDBC gebruik. Aangesien die ontwikkelingsomgewing so na as moontlik aan die produksie-omgewing moet wees, is Cloud Spanner nie ideaal nie, want jy moet staatmaak op 'n volledige Spanner-instansie. Om koste te bespaar, kan jy 'n enkele streek-instansie kies.
Administrasie ondersteuning?
Die skep van 'n Cloud Spanner-instansie is baie eenvoudig. Jy hoef net te kies tussen die skep van 'n multi-streek of 'n enkel-streek instansie, spesifiseer die streek(s) en die aantal nodusse. Binne minder as 'n minuut sal die instansie aan die gang wees.
Verskeie elementêre maatstawwe is direk beskikbaar op die Spanner-bladsy in die Google Console. Meer gedetailleerde aansigte is beskikbaar via Stackdriver, waar jy ook metrieke drempels en waarskuwingsbeleide kan stel.
Toegang tot hulpbronne?
MySQL bied uitgebreide en baie fyn gebruikertoestemming/rolinstellings. Jy kan maklik toegang tot 'n spesifieke tabel aanpas, of selfs net 'n subset van sy kolomme. Cloud Spanner gebruik die Google Identity & Access Management (IAM)-nutsding, wat jou net toelaat om beleide en toestemmings op 'n baie hoë vlak te stel. Die mees korrelige opsie is databasisvlaktoestemming, wat nie in die meeste produksiegevalle pas nie. Hierdie beperking dwing jou om bykomende sekuriteitsmaatreëls by jou kode, infrastruktuur of albei te voeg om ongemagtigde gebruik van Spanner-hulpbronne te voorkom.
Rugsteun?
Om dit eenvoudig te stel, daar is geen rugsteun in Cloud Spanner nie. Terwyl Google se hoë SLA-vereistes kan verseker dat jy geen data verloor as gevolg van hardeware- of databasisfoute, menslike foute, toepassingsdefekte, ens. Ons ken almal die reël: hoë beskikbaarheid is geen plaasvervanger vir 'n slim rugsteunstrategie nie. Tans is die enigste manier om data te rugsteun om dit programmaties vanaf die databasis na 'n aparte stooromgewing te stroom.
Doen navraag oor prestasie?
Ons het Yahoo! gebruik om data te laai en navrae te toets. Wolkdiensmaatstaf. Die tabel hieronder toon die B YCSB-werklading met 'n 95% lees- tot 5%-skryfverhouding.
* Die lastoets is op n1-standaard-32 Compute Engine (CE) (32 vCPU's, 120 GB geheue) uitgevoer en die toetsinstansie was nooit die bottelnek in die toetse nie.
** Die maksimum aantal drade in een YCSB-instansie is 400. In totaal moes ses parallelle gevalle van YCSB-toetse uitgevoer word om 'n totaal van 2400 drade te kry.
As ons na die maatstafresultate kyk, veral die kombinasie van SVE-lading en TPS, kan ons duidelik sien dat Cloud Spanner redelik goed skaal. Die groot las wat deur 'n groot aantal drade geskep word, word verreken deur 'n groot aantal nodusse in die Cloud Spanner-kluster. Alhoewel die latensie redelik hoog lyk, veral wanneer dit teen 2400 drade loop, kan dit nodig wees om te hertoets met 6 kleiner gevalle van die rekenaarenjin om meer akkurate getalle te kry. Elke instansie sal een YCSB-toets uitvoer in plaas van een groot CE-instansie met 6 parallelle toetse. Dit sal dit makliker maak om te onderskei tussen Cloud Spanner-versoekvertragings en vertragings wat bygevoeg word deur die netwerkverbinding tussen Cloud Spanner en die CE-instansie wat die toets uitvoer.
Hoe presteer Cloud Spanner as 'n OLAP?
Partisionering?
Die verdeling van data in fisies en/of logies onafhanklike segmente, wat partisies genoem word, is 'n baie gewilde konsep wat in die meeste OLAP-enjins voorkom. Partisies kan navraagwerkverrigting en databasisonderhoudbaarheid aansienlik verbeter. Verdere delf in partisionering sal 'n aparte artikel(s) wees, so kom ons noem net die belangrikheid van 'n partisioneringskema en subpartisionering. Die vermoë om data in partisies en selfs verder in subpartisies te verdeel, is die sleutel tot die prestasie van analitiese navrae.
Cloud Spanner ondersteun nie partisies per se nie. Dit skei data intern in sg verdeel-s gebaseer op primêre sleutelreekse. Die partisionering word outomaties gedoen om die las op die Cloud Spanner-kluster te balanseer. 'n Baie handige kenmerk van Cloud Spanner is om die basislading van 'n ouertabel te verdeel ('n tabel wat nie met 'n ander verweef is nie). Spanner bespeur outomaties of dit bevat verdeel data wat meer gereeld gelees word as data in ander verdeel-ag, en kan besluit op 'n verdere skeiding. Sodoende kan meer nodusse by 'n versoek betrek word, wat ook deurset effektief verhoog.
Laai tans data?
Die Cloud Spanner-metode vir grootmaatdata is dieselfde as vir 'n gewone oplaai. Vir maksimum prestasie moet jy 'n paar riglyne volg, insluitend:
- Sorteer jou data volgens primêre sleutel.
- Deel hulle deur 10*aantal nodusse individuele afdelings.
- Skep 'n stel werkertake wat data parallel laai.
Hierdie datalading gebruik alle Cloud Spanner-nodusse.
Ons het die A YCSB werklading gebruik om 'n 10M ry datastel te genereer.
* Die lastoets is op die n1-standaard-32-rekenaarenjin (32 vCPU's, 120 GB geheue) uitgevoer en die toetsinstansie was nooit die bottelnek in die toetse nie.
** 'n 1 nodus opstelling word nie aanbeveel vir enige produksie werklading nie.
Soos hierbo genoem, verwerk Cloud Spanner verdelings outomaties na gelang van hul vrag, sodat die resultate verbeter na verskeie opeenvolgende iterasies van die toets. Die resultate wat hier aangebied word, is die beste resultate wat ons ontvang het. As ons na die getalle hierbo kyk, kan ons sien hoe Cloud Spanner skaal (goed) soos die aantal nodusse in die groep toeneem. Die getalle wat uitstaan is uiters lae gemiddelde latency, wat in kontras is met resultate van gemengde werkladings (95% lees en 5% skryf) soos beskryf in die afdeling hierbo.
Skaal?
Die verhoging en vermindering van die aantal Cloud Spanner nodusse is 'n een-klik taak. As jy data vinnig wil laai, wil jy dalk oorweeg om die instansie tot die maksimum te verhoog (in ons geval was dit 25 nodusse in die VSA-OOS-streek) en dan die aantal nodusse wat geskik is vir jou normale vrag verminder ná al die data in die databasis, met inagneming van die limiet van 2 TB/nodus.
Ons is aan hierdie limiet herinner, selfs met 'n baie kleiner databasis. Na verskeie laaitoetslopies was ons databasis ongeveer 155 GB groot, en toe dit afgeskaal is tot 'n 1 nodus-instansie, het ons die volgende fout gekry:
Ons kon afskaal van 25 tot 2 gevalle, maar ons sit vas op twee nodusse.
Die verhoging en vermindering van die aantal nodusse in 'n Cloud Spanner-kluster kan geoutomatiseer word met behulp van die REST API. Dit kan veral nuttig wees om die verhoogde las op die stelsel gedurende besige ure te verminder.
OLAP-navraagprestasie?
Ons het oorspronklik beplan om heelwat tyd aan ons evaluering van Spanner aan hierdie deel te bestee. Na 'n paar SELECT COUNTs het ons dadelik besef dat die toets kort sou wees en dat Spanner NIE 'n geskikte enjin vir OLAP sou wees nie. Ongeag die aantal nodusse in die groepie, die keuse van die aantal rye in 'n 10M-rytabel het 55 tot 60 sekondes geneem. Enige navraag wat meer geheue benodig het om tussenresultate te stoor, het ook misluk met 'n OOM-fout.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Sommige nommers vir TPC-H-navrae kan gevind word in Todd Lipcon se artikel , skyfies 42 en 43. Hierdie getalle stem ooreen met ons eie resultate (ongelukkig).
4. Ons bevindinge
Gegewe die huidige stand van Cloud Spanner se kenmerke, is dit moeilik om dit te sien as 'n eenvoudige plaasvervanger vir 'n bestaande OLTP-oplossing, veral wanneer jou behoeftes dit ontgroei. 'n Beduidende hoeveelheid tyd sal bestee moet word om 'n oplossing rondom die tekortkominge van Cloud Spanner te bou.
Toe ons Cloud Spanner begin evalueer het, het ons verwag dat sy bestuurskenmerke op gelyke voet sou wees met, of ten minste nie ver van, ander Google SQL-oplossings nie. Maar ons was verras deur die algehele gebrek aan rugsteun en baie beperkte toegangsbeheer tot hulpbronne. Om nie te praat van geen sienings, geen plaaslike ontwikkelingsomgewing, ongesteunde reekse, JDBC sonder DML- en DDL-ondersteuning, ensovoorts nie.
So, waarheen om te gaan vir iemand wat 'n transaksionele databasis moet skaal? Dit lyk of daar nog nie 'n enkele oplossing op die mark is wat by alle gebruiksgevalle pas nie. Daar is baie geslote en oopbronoplossings (waarvan sommige in hierdie artikel genoem word), elk met hul eie sterk- en swakpunte, maar nie een van hulle bied SaaS met 'n 99,999% SLA en 'n hoë mate van konsekwentheid nie. As 'n hoë SLA jou primêre doelwit is en jy nie geneig is om jou eie oplossing vir veelvuldige wolke te bou nie, is Cloud Spanner dalk die oplossing waarna jy soek. Maar jy moet bewus wees van al sy beperkings.
Om regverdig te wees, is Cloud Spanner eers in die lente van 2017 aan die publiek vrygestel, so dit is redelik om te verwag dat sommige van sy huidige gebreke uiteindelik kan verdwyn (hopelik), en wanneer dit wel gebeur, kan dit 'n speletjie-wisselaar wees. Cloud Spanner is immers nie net 'n byprojek vir Google nie. Google gebruik dit as die basis vir ander Google-produkte. En toe Google onlangs Megastore in Google Cloud Storage met Cloud Spanner vervang het, het dit Google Cloud Storage toegelaat om hoogs konsekwent te word vir objeklyste op 'n globale skaal (wat steeds nie die geval is vir ).
So, daar is nog hoop ... ons hoop.
Dis al. Soos die skrywer van die artikel, bly ons ook hoop, maar wat dink jy hiervan? Skryf in die kommentaar
Ons nooi almal uit om ons te besoek waarin ons jou in detail oor die kursus sal vertel van OTUS.
Bron: will.com