Tere, Khabrovites. Traditsiooniliselt jätkame huvitava materjali jagamist uute kursuste alguse eel. Täna tõlkisime spetsiaalselt teie jaoks artikli Google Cloud Spanneri kohta, mis on ajastatud kursuse käivitamisega .
Algselt avaldati aastal .
Ettevõttena, mis pakub erinevaid pilvepõhiseid POS-lahendusi jaemüüjatele, restoranipidajatele ja veebikaupmeestele üle maailma, kasutab Lightspeed mitut erinevat tüüpi andmebaasiplatvorme mitmesuguste tehingu-, analüüsi- ja otsingujuhtude jaoks. Igal neist andmebaasiplatvormidest on oma tugevad ja nõrgad küljed. Seega, kui Google tõi turule Cloud Spanneri – paljulubavaid funktsioone, mida relatsiooniandmebaaside maailmas pole näha, nagu praktiliselt piiramatu horisontaalne mastaapsus ja 99,999% teenusetaseme leping (SLA) , Me ei saanud kasutamata jätta võimalust teda meie käes hoida!
Et anda põhjalik ülevaade meie kogemusest Cloud Spanneriga ja kasutatud hindamiskriteeriumidest, käsitleme järgmisi teemasid:
- Meie hindamiskriteeriumid
- Pilvevõti lühidalt
- Meie hinnang
- Meie leiud
1. Meie hindamiskriteeriumid
Enne kui sukelduda Cloud Spanneri eripäradesse, selle sarnasustesse ja erinevustesse teiste turul leiduvate lahendustega, räägime esmalt peamistest kasutusjuhtudest, mida pidasime silmas, kui kaalusime, kuhu oma infrastruktuuris Cloud Spanneri juurutada:
- Asendusena (valitsevale) traditsioonilisele SQL andmebaasilahendusele
- OLAP-toega OLTP-lahendusena
Märkus: Võrdluse hõlbustamiseks võrreldakse selles artiklis Cloud Spannerit GCP Cloud SQL-i ja Amazon AWS RDS-i lahendusperekondade MySQL-i variantidega.
Cloud Spanneri kasutamine traditsioonilise SQL-i andmebaasilahenduse asendajana
Keskkonnas traditsiooniline andmebaaside puhul, kui andmebaasipäringu reageerimisaeg läheneb või isegi ületab eelmääratletud rakenduse künniseid (peamiselt kasutajate ja/või päringute arvu suurenemise tõttu), on vastuseaja vähendamiseks vastuvõetava tasemeni mitu võimalust. Kuid enamik neist lahendustest hõlmab käsitsi sekkumist.
Näiteks on esimene samm vaadata erinevaid jõudlusega seotud andmebaasi sätteid ja häälestada need nii, et need vastaksid kõige paremini rakenduse kasutusstsenaariumi mustritele. Kui sellest ei piisa, saate valida, kas skaleerida andmebaasi vertikaalselt või horisontaalselt.
Rakenduse suurendamine hõlmab serveri eksemplari värskendamist, tavaliselt lisades rohkem protsessoreid/tuumasid, rohkem RAM-i, kiiremat salvestusruumi jne. Suurema riistvararessursside lisamine suurendab andmebaasi jõudlust, mõõdetuna peamiselt tehingutes sekundis, ja OLTP-süsteemide tehingute latentsust. Relatsiooniandmebaasisüsteemid (mis kasutavad mitme lõimega lähenemist), näiteks MySQL-i mastaabis hästi vertikaalselt.
Sellel lähenemisviisil on mitmeid puudusi, kuid kõige ilmsem on serveri maksimaalne suurus turul. Kui suurim serverieksemplari limiit on saavutatud, jääb järele ainult üks tee: skaleerimine.
Scale-out on lähenemisviis, mis lisab klastrisse rohkem servereid, et ideaaljuhul suurendada jõudlust lineaarselt, kui lisatakse rohkem servereid. Enamus traditsiooniline andmebaasisüsteemid ei skaleeri hästi või ei skaleerita üldse. Näiteks saab MySQL lugemistoimingute jaoks skaleerida, lisades alamlugejaid, kuid ei saa skaleerida kirjutamistoimingute jaoks.
Teisest küljest saab Cloud Spanner oma olemuse tõttu hõlpsasti horisontaalselt skaleerida ja minimaalse sekkumisega.
Täisfunktsiooniga DBMS kui teenus tuleb hinnata erinevatest vaatenurkadest. Aluseks võtsime pilves kõige populaarsema DBMS-i - Google'i jaoks GCP Cloud SQL ja Amazoni jaoks AWS RDS. Oma hindamisel keskendusime järgmistele kategooriatele:
- Funktsioonide kaardistamine: SQL-i ulatus, DDL, DML; ühendusteegid/pistikud, tehingutugi jne.
- Arendustugi: arendamise ja testimise lihtsus.
- Haldustugi: eksemplaride haldamine, näiteks eksemplaride suurendamine/vähendamine ja uuendamine; SLA, varundamine ja taastamine; turvalisus/juurdepääsu kontroll.
Cloud Spanneri kasutamine OLAP-toega OLTP-lahendusena
Kuigi Google ei ütle selgesõnaliselt, et Cloud Spanner on analüütika jaoks, jagab see mõningaid atribuute teiste mootoritega, nagu Apache Impala & Kudu ja YugaByte, mis on loodud OLAP-i töökoormuste jaoks.
Isegi kui oleks vaid väike võimalus, et Cloud Spanner sisaldas järjekindlat laiendatavat HTAP-i (hübriidtehingu-/analüütiline töötlemine) koos (enam-vähem) kasutatava OLAP-i funktsioonikomplektiga, vääriks see meie arvates meie tähelepanu.
Seda silmas pidades vaatlesime järgmisi kategooriaid.
- Andmete laadimise, indeksite ja partitsioonide tugi
- Päringu jõudlus ja DML
2. Pilvevõti lühidalt
Google Spanner on rühmitatud relatsiooniandmebaasi haldussüsteem (RDBMS), mida Google kasutab mitme oma teenuse jaoks. Google tegi selle Google Cloud Platformi kasutajatele avalikult kättesaadavaks 2017. aasta alguses.
Siin on mõned Cloud Spanneri atribuudid.
- Väga järjepidev, skaleeritav RDBMS-klaster: kasutab andmete järjepidevuse tagamiseks riistvaralise aja sünkroonimist.
- Tabelitevaheliste tehingute tugi: tehingud võivad hõlmata mitut tabelit – mitte tingimata ühe tabeliga (erinevalt Apache HBase'ist või Apache Kudust).
- Esmase võtmepõhised tabelid: kõikidel tabelitel peab olema deklareeritud primaarvõti (PC), mis võib koosneda mitmest tabeli veerust. Tabeliandmed salvestatakse arvuti järjekorras, mis muudab selle arvutiotsingu jaoks väga tõhusaks ja kiireks. Nagu ka teiste arvutipõhiste süsteemide puhul, tuleb selle rakendamiseks mudelit kasutada eelarvamuste põhjal .
- Triibulised tabelid: tabelitel võivad olla üksteisest füüsilised sõltuvused. Alamtabeli ridu saab sobitada põhitabeli ridadega. Selline lähenemine kiirendab seoste otsimist, mida saab määrata andmete modelleerimise etapis, näiteks klientide ja nende arvete koostamisel.
- Indeksid: Cloud Spanner toetab sekundaarseid indekseid. Indeks koosneb indekseeritud veergudest ja kõigist arvuti veergudest. Valikuliselt võib register sisaldada ka muid indekseerimata veerge. Indeksi saab päringute kiirendamiseks põimida põhitabeliga. Indeksitele kehtivad mitmed piirangud, näiteks registrisse salvestatavate täiendavate veergude maksimaalne arv. Samuti ei pruugi päringud indeksite kaudu olla nii lihtsad kui teistes RDBMS-ides.
„Cloud Spanner valib indeksi automaatselt ainult harvadel juhtudel. Eelkõige ei vali Cloud Spanner automaatselt sekundaarset indeksit, kui päring nõuab veerge, mida pole salvestatud '.
- Teenusetaseme leping (SLA): ühe piirkonna juurutamine 99,99% SLA-ga; mitme piirkonna juurutamine 99,999% SLA-ga. Kuigi SLA ise on lihtsalt leping, mitte mingisugune garantii, usun, et Google'i inimestel on nii tugeva väite esitamiseks kõvasti andmeid. (Viide, 99,999% tähendab 26,3 sekundit teenuse seisakut kuus.)
- Veel:
Märkus: Apache Tephra projekt lisab Apache HBase'ile täiustatud tehingutoe (mis on nüüd ka Apache Phoenixis beetaversioonina rakendatud).
3. Meie hinnang
Seega oleme kõik lugenud Google'i avaldusi Cloud Spanneri eeliste kohta – praktiliselt piiramatu horisontaalne skaleerimine, säilitades samas kõrge järjepidevuse ja väga kõrge SLA. Kuigi neid väiteid on igal juhul äärmiselt raske saavutada, ei olnud meie eesmärk neid ümber lükata. Selle asemel keskendugem muudele asjadele, millest enamik andmebaasi kasutajaid korda läheb: võrdsus ja kasutatavus.
Hindasime Cloud Spannerit Sharded MySQL-i asenduseks
Google Cloud SQL ja Amazon AWS RDS, kaks kõige populaarsemat OLTP andmebaasi pilveturul, omavad väga suurt funktsioonide komplekti. Kuid selleks, et skaleerida neid andmebaase ühe sõlme suurusest kaugemale, peate rakenduse poolitama. Selline lähenemine muudab nii rakenduste kui ka halduse jaoks täiendava keerukuse. Uurisime, kuidas sobib Spanner mitme killu ühte eksemplari kombineerimise stsenaariumiga ja milliseid funktsioone (kui üldse) tuleb ohverdada.
SQL-i, DML-i ja DDL-i tugi, samuti konnektori ja teekide tugi?
Esiteks tuleb mis tahes andmebaasiga alustades luua andmemudel. Kui arvate, et saate JDBC mutrivõtme oma lemmik-SQL-tööriistaga ühendada, leiate, et saate selle abil oma andmeid pärida, kuid te ei saa seda kasutada tabeli või värskenduse (DDL) loomiseks ega mis tahes lisamiseks/värskendamiseks/kustutamiseks. operatsioonid (DML). Google'i ametlik JDBC ei toeta kumbagi.
"Draiverid ei toeta praegu DML- ega DDL-i avaldusi."
Mutrivõtme dokumentatsioon
GCP-konsooliga pole olukord parem – saate saata ainult SELECT päringuid. Õnneks on kogukonnal DML- ja DDL-toega JDBC draiver, sealhulgas tehingud . Kuigi see draiver on äärmiselt kasulik, üllatab Google'i enda JDBC draiveri puudumine. Õnneks pakub Google üsna laialdast klienditeegi tuge (põhineb gRPC-l): C#, Go, Java, node.js, PHP, Python ja Ruby.
Peaaegu kohustuslik Cloud Spanneri kohandatud API-de kasutamine (DDL-i ja DML-i puudumise tõttu JDBC-s) toob kaasa mõningaid piiranguid seotud koodipiirkondadele, nagu ühenduse ühendamine või andmebaasi sidumise raamistikud (nagu Spring MVC). Üldiselt saab JDBC-d kasutades vabalt valida oma lemmikühenduse basseini (nt HikariCP, DBCP, C3PO jne), mis on testitud ja töötab hästi. Kohandatud Spanner API-de puhul peame tuginema raamistikele/siduvatele/seansikogumitele, mille oleme ise loonud.
Primaarvõtmele (PC) orienteeritud disain võimaldab Cloud Spanneril arvuti kaudu andmetele juurde pääsedes olla väga kiire, kuid toob kaasa ka mõned päringuprobleemid.
- Primaarvõtme väärtust ei saa värskendada; Esmalt peate kustutama algse arvutikirje ja sisestama selle uuesti uue väärtusega. (See on sarnane teiste arvutile orienteeritud andmebaasi-/salvestusmootoritega.)
- Kõik UPDATE ja DELETE avaldused peavad WHERE-is määrama arvuti, seetõttu ei saa kõik DELETE-laused tühjad olla - alati peab olema alampäring, näiteks: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Puudub automaatse suurendamise suvand või midagi sarnast, mis määrab arvutivälja järjestuse. Et see toimiks, tuleb rakenduse poolele luua vastav väärtus.
Sekundaarsed indeksid?
Google Cloud Spanneril on sisseehitatud tugi teiseste indeksite jaoks. See on väga tore funktsioon, mida teistes tehnoloogiates alati ei ole. Apache Kudu ei toeta praegu sekundaarseid indekseid üldse ja Apache HBase ei toeta indekseid otse, kuid saab neid lisada Apache Phoenixi kaudu.
Kudu ja HBase'i indekseid saab modelleerida eraldi tabelina, millel on erinev primaarvõtmete koostis, kuid põhitabeli ja sellega seotud indeksitabelitega tehtavate toimingute atomaarsus tuleb läbi viia rakenduse tasemel ja see ei ole triviaalne, et seda õigesti rakendada.
Nagu Cloud Spanneri ülevaates mainitud, võivad selle indeksid MySQL-i indeksitest erineda. Seega tuleb päringute koostamisel ja profileerimisel olla eriti tähelepanelik, et seal, kus seda vajatakse, kasutatakse õiget indeksit.
Esindus?
Väga populaarne ja kasulik objekt andmebaasis on vaated. Need võivad olla kasulikud paljudel kasutusjuhtudel; minu kaks lemmikut on loogilise abstraktsiooni kiht ja turvakiht. Kahjuks EI toeta Cloud Spanner vaateid. Kuid see piirab meid vaid osaliselt, kuna juurdepääsulubade jaoks puudub veerutaseme detailsus, kus vaated võivad olla vastuvõetavad lahendused.
Kvootide ja piirangute üksikasjalikku jaotist vaadake Cloud Spanneri dokumentatsioonist (), on üks, mis võib mõne rakenduse puhul problemaatiliseks osutuda: Cloud Spanneril on ühe eksemplari kohta maksimaalselt 100 andmebaasi. Ilmselgelt võib see olla suureks takistuseks andmebaasi jaoks, mis on loodud skaleerima enam kui 100 andmebaasi. Õnneks avastasime pärast Google'i tehnilise esindajaga rääkimist, et seda limiiti saab Google'i toe kaudu suurendada peaaegu iga väärtuseni.
Arengutoetus?
Cloud Spanner pakub oma API-ga töötamiseks üsna korralikku programmeerimiskeele tuge. Ametlikult toetatud teegid on C#, Go, Java, node.js, PHP, Python ja Ruby piirkonnas. Dokumentatsioon on üsna üksikasjalik, kuid nagu ka teiste tipptehnoloogiate puhul, on kogukond enamiku populaarsemate andmebaasitehnoloogiatega võrreldes üsna väike, mistõttu võib kuluda rohkem aega vähem levinud kasutusjuhtudele või probleemidele.
Kuidas on siis lood kohaliku arengu toetusega?
Me ei leidnud võimalust kohapealse Cloud Spanneri eksemplari loomiseks. Meile kõige lähemal on Dockeri pilt mis on põhimõtteliselt sarnane, kuid praktikas väga erinev. Näiteks võib CockroachDB kasutada PostgreSQL JDBC-d. Kuna arenduskeskkond peaks olema tootmiskeskkonnale võimalikult lähedane, ei ole Cloud Spanner ideaalne, kuna peate tuginema täismutrivõtme eksemplarile. Kulude säästmiseks saate valida ühe piirkonna eksemplari.
Administratsiooni tugi?
Cloud Spanneri eksemplari loomine on väga lihtne. Peate lihtsalt valima mitme piirkonna või ühe piirkonna eksemplari loomise vahel, määrama piirkonna(d) ja sõlmede arvu. Vähem kui minuti pärast on eksemplar valmis ja töötab.
Mitmed elementaarsed mõõdikud on otse saadaval Google'i konsooli mutrivõtmelehel. Üksikasjalikumad vaated on saadaval Stackdriveri kaudu, kus saate määrata ka mõõdikute lävesid ja hoiatuspoliitikaid.
Juurdepääs ressurssidele?
MySQL pakub ulatuslikke ja väga üksikasjalikke kasutajalubade/rolli seadeid. Saate hõlpsasti kohandada juurdepääsu konkreetsele tabelile või isegi selle veergude alamhulgale. Cloud Spanner kasutab Google'i identiteedi ja juurdepääsu haldamise (IAM) tööriista, mis võimaldab seada eeskirju ja õigusi ainult väga kõrgel tasemel. Kõige üksikasjalikum valik on andmebaasitaseme luba, mis enamikel tootmisjuhtudel ei sobi. See piirang sunnib teid lisama oma koodile, infrastruktuurile või mõlemale täiendavaid turvameetmeid, et vältida Mutrivõtme ressursside volitamata kasutamist.
Varukoopiad?
Lihtsamalt öeldes pole Cloud Spanneris varukoopiaid. Kuigi Google'i kõrged SLA nõuded tagavad, et te ei kaota andmeid riistvara- või andmebaasitõrgete, inimlike vigade, rakendusedefektide jms tõttu. Me kõik teame reeglit: kõrge saadavus ei asenda nutikat varundusstrateegiat. Praegu on ainus viis andmete varundamiseks programmiliselt voogesitada need andmebaasist eraldi salvestuskeskkonda.
Kas küsida jõudlust?
Andmete laadimiseks ja päringute testimiseks kasutasime Yahoo!-i. Pilveteenuse võrdlusalus. Allolev tabel näitab B YCSB töökoormust 95% lugemise ja 5% kirjutamise suhtega.
* Koormustest viidi läbi n1-standard-32 Compute Engine (CE)-ga (32 vCPU-d, 120 GB mälu) ja testeksemplar ei olnud kunagi testide kitsaskohaks.
** Maksimaalne lõimede arv ühes YCSB eksemplaris on 400. Kokku tuli käivitada kuus paralleelset YCSB testide eksemplari, et saada kokku 2400 lõime.
Vaadates võrdlusuuringu tulemusi, eriti CPU koormuse ja TPS-i kombinatsiooni, näeme selgelt, et Cloud Spanner skaleerub üsna hästi. Suure hulga lõimede tekitatud suurt koormust kompenseerib Cloud Spanner klastri suur hulk sõlme. Kuigi latentsusaeg tundub üsna suur, eriti 2400 lõimega töötades, võib täpsemate arvude saamiseks osutuda vajalikuks uuesti testida 6 väiksema arvutusmootori eksemplariga. Iga eksemplar käivitab ühe YCSB-testi ühe suure, kuue paralleeltestiga CE-eksemplari asemel. See hõlbustab Cloud Spanneri päringu viivituste ja viivituste eristamist, mille lisab võrguühendus Cloud Spanneri ja testi käivitava CE-eksemplari vahel.
Kuidas Cloud Spanner OLAP-ina toimib?
Partitsioneerimine?
Andmete jagamine füüsiliselt ja/või loogiliselt sõltumatuteks segmentideks, mida nimetatakse partitsioonideks, on enamikus OLAP-mootorites väga populaarne kontseptsioon. Sektsioonid võivad oluliselt parandada päringu jõudlust ja andmebaasi hooldatavust. Partitsioonidesse süvenemine oleks eraldi artikkel(id), seega mainigem lihtsalt partitsiooniskeemi ja alampartitsioneerimise tähtsust. Võimalus jagada andmeid partitsioonideks ja veelgi enam alamsektsioonideks on analüütiliste päringute toimimise võtmeks.
Cloud Spanner ei toeta partitsioone iseenesest. See eraldab andmed sisemiselt nn jagada-s põhinevad esmase võtme vahemikel. Jaotamine toimub automaatselt, et tasakaalustada Cloud Spanneri klastri koormust. Cloud Spanneri väga mugav funktsioon on põhitabeli (tabeli, mis pole teisega põimitud) baaskoormuse jagamine. Mutrivõti tuvastab automaatselt, kas see sisaldab jagada andmeid, mida loetakse sagedamini kui teistes jagada-ah, ja võib otsustada edasise lahkumineku üle. Seega saab päringusse kaasata rohkem sõlme, mis suurendab tõhusalt ka läbilaskevõimet.
Kas laadite andmeid?
Cloud Spanneri meetod hulgiandmete jaoks on sama, mis tavalise üleslaadimise puhul. Maksimaalse jõudluse saavutamiseks peate järgima mõningaid juhiseid, sealhulgas:
- Sorteerige oma andmed primaarvõtme järgi.
- Jagage need 10-ga*sõlmede arv üksikud sektsioonid.
- Looge tööülesannete komplekt, mis laadib andmeid paralleelselt.
See andmelaadimine kasutab kõiki Cloud Spanneri sõlmi.
10 miljoni rea andmestiku loomiseks kasutasime A YCSB töökoormust.
* Koormustest viidi läbi arvutusmootoril n1-standard-32 (32 vCPU-d, 120 GB mälu) ja testeksemplar ei olnud kunagi testide kitsaskohaks.
** 1 sõlme seadistus ei ole ühegi tootmistöökoormuse jaoks soovitatav.
Nagu eespool mainitud, töötleb Cloud Spanner jaotusi automaatselt sõltuvalt nende koormusest, nii et tulemused paranevad pärast mitut järjestikust testi iteratsiooni. Siin esitatud tulemused on meie parimad tulemused. Ülaltoodud numbreid vaadates näeme, kuidas Cloud Spanner skaleerub (hästi), kui sõlmede arv klastris suureneb. Arvud, mis paistavad silma, on äärmiselt madal keskmine latentsusaeg, mis on kontrastiks segatöökoormuse (95% lugemine ja 5% kirjutamine) tulemustega, nagu on kirjeldatud ülaltoodud jaotises.
Skaleerimine?
Cloud Spanneri sõlmede arvu suurendamine ja vähendamine on ühe klõpsuga ülesanne. Kui soovite andmeid kiiresti laadida, võiksite kaaluda eksemplari maksimaalset suurendamist (meie puhul oli see USA-Ida piirkonnas 25 sõlme) ja seejärel pärast kõigi andmete saamist vähendada teie tavapäraseks laadimiseks sobivate sõlmede arvu. andmebaasis, pidades silmas piirangut 2 TB/sõlme kohta.
Seda limiiti tuletati meile meelde ka palju väiksema andmebaasiga. Pärast mitut koormustesti oli meie andmebaasi suurus umbes 155 GB ja 1 sõlme eksemplariks vähendades saime järgmise vea:
Suutsime vähendada eksemplari 25-lt 2-le, kuid oleme kinni kahes sõlmes.
Cloud Spanneri klastri sõlmede arvu suurendamist ja vähendamist saab REST API abil automatiseerida. See võib olla eriti kasulik süsteemi suurenenud koormuse vähendamiseks kiiretel tundidel.
OLAP-i päringu jõudlus?
Algselt plaanisime pühendada palju aega Spanneri hindamisele selles osas. Pärast paari SELECT COUNT-i saime kohe aru, et test saab olema lühike ja et Spanner EI OLE OLAP-i jaoks sobiv mootor. Sõltumata sõlmede arvust klastris, kulus 10 miljoni rea tabelis lihtsalt ridade arvu valimiseks 55–60 sekundit. Samuti nurjus kõik päringud, mis nõudsid vahetulemuste salvestamiseks rohkem mälu, OOM-veaga.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Mõned numbrid TPC-H päringute jaoks leiate Todd Lipconi artiklist , slaidid 42 ja 43. Need arvud on kooskõlas meie enda tulemustega (kahjuks).
4. Meie leiud
Arvestades Cloud Spanneri funktsioonide praegust olekut, on raske näha seda olemasoleva OLTP-lahenduse lihtsa asendusena, eriti kui teie vajadused on sellest suuremad. Cloud Spanneri puuduste ümber lahenduse leidmiseks tuleks kulutada märkimisväärne hulk aega.
Kui alustasime Cloud Spanneri hindamist, eeldasime, et selle haldusfunktsioonid on samaväärsed või vähemalt mitte kaugel teistest Google SQL-i lahendustest. Kuid meid üllatas varukoopiate täielik puudumine ja väga piiratud juurdepääsukontroll ressurssidele. Rääkimata vaadete puudumisest, kohaliku arenduskeskkonna puudumisest, toetamata järjestustest, DML-i ja DDL-i toeta JDBC-st jne.
Niisiis, kuhu minna inimesele, kes peab tehingute andmebaasi skaleerima? Tundub, et turul pole veel ühtegi lahendust, mis sobiks kõikidele kasutusjuhtudele. Suletud ja avatud lähtekoodiga lahendusi on palju (mõned neist on selles artiklis mainitud), millest igaühel on oma tugevad ja nõrgad küljed, kuid ükski neist ei paku 99,999% SLA-ga ja kõrge järjepidevusega SaaS-i. Kui teie esmane eesmärk on kõrge SLA ja te ei soovi mitme pilve jaoks oma lahendust luua, võib Cloud Spanner olla see lahendus, mida otsite. Kuid peaksite olema teadlik kõigist selle piirangutest.
Ausalt öeldes avaldati Cloud Spanner avalikkusele alles 2017. aasta kevadel, seega on mõistlik eeldada, et mõned selle praegused vead võivad lõpuks (loodetavasti) kaduda ja kui see juhtub, võib see muuta mängu. Lõppude lõpuks ei ole Cloud Spanner lihtsalt Google'i kõrvalprojekt. Google kasutab seda teiste Google'i toodete alusena. Ja kui Google asendas hiljuti Google Cloud Storage'i Megastore'i teenuses Cloud Spanner, võimaldas see Google Cloud Storage'il muutuda globaalses mastaabis objektiloendite jaoks väga järjepidevaks (mis pole ikka veel nii ).
Seega on veel lootust... loodame.
See on kõik. Sarnaselt artikli autorile loodame ka meie jätkuvalt, aga mida te sellest arvate? Kirjutage kommentaaridesse
Kutsume kõiki meiega tutvuma milles räägime teile üksikasjalikult kursusest alates OTUS.
Allikas: www.habr.com