Hej, Habr-anvÀndare. Traditionellt fortsÀtter vi att dela intressant material inför starten av nya kurser. Idag har vi sÀrskilt översatt en artikel om Google Cloud Spanner, i samband med lanseringen av kursen. .
Ursprungligen publicerad i .
Som ett företag som erbjuder mĂ„nga molnbaserade POS-lösningar för detaljhandlare, restauranger och onlinehandlare över hela vĂ€rlden, anvĂ€nder Lightspeed flera olika typer av databaser för olika transaktions-, analytiska och sökfall. Varje databasplattform har sina egna styrkor och svagheter. NĂ€r Google dĂ€rför introducerade Cloud Spanner pĂ„ marknaden â med lovande funktioner som aldrig tidigare skĂ„dade inom relationsdatabaser, sĂ„som praktiskt taget obegrĂ€nsad horisontell skalbarhet och 99,999% servicenivĂ„avtal (SLA) â kunde vi inte missa chansen att fĂ„ den i vĂ„ra hĂ€nder!
För att ge en uttömmande översikt över vÄra erfarenheter med Cloud Spanner samt de bedömningskriterier vi anvÀnde, kommer vi att behandla följande Àmnen:
- VÄra bedömningskriterier
- Cloud Spanner i korthet
- VÄr bedömning
- VĂ„ra slutsatser
1. VÄra bedömningskriterier
Innan vi gÄr in pÄ egenskaperna hos Cloud Spanner, dess likheter och skillnader med andra lösningar pÄ marknaden, lÄt oss först diskutera de huvudsakliga anvÀndningsfallen som vi beaktade nÀr vi övervÀgde var Cloud Spanner skulle implementeras i vÄr infrastruktur:
- Som en ersÀttning för det dominerande traditionella SQL-databassystemet
- Som en OLTP-lösning med stöd för OLAP
AnmÀrkning: För att förenkla och jÀmföra, jÀmför denna artikel Cloud Spanner med MySQL-alternativen i GCP Cloud SQL och Amazon AWS RDS-familjerna.
AnvÀndning av Cloud Spanner som ersÀttning för traditionella SQL-databassystem
I en miljö av traditionella databaser, nÀr svarstiden för databasfrÄgor nÀrmar sig eller till och med överstiger fördefinierade tröskelvÀrden för applikationen (oftast pÄ grund av ökat antal anvÀndare och/eller frÄgor), finns det flera sÀtt att sÀnka svarstiden till acceptabla nivÄer. Men de flesta av dessa lösningar involverar manuell inblandning.
Till exempel, det första steget att ta Àr att titta pÄ de olika databasparametrarna relaterade till prestanda och justera dem för att bÀst matcha anvÀndningsmönstren för applikationerna. Om detta visar sig vara otillrÀckligt kan man vÀlja att skala databasen vertikalt eller horisontellt.
Vertikal skalning av applikationen innebÀr att man uppgraderar serverinstansen, vanligtvis genom att lÀgga till fler processorer/kÀrnor, mer RAM, snabbare lagring osv. Att lÀgga till fler hÄrdvaruresurser ledar till ökad databaspresentation, mÀtt i stort sett i transaktioner per sekund och transaktionsfördröjning för OLTP-system. Relationsdatabassystem (som anvÀnder en flertrÄdad metod) som MySQL kan skalas bra vertikalt.
Denna metod har flera nackdelar, men den mest uppenbara Àr den maximala serverstorleken pÄ marknaden. NÀr grÀnsen för den största serverinstansen har uppnÄtts finns det bara en vÀg kvar: horisontell skalning.
Horisontell skalning Àr en metod dÀr fler servrar lÀggs till klustret för att i idealfallet linjÀrt öka prestanda med en ökning av antalet servrar. De flesta av traditionella databassystem Àr förstörd för horisontell skalning eller kan överhuvudtaget inte skalas. Till exempel kan MySQL horisontellt skalas för lÀsoperationer genom att lÀgga till slave-lÀsare, men kan inte horisontellt skalas för skrivoperationer.
Ă andra sidan kan Cloud Spanner tack vare sin natur enkelt skalas horisontellt med minimal inblandning.
FullfjĂ€drad DBMS som en tjĂ€nst bör utvĂ€rderas frĂ„n olika perspektiv. Som grund har vi tagit den mest populĂ€ra databasen i molnet â för Google, GCP Cloud SQL och för Amazon, AWS RDS. I vĂ„r utvĂ€rdering har vi fokuserat pĂ„ följande kategorier:
- Funktionalitet: SQL-utvidgningar, DDL, DML; anslutningsbibliotek/anslutare, transaktionsstöd osv.
- Stöd för utveckling: enkelhet i utveckling och testning.
- Administration support: instance management â for example, scaling up/down and upgrading instances; SLA, backup and recovery; security/access control.
Using Cloud Spanner as an OLTP solution with OLAP support
Although Google does not explicitly claim that Cloud Spanner is intended for analytics processing, it shares some attributes with other mechanisms, such as Apache Impala & Kudu and YugaByte, that are designed for OLAP workloads.
Even if there was only a small chance that Cloud Spanner included a horizontally scalable HTAP (hybrid transactional/analytical processing) engine with a (more or less) usable set of OLAP features, we believe it would deserve our attention.
With this in mind, we considered the following categories:
- Data loading, indexing, and partitioning support
- Query performance and DML
2. Cloud Spanner in brief
Google Spanner is a clustered relational database management system (RDBMS) used by Google for several of its own services. Google made it publicly available to Google Cloud Platform users in early 2017.
Here are some of the attributes of Cloud Spanner:
- Strongly consistent scalable cluster RDBMS: uses hardware time synchronization to ensure data consistency.
- Support for cross-table transactions: transactions can span multiple tables â not necessarily limited to a single table (unlike Apache HBase or Apache Kudu).
- Primary key-based tables: all tables must have a declared primary key (PK), which can consist of multiple columns of the table. Tabular data is stored in PK order, making it very efficient and fast for lookups by PK. Like other PK-based systems, the implementation must be modeled with an eye toward well-thought-out use cases for achieving .
- Alternativa tabeller: tabeller kan ha fysiska beroenden av varandra. Rader i en underordnad tabell kan kopplas samman med rader i en överordnad tabell. Denna metod snabbar upp sökningen efter förhÄllanden som kan bestÀmmas under datamodelleringssteget, till exempel vid gemensam placering av kunder och deras fakturor.
- Index: Cloud Spanner stöder sekundÀra index. Ett index bestÄr av indexerade kolumner och alla kolumner i primÀrnyckeln. Om sÄ önskas kan indexet ocksÄ innehÄlla andra icke-indexerade kolumner. Indexet kan samverka med den överordnade tabellen för att pÄskynda förfrÄgningar. Det finns flera begrÀnsningar för index, till exempel det maximala antalet extra kolumner som lagras i indexet. FörfrÄgningar via index kan Àven vara mer komplicerade Àn i andra relationsdatabaser.
âCloud Spanner vĂ€ljer automatiskt index endast i sĂ€llsynta fall. I synnerhet vĂ€ljer Cloud Spanner inte automatiskt ett sekundĂ€rt index om förfrĂ„gan begĂ€r nĂ„gra kolumner som inte Ă€r lagrade i ».
- Service Level Agreement (SLA): distribution i en region med SLA pĂ„ 99,99%; flerdelade distributioner med 99,999% SLA. Ăven om sjĂ€lva avtalet om servicenivĂ„ bara Ă€r ett avtal och ingen garanti, tror jag att Googles anstĂ€llda har nĂ„got exakt data som gör det möjligt att göra ett sĂ„ allvarligt pĂ„stĂ„ende. (För referens betyder 99,999% 26,3 sekunder av tjĂ€nstens otillgĂ€nglighet per mĂ„nad.)
- Mer:
AnmÀrkning: Apache Tephra-projektet lÀgger till utökat stöd för transaktioner i Apache HBase (som nu ocksÄ implementeras i Apache Phoenix i beta-version).
3. VÄr bedömning
SĂ„, vi har alla lĂ€st Googles pĂ„stĂ„enden om fördelarna med Cloud Spanner â praktiskt taget oĂ€ndlig horisontell skalning med bibehĂ„llen hög konsistens och mycket hög SLA. Ăven om dessa krav Ă€r extremt svĂ„ra att uppnĂ„, var vĂ„rt mĂ„l inte att motsĂ€ga dem. LĂ„t oss istĂ€llet fokusera pĂ„ andra saker som bekymrar de flesta databas-anvĂ€ndare: anvĂ€ndbarhet och lĂ€tthet.
Vi bedömde Cloud Spanner som en ersÀttning för Sharded MySQL
Google Cloud SQL och Amazon AWS RDS, tvÄ av de mest populÀra OLTP-databaserna pÄ marknaden för molntjÀnster, har en mycket omfattande uppsÀttning funktioner. För att dock skala dessa databaser bortom storleken pÄ en enda nod, mÄste du implementera applikationspartitionering. Denna strategi skapar ytterligare komplexitet bÄde för applikationerna och för administrationen. Vi har undersökt hur Spanner passar in i scenariot dÀr flera segment samlas i en instans och vilka funktioner (om nÄgra) som kanske mÄste offras.
Stöd för SQL, DML och DDL, samt anslutare och bibliotek?
Först och frÀmst, nÀr du arbetar med vilken databas som helst mÄste du skapa en datamodell. Om du tror att du kan koppla JDBC Spanner till ditt favorit SQL-verktyg, kommer du att mÀrka att du kan frÄga dina data med det, men du kan inte anvÀnda det för att skapa tabeller eller göra Àndringar (DDL) eller nÄgra insÀttnings-/uppdaterings-/raderingsoperationer (DML). Googles officiella JDBC stöder varken det ena eller det andra.
"För nÀrvarande stöder drivrutinerna inte DML- eller DDL-satser."
Spanner-dokumentation
Med GCP-konsolen Ă€r situationen inte heller bĂ€ttre â du kan endast skicka SELECT-frĂ„gor. Lyckligtvis finns det en JDBC-drivrutin med stöd för DML och DDL frĂ„n gemenskapen, inklusive transaktioner. . Ăven om denna drivrutin Ă€r oerhört anvĂ€ndbar, vĂ€cker avsaknaden av en egen JDBC-drivrutin frĂ„n Google förvĂ„ning. Lyckligtvis erbjuder Google ganska bra stöd för klientbibliotek (baserat pĂ„ gRPC): C#, Go, Java, node.js, PHP, Python och Ruby.
De nÀstan obligatoriska anvÀndningarna av anpassade API:er för Cloud Spanner (pÄ grund av bristen pÄ DDL och DML i JDBC) leder till vissa begrÀnsningar för relaterade kodomrÄden, sÄsom anslutningspooler eller databindningsramverk (till exempel Spring MVC). I allmÀnhet kan man vid anvÀndning av JDBC fritt vÀlja sin favoritanslutningspool (till exempel HikariCP, DBCP, C3PO osv.) som har testats och fungerar bra. För anpassade API:er i Spanner mÄste vi förlita oss pÄ de ramverk/pooler för bindning/Sessioner som vi har skapat sjÀlva.
PrimÀrnyckelsinriktad konstruktion gör att Cloud Spanner Àr mycket snabb vid databasÄtkomst via primÀrnyckeln, men leder ocksÄ till vissa problem med frÄgor.
- Du kan inte uppdatera vÀrdet av primÀrnyckeln; du mÄste först ta bort posten med den ursprungliga PK och infoga den igen med det nya vÀrdet. (Detta liknar andra PK-orienterade databaser/lagringsmekanismer.)
- Alla UPDATE- och DELETE-operatorer mĂ„ste ange PK i WHERE, dĂ€rför kan det inte finnas tomma DELETE all-operatorer â det mĂ„ste alltid finnas en underfrĂ„ga, till exempel: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Avsaknad av autoinkrement eller nÄgot liknande som anger sekvensen för PK-fÀltet. För att detta ska fungera mÄste det motsvarande vÀrdet skapas pÄ applikationens sida.
SekundÀra index?
Google Cloud Spanner har inbyggt stöd för sekundÀra index. Detta Àr en mycket trevlig funktion som inte alltid finns i andra teknologier. Apache Kudu stöder för nÀrvarande överhuvudtaget inte sekundÀra index, och Apache HBase stöder inte index direkt men kan lÀgga till dem via Apache Phoenix.
Index i Kudu och HBase kan modelleras som en separat tabell med olika sammansÀttningar av primÀrnycklar, men atomÀriteten för operationer som utförs med den primÀra tabellen och de relaterade index-tabellerna mÄste genomföras pÄ applikationsnivÄ och Àr inte trivial i en korrekt implementering.
Som nÀmnts i översikten av Cloud Spanner kan dess index skilja sig frÄn MySQL-index. DÀrför bör man vara sÀrskilt försiktig vid byggandet av frÄgor och profilering för att sÀkerstÀlla anvÀndningen av rÀtt index dÀr det Àr nödvÀndigt.
Vyern?
En mycket populÀr och anvÀndbar objekt i databasen Àr vyer. De kan vara anvÀndbara för en mÀngd olika anvÀndningsfall; tvÄ av mina favoriter Àr logisk abstraheringsnivÄ och sÀkerhetsnivÄ. TyvÀrr stödjer Cloud Spanner INTE vyer. Men detta begrÀnsar oss endast delvis, eftersom det inte finns nÄgon detaljering pÄ kolumnivÄ för ÄtkomstrÀttigheter dÀr vyer kan vara en acceptabel lösning.
I Cloud Spanners dokumentation finns det en sektion dÀr kvoter och begrÀnsningar beskrivs i detalj (), det finns, sÀrskilt, en som kan vara problematisk för vissa applikationer: Cloud Spanner har som standard en grÀns pÄ högst 100 databaser per instans. Det Àr uppenbart att detta kan bli ett allvarligt hinder för en databas som Àr avsedd att skalas över mer Àn 100 databaser. Som tur Àr, efter att ha pratat med vÄr tekniska representant pÄ Google, fick vi veta att denna grÀns kan ökas till praktiskt taget vilket vÀrde som helst via Googles support.
Stöd för utveckling?
Cloud Spanner erbjuder ganska bra stöd för programmeringssprÄk för att arbeta med sitt API. Officiellt stödda bibliotek finns inom C#, Go, Java, node.js, PHP, Python och Ruby. Dokumentationen Àr ganska detaljerad, men som med andra avancerade teknologier Àr gemenskapen relativt liten jÀmfört med de mest populÀra databasteknologierna, vilket kan leda till ökad tid som spenderas pÄ att lösa mindre vanliga anvÀndningsfall eller problem.
SÄ, hur Àr det med stödet för lokal utveckling?
Vi hittade inget sÀtt att skapa en Cloud Spanner-instans i en lokal miljö. Det nÀrmaste vi fick var en Docker-avbildning , vilket i princip liknar, men i praktiken skiljer sig mycket. Till exempel kan CockroachDB anvÀnda PostgreSQL JDBC. Eftersom utvecklingsmiljön mÄste vara sÄ nÀra produktionsmiljön som möjligt, Àr Cloud Spanner inte idealisk, eftersom man mÄste förlita sig pÄ en fullstÀndig Spanner-instans. För att spara kostnader kan du vÀlja en instans för en region.
Stöd för administration?
Att skapa en Cloud Spanner-instans Àr mycket enkelt. Du behöver bara vÀlja mellan att skapa en multiregional instans eller en instans för en region, ange region(er) och antal noder. PÄ mindre Àn en minut kommer instansen att starta och vara redo att anvÀndas.
NÄgra grundlÀggande mÀtvÀrden Àr direkt tillgÀngliga pÄ Spanner-sidan i Google Console. Mer detaljerade vyer Àr tillgÀngliga via Stackdriver, dÀr du ocksÄ kan stÀlla in tröskelvÀrden för mÀtvÀrden och aviseringar.
TillgÄng till resurser?
MySQL erbjuder omfattande och mycket detaljerade instÀllningar för anvÀndarrÀttigheter/roller. Det Àr enkelt att konfigurera Ätkomst till en specifik tabell eller till och med bara ett delmÀngd av dess kolumner. Cloud Spanner anvÀnder Google Identity & Access Management (IAM), vilket gör att du kan stÀlla in policyer och ÄtkomstrÀttigheter pÄ en mycket hög nivÄ. Den mest detaljerade versionen Àr databasnivÄtillstÄnd, vilket inte passar in i de flesta produktionsfall. Denna begrÀnsning tvingar dig att lÀgga till ytterligare sÀkerhetsÄtgÀrder i din kod, infrastruktur eller bÄda för att förhindra obehörig anvÀndning av Spanner-resurser.
SĂ€kerhetskopior?
För att sĂ€ga det enkelt, det finns inga sĂ€kerhetskopior i Cloud Spanner. Ăven om Googles höga SLA-krav kan garantera att du inte förlorar nĂ„gra data pĂ„ grund av hĂ„rdvarufel eller databasproblem, skyddar det inte mot mĂ€nskliga misstag, applikationsfel osv. Vi vet alla regeln: hög tillgĂ€nglighet ersĂ€tter inte en rimlig sĂ€kerhetskopieringsstrategi. För nĂ€rvarande Ă€r det enda sĂ€ttet att sĂ€kerhetskopiera data att programvaru-streama dem frĂ„n databasen till en separat lagringsmiljö.
FrÄgeprestanda?
För datainlÀsning och testning av frÄgor anvÀnde vi Yahoo! Cloud Serving Benchmark. Tabellen nedan visar arbetsbelastningen B YCSB med lÀsningskvot 95 % och skrivkvot 5 %.
* Belastningstestet utfördes pÄ berÀkningsmotorn (CE) n1-standard-32 (32 vCPU, 120 GB RAM), och testinstansen var aldrig en flaskhals i testerna.
** Det maximala antalet trÄdar i en YCSB-instans Àr 400. Totalt behövde sex parallella YCSB-testinstanser köras för att fÄ totalt 2400 trÄdar.
Tittande pĂ„ testresultaten, sĂ€rskilt nĂ€r det gĂ€ller kombinationen av processorbelastning och TPS, ser vi tydligt att Cloud Spanner skalar ganska bra. Den stora belastningen som skapas av mĂ„nga trĂ„dar kompenseras av antalet noder i Cloud Spanner-klustret. Ăven om fördröjningen verkar ganska hög, sĂ€rskilt vid arbete med 2400 trĂ„dar, kan det krĂ€vas omtestning med 6 mindre instanser av berĂ€kningsmotorn för att fĂ„ mer exakta siffror. Varje instans kommer att köra ett YCSB-test istĂ€llet för en stor CE-instans med 6 parallella tester. PĂ„ sĂ„ sĂ€tt blir det lĂ€ttare att sĂ€rskilja fördröjningarna i Cloud Spanner och de fördröjningar som lĂ€ggs till genom nĂ€tverksanslutningen mellan Cloud Spanner och CE-instansen dĂ€r testet utförs.
Hur fungerar Cloud Spanner som OLAP?
Partionering?
Att dela upp data i fysiskt och/eller logiskt oberoende segment, kallade partitioner, Àr en mycket populÀr idé som Àr typisk för de flesta OLAP-mekanismer. Partitioner kan avsevÀrt förbÀttra frÄgeprestanda och databasunderhÄll. Att gÄ djupare in pÄ partitioner skulle vara en egen artikel, sÄ lÄt oss bara nÀmna vikten av att ha en partitioneringsschema och sub-partionering. Möjligheten att dela upp data i partitioner och till och med vidare i underpartitioner Àr nyckeln till prestanda i analytiska frÄgor.
Cloud Spanner stödjer inte partitioner i egentlig mening. Den delar upp data inÄt i sÄ kallade split-er baserat pÄ intervall av primÀra nycklar. Dela upp sker automatiskt för att balansera lasten i Cloud Spanner-klustret. En mycket anvÀndbar funktion hos Cloud Spanner Àr uppdelningen av den grundlÀggande belastningen av moderntabellen (tabellen som inte alterneras med en annan). Spanner identifierar automatiskt om split data lÀses oftare Àn data i andra split-er och kan besluta att ytterligare dela upp. PÄ sÄ sÀtt kan fler noder involveras i frÄgan, vilket effektivt ökar genomströmningen.
DatainlÀsning?
Cloud Spanner-metoden för stora datamÀngder Àr densamma som vid vanlig inladdning. För att uppnÄ maximal prestanda mÄste du följa vissa rekommendationer, inklusive:
- Sortera dina data efter primÀrnyckeln.
- Dela upp dem i 10*antal noder separata sektioner.
- Skapa en uppsÀttning arbetsuppgifter som laddar data parallellt.
Vid denna datainladdning anvÀnds alla noder i Cloud Spanner.
Vi anvÀnde arbetsbelastning A YCSB för att generera en datamÀngd av 10M rader.
* Belastningstestet genomfördes pÄ berÀkningsmotorn n1-standard-32 (32 vCPU, 120 GB minne), och testinstansen var aldrig den begrÀnsande faktorn i testerna.
** Konfiguration med 1 nod rekommenderas inte för nÄgot produktionsbelastning.
Som nÀmnts ovan hanterar Cloud Spanner automatiskt splittringar beroende pÄ deras belastning, sÄ resultaten förbÀttras efter flera pÄ varandra följande testkörningar. Resultaten hÀr Àr de bÀsta vi fick. Genom att titta pÄ siffrorna ovan kan vi se hur Cloud Spanner (bra) skalas med ökande antal noder i klustret. Siffrorna som sticker ut representerar extremt lÄga genomsnittliga latenser som kontrasterar med resultaten frÄn blandade arbetsbelastningar (95% för lÀsning och 5% för skrivning), som beskrivs ovan.
Skalning?
Att öka och minska antalet noder i Cloud Spanner Àr en uppgift som utförs med ett klick. Om du snabbt vill ladda data kan du övervÀga att öka instansen till max (i vÄrt fall var det 25 noder i regionen US-EAST), och sedan minska antalet noder till det som passar din normala belastning efter att alla data Àr i databasen, med tanke pÄ begrÀnsningen pÄ 2 TB/nod.
Vi blev pÄminda om denna grÀns Àven med en mycket mindre databas. Efter flera körningar av belastningstester hade vÄr databas en storlek av cirka 155 GB, och vid minskning till en instans med 1 nod fick vi följande felmeddelande:
Vi lyckades minska skalan frÄn 25 till 2 instanser, men vi fastnade vid tvÄ noder.
Ăkningen och minskningen av antalet noder i Cloud Spanner-klustret kan automatiseras med hjĂ€lp av REST API. Detta kan vara sĂ€rskilt anvĂ€ndbart för att minska den ökade belastningen pĂ„ systemet under högtrafikperioder.
Prestanda för OLAP-frÄgor?
Vi planerade ursprungligen att Àgna betydande tid Ät vÄr bedömning av Spanner pÄ denna del. Efter flera SELECT COUNT insÄg vi genast att testningen skulle bli kort och att Spanner INTE skulle passa som OLAP-motor. Oavsett antalet noder i klustret tog en enkel frÄga för att rÀkna antalet rader i en tabell med 10 miljoner rader mellan 55 och 60 sekunder. Dessutom ledde varje frÄga som krÀvde mer minne för att lagra mellanresultat till ett OOM-fel.
SELECT COUNT(DISTINCT(field0)) FROM usertable; â (10M distinkta vĂ€rden) -> SpoolingHashAggregateIterator fick slut pĂ„ minne under den nya raden.
Vissa siffror för TPC-H-frÄgor finns i artikeln av Todd Lipkon , bilder 42 och 43. Dessa siffror överensstÀmmer med vÄra egna resultat (tyvÀrr).
4. VĂ„ra slutsatser
Med tanke pÄ det nuvarande tillstÄndet av Cloud Spanner-funktioner Àr det svÄrt att förestÀlla sig en enkel ersÀttning för ett befintligt OLTP-lösning, sÀrskilt nÀr dina behov överstiger dess kapacitet. Det skulle ta betydande tid att bygga en lösning med tanke pÄ bristerna hos Cloud Spanner.
NÀr vi började utvÀrdera Cloud Spanner förvÀntade vi oss att dess hanteringsfunktioner skulle vara pÄ nivÄ eller Ätminstone inte sÄ lÄngt ifrÄn andra lösningar frÄn Google SQL. Men vi blev överraskade över den totala avsaknaden av sÀkerhetskopior och mycket begrÀnsad Ätkomstkontroll till resurser. För att inte tala om avsaknaden av vyer, bristen pÄ lokala utvecklingsmiljöer, icke-understödda sekvenser, JDBC utan stöd för DML och DDL och sÄ vidare.
SÄ, vart ska man gÄ för att skala en transaktionsdatabas? Det verkar finnas mÄnga lösningar med bÄde stÀngd och öppen kÀllkod pÄ marknaden (nÄgra av dem nÀmns i denna artikel), varje med sina styrkor och svagheter, men ingen av dem erbjuder en SaaS-lösning med SLA pÄ 99,999 % och hög grad av överensstÀmmelse. Om en hög SLA-nivÄ Àr ditt frÀmsta mÄl och du inte Àr benÀgen att skapa en egen lösning för flera molnmiljöer, kan Cloud Spanner vara den lösning du söker. Men du bör kÀnna till dess begrÀnsningar.
För rÀttvisans skull bör det nÀmnas att Cloud Spanner endast slÀpptes för allmÀnheten vÄren 2017, sÄ det Àr rimligt att förvÀnta sig att vissa av dess nuvarande brister sÄ smÄningom försvinner (förhoppningsvis), och nÀr det hÀnder kan det förÀndra spelet. Trots allt, Cloud Spanner Àr inte bara ett sidoprojekt för Google. Google anvÀnder det som grund för andra produkter. Och nÀr Google nyligen ersatte Megastore i Google Cloud Storage med Cloud Spanner, gjorde det att Google Cloud Storage blev strikt överenskommet för objektlistor pÄ vÀrldsstandard (vilket fortfarande inte gÀller för) ).
SĂ„ hoppet lever fortfarande... vi hoppas.
Detta Àr allt. Precis som författaren av artikeln fortsÀtter vi att hoppas, vad tycker du om detta? Skriv i kommentarerna.
Vi inbjuder alla intresserade att besöka vÄr dÀr vi kommer att berÀtta mer om kursen frÄn OTUS.
KĂ€lla: habr.com
