Hallo, Khabrovites. Tradysjoneel bliuwe wy ynteressant materiaal te dielen oan 'e foarjûn fan it begjin fan nije kursussen. Hjoed, spesjaal foar jo, hawwe wy in artikel oerset oer Google Cloud Spanner, timed om gear te fallen mei de lansearring fan 'e kursus .
Oarspronklik publisearre yn .
As in bedriuw dat in ferskaat oan cloud-basearre POS-oplossingen biedt foar retailers, restaurateurs en online keaplju oer de hiele wrâld, brûkt Lightspeed ferskate ferskillende soarten databankplatfoarms foar in ferskaat oan transaksje-, analytyk- en sykgebrûkgefallen. Elk fan dizze databankplatfoarms hat syn eigen sterke en swakke punten. Dêrom, doe't Google Cloud Spanner op 'e merk yntrodusearre - belofte funksjes dy't net sjoen wurde yn' e wrâld fan relasjonele databases, lykas praktysk ûnbeheinde horizontale skalberens en in 99,999% tsjinstnivo-oerienkomst (SLA) , Wy koenen de kâns net misse om har yn ús hannen te hawwen!
Om in wiidweidich oersjoch te jaan fan ús ûnderfining mei Cloud Spanner, lykas de evaluaasjekritearia dy't wy hawwe brûkt, sille wy de folgjende ûnderwerpen dekke:
- Us evaluaasjekritearia
- Cloud Spanner yn in notedop
- Us beoardieling
- Us fynsten
1. Us evaluaasjekritearia
Foardat wy dûke yn 'e spesifikaasjes fan Cloud Spanner, syn oerienkomsten en ferskillen mei oare oplossingen op' e merke, litte wy earst prate oer de wichtichste gebrûksgefallen dy't wy yn gedachten hienen by it beskôgjen fan wêr't Cloud Spanner yn ús ynfrastruktuer moat ynset wurde:
- As ferfanging foar de (hearskende) tradisjonele SQL-database-oplossing
- As in OLAP-ynskeakele OLTP-oplossing
Tink derom: Foar gemak fan fergeliking fergeliket dit artikel Cloud Spanner mei de MySQL-farianten fan 'e GCP Cloud SQL en Amazon AWS RDS-oplossingsfamyljes.
Cloud Spanner brûke as ferfanging foar in tradysjonele SQL-databaseoplossing
Yn it miljeu tradisjoneel databases, doe't de antwurd tiid foar in databank query benaderjen liedt of sels boppe foarôf definiearre applikaasje drompels (foaral troch in tanimming fan it oantal brûkers en / of fersiken), der binne ferskate manieren om te ferminderjen de reaksje tiid oan akseptabel nivo. De measte fan dizze oplossingen befetsje lykwols hânmjittige yntervinsje.
Bygelyks, de earste stap om te nimmen is om te sjen nei de ferskate prestaasje-relatearre databankynstellingen en ôfstimme se om it bêste te passen tapassing-gebrûk-senario-patroanen. As dit net genôch is, kinne jo kieze om de databank fertikaal of horizontaal te skaaljen.
Skaalfergrutting fan in applikaasje hâldt in bywurkjen fan de servereksimplaar, typysk troch it tafoegjen fan mear processors/kearnen, mear RAM, flugger opslach, ensfh. Relasjonele databasesystemen (dy't in multi-threaded oanpak brûke) lykas MySQL-skaal goed fertikaal.
D'r binne ferskate neidielen oan dizze oanpak, mar it meast foar de hân lizzende is de maksimale servergrutte op 'e merke. Sadree't de grutste Server Instance limyt is berikt, is der mar ien paad oer: skaal út.
Skaalfergrutting is in oanpak dy't mear servers tafoegje oan in kluster om ideaal de prestaasjes lineêr te ferheegjen as mear servers wurde tafoege. Mearderheid tradisjoneel databanksystemen skaalje net goed of skaalje hielendal net. MySQL kin bygelyks útskaalje foar lêzings troch slavelêzers ta te foegjen, mar it kin net útskaalje foar skriuwen.
Oan 'e oare kant, troch syn aard, kin Cloud Spanner maklik horizontaal skaalje mei minimale yntervinsje.
Folsleine featured DBMS as in tsjinst moat wurde evaluearre út ferskate perspektiven. As basis namen wy de populêrste DBMS yn 'e wolk - foar Google, GCP Cloud SQL en foar Amazon, AWS RDS. Yn ús evaluaasje hawwe wy rjochte op de folgjende kategoryen:
- Feature mapping: SQL omfang, DDL, DML; ferbining biblioteken / Anschlüsse, transaksje stipe, ensafuorthinne.
- Untwikkelingsstipe: Gemak fan ûntwikkeling en testen.
- Bestjoersstipe: eksimplaarbehear lykas skaalfergrutting / del en opwurdearjen fan eksimplaren; SLA, reservekopy en herstel; feiligens / tagong kontrôle.
Cloud Spanner brûke as in OLAP-ynskeakele OLTP-oplossing
Wylst Google net eksplisyt stelt dat Cloud Spanner foar analytics is, dielt it wat attributen mei oare motoren lykas Apache Impala & Kudu en YugaByte dy't binne ûntworpen foar OLAP-wurkloads.
Sels as d'r mar in lytse kâns wie dat Cloud Spanner in konsekwint skaalfergrutting HTAP (Hybrid Transactional / Analytic Processing)-motor mei in (min of mear) brûkbere OLAP-funksje set, tinke wy dat it ús oandacht soe fertsjinje.
Mei dat yn gedachten seagen wy nei de folgjende kategoryen:
- Gegevens laden, yndeksen en partitioning stipe
- Query prestaasjes en DML
2. Wolk Spanner yn in Nutshell
Google Spanner is in clustered relational database management system (RDBMS) dat Google brûkt foar ferskate fan har eigen tsjinsten. Google makke it begjin 2017 iepenbier beskikber foar brûkers fan Google Cloud Platform.
Hjir binne guon fan 'e Cloud Spanner-attributen:
- Heech konsekwint, skalberber RDBMS-kluster: brûkt hardware-tiidsyngronisaasje om gegevenskonsistinsje te garandearjen.
- Transaksjestipe foar cross-tabel: Transaksjes kinne meardere tabellen omfetsje - net needsaaklik beheind ta ien tabel (oars as Apache HBase of Apache Kudu).
- Primêre Key Based Tables: Alle tabellen moatte hawwe in ferklearre primêre kaai (PC), dat kin bestean út meardere tabel kolommen. Tabulêre gegevens wurde opslein yn PC folchoarder, dat makket it hiel effisjint en fluch foar PC sykopdrachten. Lykas by oare PC-basearre systemen, moat de ymplemintaasje wurde modeleare tsjin foaropstelde gebrûksgefallen om te berikken .
- Striped tabellen: Tabellen kinne hawwe fysike ôfhinklikens fan elkoar. De rigen fan 'e berntabel kinne oerienkomme mei de rigen fan' e âldertabel. Dizze oanpak fersnelt it sykjen nei relaasjes dy't kinne wurde bepaald yn 'e gegevensmodelleringsstadium, bygelyks by it pleatsen fan klanten en har faktueren.
- Yndeksen: Cloud Spanner stipet sekundêre yndeksen. In yndeks bestiet út yndeksearre kolommen en alle PC-kolommen. Opsjoneel kin de yndeks ek oare net-yndekse kolommen befetsje. De yndeks kin ynterleave wurde mei de âldertabel om queries te fersnellen. Ferskate beheinings jilde foar yndeksen, lykas it maksimum oantal ekstra kolommen dat kin wurde opslein yn in yndeks. Ek kinne fragen fia yndeksen net sa ienfâldich wêze as yn oare RDBMS.
"Cloud Spanner selekteart in yndeks automatysk allinich yn seldsume gefallen. Yn it bysûnder, Cloud Spanner selekteart net automatysk in sekundêre yndeks as de query alle kolommen freget dy't net binne opslein yn ".
- Service Level Agreement (SLA): Single regio ynset mei 99,99% SLA; multi-regio ynset mei 99,999% SLA. Wylst de SLA sels gewoan in oerienkomst is en gjin garânsje fan hokker soart, leau ik dat Google-minsken wat hurde gegevens hawwe om sa'n sterke claim te meitsjen. (Foar referinsje betsjut 99,999% 26,3 sekonden tsjinstferliening per moanne.)
- Mear:
Tink derom: It Apache Tephra-projekt foeget avansearre transaksjestipe ta oan Apache HBase (ek no ymplementearre yn Apache Phoenix as beta).
3. Us evaluaasje
Dat, wy hawwe allegear de útspraken fan Google lêzen oer de foardielen fan Cloud Spanner - praktysk ûnbeheinde horizontale skaalfergrutting mei it behâld fan hege konsistinsje en in heul hege SLA. Hoewol dizze oanspraken yn alle gefallen ekstreem lestich te berikken binne, wie ús doel net om se te wjerlizzen. Litte wy ynstee rjochtsje op oare dingen wêr't de measte database-brûkers om soarchje: pariteit en brûkberens.
Wy beoardiele Cloud Spanner as ferfanging foar Sharded MySQL
Google Cloud SQL en Amazon AWS RDS, twa fan 'e populêrste OLTP-databases yn' e wolkmerk, hawwe in heul grutte funksjeset. Om dizze databases lykwols te skaaljen boppe de grutte fan in inkele knooppunt, moatte jo applikaasje-splitsing útfiere. Dizze oanpak soarget foar ekstra kompleksiteit foar sawol applikaasjes as administraasje. Wy seagen hoe't Spanner past yn it senario fan it kombinearjen fan meardere shards yn ien eksimplaar en hokker funksjes (as ien) miskien moatte wurde opoffere.
Stipe foar SQL, DML en DDL, lykas de ferbining en bibleteken?
Earst, as jo begjinne mei elke databank, moatte jo in gegevensmodel oanmeitsje. As jo tinke dat jo kinne ferbine JDBC Spanner oan jo favorite SQL ark, do silst fine dat jo kinne query jo gegevens mei it, mar do kinst net brûke it foar in meitsje in tabel of update (DDL) of in ynfoegje/bywurkje/wiskje operaasjes (DML). Google's offisjele JDBC stipet ek net.
"Bestjoerders stypje op it stuit gjin DML- of DDL-útspraken."
Spanner dokumintaasje
De situaasje is net better mei de GCP-konsole - jo kinne allinich SELECT-fragen stjoere. Gelokkich is d'r in JDBC-bestjoerder mei DML- en DDL-stipe fan 'e mienskip, ynklusyf transaksjes . Hoewol dizze bestjoerder ekstreem nuttich is, is it ûntbrekken fan Google's eigen JDBC-bestjoerder ferrassend. Gelokkich biedt Google frij brede stipe foar kliïntbibleteek (basearre op gRPC): C#, Go, Java, node.js, PHP, Python en Ruby.
It hast ferplichte gebrûk fan Cloud Spanner's oanpaste API's (fanwege it ûntbrekken fan DDL en DML yn JDBC) resultearret yn guon beheiningen foar besibbe gebieten fan koade, lykas ferbining pooling of database-binende kaders (lykas Spring MVC). Yn 't algemien, as jo JDBC brûke, binne jo frij om jo favorite ferbiningspool te kiezen (bgl. HikariCP, DBCP, C3PO, ensfh.) Dat wurdt hifke en goed wurket. Yn it gefal fan oanpaste Spanner API's moatte wy fertrouwe op kaders / binende / sesjepools dy't wy sels hawwe makke.
It primêre kaai (PC) oriïntearre ûntwerp lit Cloud Spanner heul rap wêze as jo tagong krije ta gegevens fia de PC, mar yntroduseart ek wat queryproblemen.
- Jo kinne de wearde fan in primêre kaai net bywurkje; Jo moatte earst de orizjinele PC-yngong wiskje en it opnij ynfoegje mei de nije wearde. (Dit is fergelykber mei oare PC-rjochte databank-/opslachmotoren.)
- Elke UPDATE- en DELETE-útspraken moatte de PC spesifisearje yn 'e WHERE, dus kin d'r net leech wêze DELETE alle útspraken - d'r moat altyd in subquery wêze, bygelyks: UPDATE xxx WHERE id IN (SELECT id FROM tabel1)
- Gebrek oan in auto-increment opsje of wat ferlykber dat stelt de folchoarder foar it PC fjild. Om dit te wurkjen, moat de oerienkommende wearde oanmakke wurde oan 'e applikaasjekant.
Sekundêre yndeksen?
Google Cloud Spanner hat ynboude stipe foar sekundêre yndeksen. Dit is in heul leuke funksje dy't net altyd oanwêzich is yn oare technologyen. Apache Kudu stipet op it stuit gjin sekundêre yndeksen, en Apache HBase stipet gjin yndeksen direkt, mar kin se tafoegje fia Apache Phoenix.
Yndeksen yn Kudu en HBase kinne wurde modeleare as in aparte tabel mei ferskate komposysje fan primêre kaaien, mar de atomiteit fan 'e operaasjes útfierd op' e âldertabel en relatearre yndekstabellen moatte wurde útfierd op it tapassingsnivo en is net triviaal om korrekt te ymplementearjen.
Lykas neamd yn 'e Cloud Spanner-resinsje, kinne har yndeksen ferskille fan MySQL-yndeksen. Sa moat spesjale soarch nommen wurde by it opbouwen en profilearjen fan query's om te soargjen dat de juste yndeks brûkt wurdt wêr't it nedich is.
Fertsjintwurdiging?
In heul populêr en brûkber objekt yn in databank is werjeften. Se kinne brûkber wêze foar in grut oantal gebrûk gefallen; myn twa favoriten binne de logyske abstraksjelaach en de feiligenslaach. Spitigernôch stipet Cloud Spanner NET werjeften. Dit beheint ús lykwols mar foar in part, om't d'r gjin granulariteit op kolomnivo is foar tagongsrjochten wêr't werjeften in akseptabele oplossing kinne wêze.
Sjoch de Cloud Spanner-dokumintaasje foar in seksje mei detaillearre kwota's en grinzen (), der is ien yn it bysûnder dat kin wêze problematysk foar guon applikaasjes: Cloud Spanner út it fak hat in maksimum fan 100 databases per eksimplaar. Fansels kin dit in grutte hindernis wêze foar in database dy't is ûntworpen om te skaaljen nei mear dan 100 databases. Gelokkich, nei it praten mei ús technyske fertsjintwurdiger fan Google, fûnen wy út dat dizze limyt kin wurde ferhege nei hast elke wearde fia Google Support.
Untwikkelingsstipe?
Cloud Spanner biedt aardich fatsoenlike stipe foar programmeartaal foar wurkjen mei har API. De offisjeel stipe bibleteken binne op it mêd fan C#, Go, Java, node.js, PHP, Python en Ruby. De dokumintaasje is frij detaillearre, mar lykas by oare moderne technologyen is de mienskip frij lyts yn ferliking mei de meast populêre databanktechnologyen, wat kin resultearje yn mear tiid bestege oan minder gewoane gebrûksgefallen of problemen.
Dus wat oer stipe foar lokale ûntwikkeling?
Wy hawwe gjin manier fûn om in Cloud Spanner-eksimplaar on-premises te meitsjen. It tichtste dat wy krigen is in Docker-ôfbylding dy't yn prinsipe fergelykber is, mar yn 'e praktyk hiel oars. Bygelyks, CockroachDB kin PostgreSQL JDBC brûke. Sûnt de ûntwikkeling omjouwing moat wêze sa ticht mooglik by de produksje omjouwing, Cloud Spanner is net ideaal omdat jo moatte fertrouwe op in folsleine Spanner eksimplaar. Om kosten te besparjen, kinne jo in inkele regio-eksimplaar selektearje.
Administraasje stipe?
It meitsjen fan in Cloud Spanner-eksimplaar is heul ienfâldich. Jo moatte gewoan kieze tusken it meitsjen fan in multi-regio of in ien-regio eksimplaar, spesifisearje de regio (s) en it oantal knopen. Yn minder dan in minút sil de eksimplaar opnij wêze.
Ferskate elemintêre metriken binne direkt beskikber op 'e Spanner-side yn' e Google Konsole. Mear detaillearre werjeften binne beskikber fia Stackdriver, wêr't jo ek metrike drompels en warskôgingsbelied kinne ynstelle.
Tagong ta middels?
MySQL biedt wiidweidige en heul granulêre tastimming / rolynstellingen fan brûkers. Jo kinne maklik oanpasse tagong ta in spesifike tabel, of sels mar in subset fan syn kolommen. Cloud Spanner brûkt it Google Identity & Access Management (IAM) ark, wêrtroch jo allinich belied en tagongsrjochten op in heul heech nivo kinne ynstelle. De meast korrelige opsje is tastimming op databanknivo, dy't net past yn 'e measte produksjegefallen. Dizze beheining twingt jo om ekstra befeiligingsmaatregels ta te foegjen oan jo koade, ynfrastruktuer, of beide om ûnautorisearre gebrûk fan Spanner-boarnen te foarkommen.
Reservekopyen?
Om it gewoan te sizzen, binne d'r gjin backups yn Cloud Spanner. Wylst Google's hege SLA-easken kinne soargje dat jo gjin gegevens ferlieze troch hardware- of databankfout, minsklike flater, applikaasjedefekten, ensfh.. Wy witte allegear de regel: hege beskikberens is gjin ferfanging foar in tûke backupstrategy. Op it stuit is de ienige manier om gegevens te bewarjen is it programmatysk te streamen fan 'e databank nei in aparte opslachomjouwing.
Query prestaasjes?
Wy brûkten Yahoo! om gegevens te laden en fragen te testen. Cloud Serving Benchmark. De tabel hjirûnder lit de B YCSB wurkdruk sjen mei in 95% lêzen oant 5% skriuwferhâlding.
* De loadtest waard útfierd op n1-standert-32 Compute Engine (CE) (32 vCPU's, 120 GB ûnthâld) en de testeksimplaar wie nea de knelpunt yn 'e testen.
** It maksimum oantal triedden yn ien YCSB-eksimplaar is 400. Yn totaal moasten seis parallelle eksimplaren fan YCSB-tests útfierd wurde om in totaal fan 2400 triedden te krijen.
Sjoch nei de benchmark-resultaten, yn it bysûnder de kombinaasje fan CPU-lading en TPS, kinne wy dúdlik sjen dat Cloud Spanner frij goed skaleart. De grutte lading makke troch in grut oantal triedden wurdt kompensearre troch in grut oantal knopen yn it Cloud Spanner-kluster. Hoewol't de latency der frij heech útsjocht, foaral as jo rinne op 2400 threads, kin it nedich wêze om opnij te testen mei 6 lytsere eksimplaren fan 'e komputermotor om krekter nûmers te krijen. Elke eksimplaar sil ien YCSB-test útfiere ynstee fan ien grutte CE-eksimplaar mei 6 parallelle tests. Dit makket it makliker om te ûnderskieden tusken Cloud Spanner-fersykfertragingen en fertragingen tafoege troch de netwurkferbining tusken Cloud Spanner en de CE-eksimplaar dy't de test útfiert.
Hoe docht Cloud Spanner as OLAP?
Partitionearje?
It dielen fan gegevens yn fysyk en / of logysk ûnôfhinklike segminten, partysjes neamd, is in heul populêr konsept dat fûn wurdt yn 'e measte OLAP-motoren. Partitionen kinne query-prestaasjes en ûnderhâldberens fan databases sterk ferbetterje. Fierder ferdjipje yn partitionering soe in aparte artikel(en) wêze, dus litte wy gewoan it belang neame fan it hawwen fan in partitioneringsskema en sub-partitionearring. De mooglikheid om gegevens te splitsen yn partysjes en noch fierder yn subpartysjes is de kaai foar de prestaasjes fan analytyske queries.
Cloud Spanner stipet gjin partysjes per se. It skiedt gegevens yntern yn saneamde spjalte-s basearre op primêre kaai berik. De partitioning wurdt automatysk dien om de lading op it Cloud Spanner-kluster te balansearjen. In hiel handich skaaimerk fan Cloud Spanner is it splitsen fan de basis lading fan in âlder tafel (in tabel dy't net interleaved mei in oar). Spanner detektearret automatysk as it befettet spjalte gegevens dy't faker lêzen wurde as gegevens yn oare spjalte-ah, en kin beslute op in fierdere skieding. Sa kinne mear knopen wurde belutsen by in fersyk, dy't ek effektyf fergruttet de trochslach.
Gegevens laden?
De Cloud Spanner-metoade foar bulkgegevens is itselde as foar in gewoane upload. Foar maksimale prestaasjes moatte jo guon rjochtlinen folgje, ynklusyf:
- Sortearje jo gegevens op primêre kaai.
- Diel se troch 10*oantal knopen yndividuele seksjes.
- Meitsje in set fan wurknimmerstaken dy't gegevens parallel lade.
Dizze gegevenslading brûkt alle Cloud Spanner-knooppunten.
Wy brûkten de A YCSB wurkdruk om in 10M rige dataset te generearjen.
* De loadtest waard útfierd op 'e n1-standert-32 komputermotor (32 vCPU's, 120 GB ûnthâld) en de testeksimplaar wie nea de knelpunt yn 'e tests.
** In opset fan 1 knooppunten wurdt net oanrikkemandearre foar elke produksjewurkdruk.
Lykas hjirboppe neamd, ferwurket Cloud Spanner automatysk splits ôfhinklik fan har lading, sadat de resultaten ferbetterje nei ferskate opienfolgjende iteraasjes fan 'e test. De hjir presintearre resultaten binne de bêste resultaten dy't wy hawwe krigen. As wy nei de boppesteande sifers sjogge, kinne wy sjen hoe't Cloud Spanner skalen (goed) as it oantal knooppunten yn it kluster nimt ta. De nûmers dy't opfalle binne ekstreem lege gemiddelde latency, dy't kontrastearret mei resultaten fan mingde wurklêsten (95% lêzen en 5% skriuwe) lykas beskreaun yn 'e seksje hjirboppe.
Skaalfergrutting?
It fergrutsjen en ferminderjen fan it oantal Cloud Spanner-knooppunten is in taak mei ien klik. As jo gegevens fluch wolle laden, wolle jo miskien beskôgje om it eksimplaar oant it maksimum te stimulearjen (yn ús gefal wiene it 25 knooppunten yn 'e US-EAST-regio) en ferminderje dan it oantal knooppunten geskikt foar jo normale lading nei alle gegevens yn 'e databank, mei de limyt fan 2 TB / node yn gedachten.
Wy waarden herinnere oan dizze limyt sels mei in folle lytsere databank. Nei ferskate loadtestruns wie ús databank sawat 155 GB yn grutte, en doe't omleech nei in eksimplaar fan 1 knooppunt, krigen wy de folgjende flater:
Wy koenen skaalje fan 25 nei 2 eksimplaren, mar wy sitte fêst op twa knopen.
It ferheegjen en ferleegjen fan it oantal knooppunten yn in Cloud Spanner-kluster kin automatisearre wurde mei de REST API. Dit kin benammen nuttich wêze foar it ferminderjen fan de ferhege lêst op it systeem yn drokke oeren.
OLAP query prestaasjes?
Wy wiene oarspronklik pland om in protte tiid te besteegjen oan ús evaluaasje fan Spanner op dit diel. Nei in pear SELECT COUNTs, wy realisearre fuortendaliks dat de test soe wêze koart en dat Spanner soe NET in geskikte motor foar OLAP. Nettsjinsteande it oantal knopen yn it kluster, gewoan kieze it oantal rigen yn in 10M rige tabel naam 55 oan 60 sekonden. Ek mislearre elke fraach dy't mear ûnthâld nedich hie om tuskenresultaten op te slaan mei in OOM-flater.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Guon nûmers foar TPC-H-fragen kinne fûn wurde yn it artikel fan Todd Lipcon , dia's 42 en 43. Dizze sifers binne yn oerienstimming mei ús eigen resultaten (spitigernôch).
4. Us befinings
Sjoen de hjoeddeistige steat fan 'e funksjes fan Cloud Spanner, is it lestich om it te sjen as in ienfâldige ferfanging foar in besteande OLTP-oplossing, foaral as jo behoeften it groeie. It soe in wichtige hoemannichte tiid nimme om in oplossing te bouwen om de tekoarten fan Cloud Spanner hinne.
Doe't wy begûnen te evaluearjen fan Cloud Spanner, ferwachten wy dat syn behearfunksjes op gelyk wiene mei, of op syn minst net fier fan, oare Google SQL-oplossingen. Mar wy wiene ferrast troch it folsleine gebrek oan backups en heul beheinde tagongskontrôle foar boarnen. Net te hawwen oer gjin werjeften, gjin lokale ûntwikkelingsomjouwing, net-stipe sekwinsjes, JDBC sûnder DML- en DDL-stipe, ensfh.
Dus, wêr te gean foar ien dy't in transaksjedatabase moat skaalje? D'r liket noch gjin inkele oplossing op 'e merke te wêzen dy't past by alle gebrûksgefallen. D'r binne in protte sletten en iepen boarne-oplossingen (guon dêrfan wurde neamd yn dit artikel), elk mei har eigen sterke en swakke punten, mar gjinien fan har biedt SaaS mei in 99,999% SLA en in hege graad fan konsistinsje. As in hege SLA jo primêre doel is en jo binne net oanstriid om jo eigen oplossing foar meardere wolken te bouwen, kin Cloud Spanner de oplossing wêze wêr't jo nei sykje. Mar jo moatte bewust wêze fan al syn beheiningen.
Om earlik te wêzen, waard Cloud Spanner allinich frijlitten oan it publyk yn 'e maitiid fan 2017, dus it is ridlik te ferwachtsjen dat guon fan har hjoeddeistige gebreken úteinlik kinne ferdwine (hooplik), en as it docht, kin it in spultsje-wikseler wêze. Ommers, Cloud Spanner is net allinich in sydprojekt foar Google. Google brûkt it as basis foar oare Google-produkten. En doe't Google koartlyn Megastore yn Google Cloud Storage ferfong mei Cloud Spanner, liet it Google Cloud Storage heul konsekwint wurde foar objektlisten op wrâldwide skaal (wat noch altyd net it gefal is foar ).
Dus, der is noch hoop ... wy hoopje.
Da's alles. Lykas de skriuwer fan it artikel bliuwe wy ek hoopje, mar wat fine jo hjirfan? Skriuw yn 'e kommentaren
Wy noegje elkenien út om ús te besykjen wêryn wy sille fertelle jo yn detail oer de kursus fan OTUS.
Boarne: www.habr.com