Google Cloud Spanner: hea, halb, kole

Tere, Habrikad. Jätkame traditsiooniliselt huvitava sisu jagamist, enne kui uued kursused algavad. Täna, just teie jaoks, tõlgime artikli Google Cloud Spannerist, seostades selle kursuse käivitamisega. „AWS arendajatele“.

Algne avaldamine Lightspeed HQ blogis.

Kuna Lightspeed pakub hulgaliselt pilvepõhiseid POS-lahendusi jaekaubanduse, restoranide ja veebimüüjate jaoks üle kogu maailma, kasutab ettevõte erinevaid andmebaasiplatvorme paljude tehinguliste, analüütiliste ja otsingujuhtumite jaoks. Igaühel neist andmebaasiplatvormidest on oma tugevused ja nõrkused. Seetõttu, kui Google tutvustas turule Cloud Spannerit – paljutõotavad funktsioonid, mida pole nähtud relatsiooniliste andmebaaside maailmas, nagu praktiliselt piiramatu horisontaalne skaleeritavus ja 99,999% teenustaseme leping (SLA) –, ei saanud me selle kasutuselevõttu mööda lasta!

Kuna anname põhjaliku ülevaate meie kogemusest Cloud Spanneriga ning hindamiskriteeriumitest, mida kasutasime, käsitleme järgmisi teemasid:

1. Meie hindamiskriteeriumid
2. Cloud Spanner kaks sõna
3. Meie hinnang
4. Meie järeldused

1. Meie hindamiskriteeriumid

Enne kui süveneme Cloud Spanneri funktsioonidesse, selle sarnastesse ja erinevustesse turul olevate lahenduste suhtes, räägime kõigepealt peamistest kasutusjuhtudest, mida pidasime silmas, arutades, kuhu integreerida Cloud Spanner meie infrastruktuuri:

• Klassikalise SQL andmebaasi lahenduse asendajana
• OLTP lahendusena, millel on OLAP tugi

Märkus: Mugavuse ja kasutajasõbralikkuse huvides võrdleb see artikkel Cloud Spannerit MySQL variandi GCP Cloud SQL ja Amazon AWS RDS lahendustega.

Cloud Spanneri kasutamine traditsioonilise SQL andmebaasi lahenduse asendamiseks

Keskkonnas traditsioonilised andmebaasid, kui andmebaasi päringu vastuse aeg läheneb või isegi ületab eelmise määratletud rakenduse läve (peamiselt kasutajate ja / või päringute arvu suurenemise tõttu), on mitmeid viise vastuse aja vähendamiseks vastuvõetavatesse tasemetes. Kuid enamik neist lahendustest hõlmab käsitsi sekkumist.

Näiteks, esimene samm, mida teha, on vaadata erinevaid andmebaasi seadistusi, mis on seotud jõudlusega, ja kohandada neid nii, et need vastaksid kõige paremini rakenduste kasutusstsenaariumide mustritele. Kui sellest ei piisa, võib valida andmebaasi vertikaalse või horisontaalse skaleerimise.

Rakenduse vertikaalne skaleerimine tähendab serveri instantsi uuendamist, tavaliselt suurema arvu protsessorite/tuumade, suurema mälu ja kiirema salvestusruumi lisamise abil jne. Suuremate riistvararessursside lisamine parandab andmebaasi jõudlust, mida mõõdetakse peamiselt tehingute arvu järgi sekundis ning tehingute latentsusena OLTP süsteemides. Suhteliste andmebaasisüsteemide (mis kasutavad mitmeõngemudelit), nagu MySQL, vertikaalne skaleerimine toimub hästi.

Sellel lähenemisel on mitmeid puudusi, kuid kõige ilmsem on turul oleva serveri maksimaalne suurus. Kui on saavutatud suurima serveri instantsi piir, on ainus viis edasi: horisontaalne skaleerimine.

Horisontaalne skaleerimine on lähenemine, kus klastrile lisatakse rohkem servereid, et ideaalis lineaarselt suurendada jõudlust serverite arvu kasvades. Enamik traditsioonilised andmebaasisüsteemidest ei skaleerita horisontaalselt hästi või üldse mitte. Näiteks MySQL suudab horisontaalselt skaleerida lugemisoperatsioonide jaoks, lisades slave-loendureid, kuid ei suuda horisontaalselt skaleerida kirjutamisoperatsioonide jaoks.

Teisest küljest suudab Cloud Spanner oma loomuse tõttu hõlpsasti horisontaalselt skaleerida minimaalse sekkumisega.

Täiendav funktsionaalsus Andmebaas kui teenus peaks olema hinnatud erinevatest külgedest. Alguseks võtsime kõige populaarsema pilvandmebaasi — Google'i GCP Cloud SQL ja Amazoni AWS RDS. Oma hindamises keskendusime järgmistele kategooriatele:

• Funktsioonide vastavus: SQL, DDL, DML; ühendusraamatukogud/konnektorid, tehingute toetamised jne.
• Arenduse tugi: arendamise ja testimise lihtsus.
• Halduse tugi: instantside haldamine — näiteks üles-alla skaleerimine ja instantside täiendamine; SLA, varundamine ja taastamine; turve/ligipääsu kontroll.

Cloud Spanneri kasutamine OLTP lahenduse jaoks, mis toetab OLAP-i.

Kuigi Google ei väida selgesõnaliselt, et Cloud Spanner on mõeldud analüütiliseks töötlemiseks, jagab see mõningaid omadusi teiste mootoritega, nagu Apache Impala & Kudu ja YugaByte, mis on mõeldud OLAP-i töökoormusteks.

Isegi kui Cloud Spanneril oleks ainult väike tõenäosus sisaldada konsolideeritud horisontaalselt skaleeritavat HTAP (hübriidne tehingu/analuütiline töötlemine) mootorit koos (rohkem-vähem) kasutatava OLAP funktsioonide kogumiga, arvame, et see vääriks meie tähelepanu.

Seda silmas pidades oleme vaadanud järgmisi kategooriaid:

• Andmete laadimine, indeksid ja partitsioneerimise tugi.
• Küsimuste ja DML jõudlus.

2. Cloud Spanner lühidalt.

Google Spanner on klastritehalduse relatsiooniliste andmebaaside süsteem (RDBMS), mida Google kasutab mitmete oma teenuste jaoks. Google avas selle avalikkusele Google Cloud Platformis 2017. aasta alguses.

Siin on mõned Cloud Spanneri omadused:

• Tugevalt konsolideeritud skaleeritav RDBMS klaster: kasutab ajasünkroniseerimist andmete konsistentsi tagamiseks.
• Kross-tabelitehingute tugi: tehingud võivad katab mitmeid tabeleid — ei pea olema piiratud ühe tabeliga (erinevalt Apache HBase'ist või Apache Kudust).
• Esmaste võtmete põhised tabelid: kõik tabelid peavad omama deklareeritud esmast võtme (EV), mis võib koosneda mitmest tabeli veerust. Tabeliandmed salvestatakse EV järgi, mistõttu on need väga tõhusad ja kiired EV järgi otsimiseks. Nagu teised EV-põhised süsteemid, peab rakendus olema modelleeritud eelnevalt läbi mõeldud kasutusjuhtide saavutamiseks. parimat jõudlust..
• Vahelduvad tabelid: tabelid võivad omavahel füüsiliselt sõltuda. Alustabeli read võivad vastanduda pealtabeli ridadele. Selline lähenemine kiirus suhted, mis võivad andmemudeli loomise etapis kindlaks määrata, näiteks klientide ja nende arvete koospaigutamisel.
• Indeksid: Cloud Spanner toetab teiseseid indekseid. Indeks koosneb indekseeritud veergudest ja kõigist PK veergudest. Soovi korral võib indeks sisaldada ka teisi indekseerimata veerge. Indeks võib vahelduda pealtabeliga, et päringute täitmist kiirendada. Indeksitele kehtivad mitmed piirangud, näiteks maksimaalne täiendavate veergude arv, mida indeksi sees hoida võib. Lisaks ei pruugi indeksite kaudu päringud olla nii sirged kui teistes RDBMS-des.

„Cloud Spanner valib indeksi automaatselt vaid harvadel juhtudel. Eelkõige ei vali Cloud Spanner teist indeksit automaatselt, kui päring nõuab mõningaid veerge, mida ei hoita indeksis ».

• Teenuse taseme leping (SLA): ühes piirkonnas juurutamine SLA-ga 99,99%; mitme piirkonna juurutamine 99,999% SLA-ga. Kuigi teenuse taseme leping ise on vaid leping, mitte mingisugune garantii, usun, et Google'i töötajatel on tõeliselt täpsed andmed, et teha selline tõsine väide. (Infoks, 99,999% tähendab, et teenuse aegumise aeg on 26,3 sekundit kuus.)
• Rohkem: https://cloud.google.com/spanner/

Märkus: Apache Tephra projekt lisab Apache HBase'ile laienenud tehingute toe (näiteks on see nüüd rakendatud Apache Phoenixis beetaversioonina).

3. Meie hinnang

Nii et kõik oleme lugenud Google'i väiteid Cloud Spanneri eeliste kohta — praktiliselt piiramatu horisontaalne skaala säilitades samal ajal kõrge järjepidevuse ja väga kõrge SLA. Kuigi nende nõudmiste saavutamine on igal juhul äärmiselt raske, ei olnud meie eesmärk nende ümber lükata. Selle asemel keskendugem muudele asjadele, mis puudutavad enamikku andmebaasi kasutajatest: õigsus ja kasutusmugavus.

Hindasime Cloud Spannerit kui asendust Sharded MySQL-le.

Google Cloud SQL ja Amazon AWS RDS, kaks kõige populaarsemat OLTP andmebaasi pilveturul, omavad väga suurt funktsioonide kogumit. Siiski, et skaleerida neid andmebaase üle ühe sõlme suuruse, peate rakenduste jaotamisel need jagama. Selline lähenemine toob kaasa lisaks keerukust nii rakendustele kui ka haldamisele. Oleme vaadanud, kuidas Spanner sobib mitme segmendi ühendamise stsenaariumisse üheks instantsiks ja millistest funktsioonidest (kui ühtegi) tuleb võib-olla loobuda.

SQL, DML ja DDL toetamine, samuti konnektor ja raamatukogud?

Esiteks, olenemata sellest, millise andmebaasi kasutusele võtmisest on oluline luua andmemudel. Kui arvate, et saate oma lemmik SQL-tööriista JDBC Spanneriga ühendada, avastate, et saate oma andmeid selle abil pärida, kuid ei saa seda kasutada tabelite loomise või muutmise (DDL) ning insert/update/delete (DML) operatsioonide jaoks. Google'i ametlik JDBC ei toeta ei ühtegi ega teist.

„Praegu ei toeta draiverid DML- või DDL-lauseid.“
Spanneri dokumentatsioon

GCP konsooliga pole olukord parem – saate esitada ainult SELECT-päringuid. Õnneks on olemas avatud jüri DML ja DDL toetava JDBC draiver, sealhulgas tehingud. github.com/olavloite/spanner-jdbc. Kuigi see draiver on äärmiselt kasulik, üllatab Google'i enda JDBC draiveri puudumine. Õnneks pakub Google üsna laialdast kliente toetavaid raamatukogusid (gRPC põhjal): C#, Go, Java, node.js, PHP, Python ja Ruby.

Peaaegu kohustuslik Cloud Spanneri kohandatud API-de kasutamine (DDL ja DML puudumise tõttu JDBC-s) toob kaasa mõned piirangud seotud koodivaldkondades, nagu ühenduse basseinid või andmebaasi sidumisseired (nt Spring MVC). Üldiselt on JDBC kasutamisel võimalik vabalt valida oma lemmik ühenduse bassein (nt HikariCP, DBCP, C3PO jne), mis on testitud ja töötab hästi. Kui tegemist on kohandatud Spanneri API-dega, peame toetuma raamistikele/ühenduse basseinidele/istungitele, mille oleme ise loodud.

Peamise võtme (PV) suunitlus võimaldab Cloud Spanneril olla väga kiire andmete juurdepääsuks läbi PV, kuid see toob ka kaasa teatud päringute probleemid.

• Te ei saa muuta esmase võtme väärtust; peate esmalt kustutama kirje originaalse PK-ga ja seejärel sisestama selle uuesti koos uue väärtusega. (See sarnaneb teistele PK orienteeritud andmebaasidele/hoidmismehhanismidele.)
• Kõik UPDATE ja DELETE käsklused peavad määrama PK WHERE lauses, seega ei tohi olla tühje DELETE all — alati peab olema alamklausel, näiteks: UPDATE xxx WHERE id IN (SELECT id FROM table1)
• Puuduvad automaatse inkremendi valikud või midagi sellist, mis määrab PK väljade järjestuse. Selleks, et see toimiks, peab vastav väärtus olema genereeritud rakenduse tasandil.

Teised indeksid?

Google Cloud Spanner toetab sisseehitatud teise taseme indeksite toetust. See on väga kena omadus, mida ei pruugi leida teistest tehnoloogiatest. Apache Kudu ei toeta praegu teisi indekseid üldse, samas kui Apache HBase ei toeta indekseid otse, kuid saab neid lisada Apache Phoenixi kaudu.

Kudu ja HBase indekseid saab modelleerida kui eraldi tabelit erineva esmase võtme koosseisuga, kuid vanematele tabelitele ja seotud indeksitabelitele teostatavad operatsioonide aatomisus tuleb tagada rakenduse tasandil ning see ei ole triviaalne õige rakenduse puhul.

Nagu juba mainitud Cloud Spanneri ülevaates, võivad selle indeksid erineda MySQL indeksitest. Seetõttu tuleks olla äärmiselt ettevaatlik päringute koostamisel ja profileerimisel, et tagada, et õiged indeksid oleksid kasutuses seal, kus neid on vaja.

Vaated?

Väga populaarne ja kasulik objekt andmebaasis on vaated. Need võivad olla kasulikud paljude kasutusjuhtude jaoks; kaks minu lemmikut on loogilise abstraktsiooni tase ja turvalisuse tase. Kahjuks ei toeta Cloud Spanner vaateid. Kuid see piirab meid ainult osaliselt, kuna juurdepääsuõiguste detailid ei ole veergude tasandil, kus vaated võivad olla vastuvõetav lahendus.

Cloud Spanneri dokumentatsioonis, millel on kvootide ja piirangute kirjeldus (spanner/quotas), on on mitmeid, mis võivad mõne rakenduse jaoks probleemiks kujuneda: Cloud Spanneril on vaikimisi piirang, et instantsil võib olla maksimaalselt 100 andmebaasi. Ilmselgelt võib see kujuneda tõsiseks takistuseks andmebaasile, mis on mõeldud rohkem kui 100 andmebaasi skaleerimiseks. Õnneks, pärast vestlust meie Google'i tehnilise esindajaga, selgus, et seda piiri saab suures osas tõsta praktiliselt mistahes väärtuseni Google'i tugiteenuse kaudu.

Arenduse tugi?

Cloud Spanner pakub üsna head programmeerimiskeelte tuge oma API kasutamiseks. Ametlikult toetatud raamatukogud hõlmavad C#, Go, Java, node.js, PHP, Python ja Ruby. Dokumentatsioon on piisavalt detailne, kuid nagu paljude teiste tipptasemel tehnoloogiate puhul, on kogukond suhteliselt väike võrreldes populaarsemate andmebaasitehnoloogiatega, mis võib pikendada aega, mis kulub vähem levinud kasutusjuhtumite või probleemide lahendamiseks.

Kuidas on lood lokaalsete arendustegevuse tugiteenustega?

Me ei leidnud viisi, kuidas luua Cloud Spanneri instants lokaalses keskkonnas. Kõige lähem, mida me saime, oli Docker-pilt. CockroachDB, mis on põhimõtteliselt sarnane, kuid praktikas tugevalt erinev. Näiteks saab CockroachDB kasutada PostgreSQL JDBC-d. Kuna arenduskeskkond peaks olema võimalikult lähedane tootmisliideselt, ei ole Cloud Spanner ideaalne, kuna tuleb tugineda täielikule Spanneri instantsile. Kulude kokkuhoidmiseks võite valida ühe piirkonna instantsi.

Administratsiooni tugi?

Cloud Spanneri instantsi loomine on väga lihtne. Tuleb lihtsalt valida, kas luua mitmeregionaalne või üheregionaalne instants, määrata piirkonnad ja sõlmede arv. Vähem kui minuti jooksul on instants käivitunud ja tööks valmis.

Mõned põhistatistika on otse kergesti kergesti kätte saadavad Google'i konsoolis Spanneri lehelt. Täiendavad vaated on saadaval läbi Stackdriveri, kus saate ka seadistada mõõdikute piirväärtusi ja teavitamispoliitikaid.

Juurdepääs ressurssidele?

MySQL pakub laialdasi ja väga üksikasjalikke kasutajaõiguste/rollide seadistusi. Kui soovite, saate hõlpsasti seadistada juurdepääsu kindlale tabelile või isegi lihtsalt alamhulgale selle veergudest. Cloud Spanner kasutab Google'i identiteedi ja juurdepääsu halduse (IAM) tööriista, mis võimaldab seada poliitikaid ja õigusi ainult väga kõrgel tasemel. Kõige detailsem variant on andmebaasi tasemel õigus, mis ei sobi enamiku tootmisjuhtumitega. See piirang sunnib teid lisama oma koodi, infrastruktuuri või mõlema lisakaitsemeetmeid Spanneri ressursside volitamata kasutamise vältimiseks.

Varukoopiad?

Lihtsalt öeldes ei eksisteeri Cloud Spanneris varukoopiaid. Kuigi Google'i SLA kõrged nõuded võivad tagada, et te ei kaota andmeid seadme või andmebaasi ülekoormuse tõttu, ei kaitse need inimvigade, rakenduse defektide jne eest. Me kõik teame reeglit: kõrge kättesaadavus ei asenda mõistlikku varukoopiate strateegiat. Praegu on ainus viis andmete varundamiseks nende voogedastamine andmebaasist eraldi salvestuskeskkonda.

Päringute jõudlus?

Andmete laadimiseks ja päringute testimiseks kasutasime Yahoo! Cloud Serving Benchmark'i. Allolevas tabelis on esitatud YCSB töökoormus B, mille lugemise suhe on 95% ja kirjutamise suhe 5%.

* Koormustest viidi läbi arvutusmootoril (CE) n1-standard-32 (32 vCPU, 120 GB mälu), ja testimisinstants ei olnud kunagi testide kitsaskohaks.
** Ühe YCSB instantsi maksimaalne lõimede arv on 400. Kokku tuli käivitada kuus paralleelset YCSB testide instantsi, et saavutada kokku 2400 lõime.

Tulemusi silmas pidades, eriti protsessori koormuse ja TPS kombinatsiooni osas, näeme selgelt, et Cloud Spanner suudab piisavalt hästi skaleeruda. Suure koormuse, mille tekitab suur arv vooge, kompenseerib Cloud Spanneri klastris olev suur arv sõlmi. Kuigi latentsus näib olevat üsna kõrge, eriti 2400 voo korral, võib täpsemate numbrite saamiseks olla vajalik uuesti testimine 6 väiksema arvutusmootoriga eksemplariga. Iga eksemplar käivitab ühe YCSB testi, selle asemel et kasutada ühte suurt CE eksemplari 6 paralleelse testiga. Nii on kergem eristada Cloud Spanneri päringute latentsust ja latentsust, mille toob kaasa võrguühendus Cloud Spanneri ja CE eksemplari vahel, kus test viiakse läbi.

Kuidas Cloud Spanner OLAP-iga toime tuleb?

Partitsioneerimine?

Andmete jagamine füüsiliselt ja/või loogiliselt iseseisvateks segmentideks, mida nimetatakse partitsioonideks, on väga populaarne kontseptsioon, mis on iseloomulik enamikule OLAP mehhanismidele. Partitsioonid võivad oluliselt parandada päringute jõudlust ja andmebaasi hooldatavust. Sügavam käsitlus partitsioonide üle kujundaks eraldi artikli(e), seega mainime lihtsalt partitsioneerimise ja alam-partitsioneerimise skeemi olemasolu tähtsust. Võime andmed partitsioonideks jagada ja isegi edasi alam-partitsioonideks on võtmetähtsusega analüütiliste päringute jõudluses.

Cloud Spanner ei toeta partitsioone sellisel kujul. See jagab andmed seespool nii-öelda split-deks, mis põhinevad peamise võtme vahemikel. Jagamine toimub automaatselt, et tasakaalustada koormust Cloud Spanneri klastris. Väga mugav omadus Cloud Spanneris on ematahlaava koormuse jagamine (tabel, mis ei vaheldu teisega). Spanner kindlaks teeb, kas split andmed, mida loetakse sagedamini kui muudest split-dest, ja võib otsustada edasise jagamise üle. Nii saab päringus osaleda rohkem sõlmi, mis suurendab samuti läbilaskevõimet.

Andmete laadimine?

Cloud Spanneri meetod mahukate andmete laadimiseks on sama, mis tava-laadimisel. Parima jõudluse saavutamiseks peate järgima mõningaid soovitusi, sealhulgas:

• Korrastage oma andmed primaarvõtme järgi.
• Jagage need kümneks*sõlmede arv eraldi sektsioonides.
• Looge tööülesannete kogum, mis laadib andmeid paralleelselt.

Selle laadimise käigus kasutatakse kõiki Cloud Spanneri sõlmi.

Kasutasime A YCSB koormust, et genereerida 10M rea andmesett.

* Koormustest tehti n1-standard-32 (32 vCPU, 120 GB mälu) arvutusvõimsusel ning testimisinstituudi ei täheldatud kitsaskohana testide jooksul.
** Üksiku sõlme seadistamine ei ole soovitatav ühegi tootmiskoormuse jaoks.

Nagu eespool mainitud, haldab Cloud Spanner automaatselt jagamist sõltuvalt nende koormusest, seega paranevad tulemused pärast mitut järjestikust katset. Siin esitatud tulemused on parimad, mida oleme saavutanud. Kui vaatame ülaltoodud numbreid, näeme, kuidas Cloud Spanner (hästi) skaleerub koos sõlmede arvu suurenemisega klastris. Tunduvad numbrid esindavad äärmiselt madalaid keskmisi viivitusi, mis kontrasteeruvad segakoormuse tulemustega (95% lugemist ja 5% kirjutamist), nagu on eespool kirjeldatud.

Skaleerimine?

Cloud Spanneri sõlmede arvu suurendamine ja vähendamine on ühe nupuvajutusega toiming. Kui soovite kiiresti andmeid laadida, võite kaaluda instantsi jõudluse tõstmist maksimaalseks (meie puhul oli see 25 sõlme US-EAST regioonis), ja seejärel vähendada sõlmede arvu, mis sobib teie tavaliseks koormuseks, pärast seda, kui kõik andmed on andmebaasis, pidada meeles 2 TB/sõlm piiri.

See piir tuli meelde isegi märksa väiksema andmebaasi korral. Pärast mitmeid koormustestide läbiviimisi oli meie andmebaasi suurus umbes 155 GB ja ühe sõlmega instantsi vähendamisel saime järgmise vea:

Meil õnnestus vähendada skaleerimist 25st 2 instantsini, kuid jäime kahe sõlme külge kinni.

Cloud Spanner klastris sõlmede arvu suurenemist ja vähenemist saab automatiseerida REST API abil. See võib olla eriti kasulik süsteemi koormuse vähendamiseks tipptundidel.

OLAP päringute jõudlus?

Alguses plaanisime pöörata sellele osale meie Spanneri hindamisest märkimisväärselt aega. Pärast mitmeid SELECT COUNT päringuid saime kohe aru, et testimine jääb lühikeseks ja Spanner ei sobi OLAP mootoriks. Ükskõik kui palju sõlmi klastris on, võttis 10M rida tabelist lihtsalt ridade arvu valimine aega 55 kuni 60 sekundit. Lisaks lõppes iga päring, mis vajas suuremat mälu vahepealsete tulemuste hoidmiseks, OOM veaga.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M unikaalset väärtust) -> SpoolingHashAggregateIterator jooksis välja mälu uue rea töötlemisel.

Mõningaid numbreid TPC-H päringute kohta saab leida Todd Lipkoni artiklist Nosql-kudu-spanner-slides.html, slaididel 42 ja 43. Need numbrid vastavad meie enda tulemustele (kahjuks).

4. Meie järeldused

Arvestades Cloud Spanneri hetkeseisu, on raske ette kujutada selle lihtsat asendamist olemasoleva OLTP lahendusega, eriti kui teie vajadused kasvavad sellest üle. Tuleks kulutada märkimisväärselt aega lahenduse ehitamiseks, arvestades Cloud Spanneri puudusi.

Kui me alustasime Cloud Spanneri hindamist, ootasime, et selle haldusfunktsioonid on samal tasemel või vähemalt mitte liiga kaugel teiste Google SQL lahenduste omadest. Kuid olime üllatunud, et varukoopiad puudusid täielikult ja juurdepääsu ressursidele kontroll oli äärmiselt piiratud. Rääkimata vaadete puudumisest, kohaliku arenduskeskkonna puudumisest, toetamata järjestustest, JDBC-st DML ja DDL toeta jne.

Nii et kuhu minna, kui on vaja skaleerida tehingute andmebaasi? Paistab, et turul ei ole veel ühtset lahendust, mis sobiks kõigi kasutusvariantidega. On olemas mitmeid suletud ja avatud lähtekoodiga lahendusi (mõned neist on selles artiklis mainitud), igaühel on oma tugevused ja nõrkused, kuid ükski neist ei paku SaaS-i SLA-ga 99,999% ja kõrge järjepidevusega. Kui kõrge SLA on teie peamine eesmärk ja te ei soovi luua oma lahendust mitmete pilvekeskkondade jaoks, võib Cloud Spanner olla just see lahendus, mida otsite. Kuid peate teadma selle kõiki piiranguid.

Õigluse nimel tuleks märkida, et Cloud Spanner lasti üldkasutusse alles 2017. aasta kevadel, seega on mõistlik oodata, et mõned selle praegused puudused võivad lõpuks kaduda (loodetavasti), ja kui see juhtub, võib see mängu muuta. Lõppude lõpuks ei ole Cloud Spanner lihtsalt Google'i külalisprojekt. Google kasutab seda oma teiste Google'i toodete aluseks. Ja kui Google asendas hiljuti Megastore'i Google Cloud Storage'is Cloud Spanneriga, muudab see Google Cloud Storage'i rangelt järjepidevaks objektide nimekirjade osas maailmas (mis siiski ei kehti Amazon’s S3).

Nii et lootus on veel olemas… loodame.

Sellega on kõik. Nagu artikli autor, jätkame meiegi lootmist, aga mida teie arvate? Kirjutage kommentaaridesse

Kutsume kõiki huvilisi külastama meie which is taking place today at 20:00. During the webinar, we will discuss how to build an efficient and scalable data processing system for a small company or startup with minimal costs. As a part of the practice, we will get to know Google Cloud data processing tools. See you there! , kus räägime kursusest üksikasjalikult „AWS arendajatele“ OTUS-e poolt.

Allikas: habr.com