Hej Khabrovsk beboere. Som sædvanlig deler vi fortsat interessant materiale forud for start af nye kurser. I dag har vi, specielt til dig, udgivet en artikel om Google Cloud Spanner, der falder sammen med lanceringen af kurset .
Oprindeligt udgivet i .
Som en virksomhed, der tilbyder en række cloud-baserede POS-løsninger til detailhandlere, restauratører og onlinesælgere over hele verden, bruger Lightspeed flere forskellige typer databaseplatforme til en række forskellige transaktions-, analytiske og søgeanvendelsessager. Hver af disse databaseplatforme har sine egne styrker og svagheder. Derfor, da Google introducerede Cloud Spanner på markedet - lovende funktioner, der ikke er set i verden af relationelle databaser, såsom praktisk talt ubegrænset horisontal skalerbarhed og en 99,999 % serviceniveauaftale (SLA), — vi kunne ikke gå glip af muligheden for at få fingrene i det!
For at give et omfattende overblik over vores erfaring med Cloud Spanner, samt de evalueringskriterier, vi brugte, vil vi dække følgende emner:
- Vores evalueringskriterier
- Cloud Spanner i en nøddeskal
- Vores vurdering
- Vores fund
1. Vores evalueringskriterier
Før vi dykker ned i detaljerne ved Cloud Spanner, dets ligheder og forskelle med andre løsninger på markedet, lad os først tale om de vigtigste use cases, vi havde i tankerne, da vi overvejede, hvor Cloud Spanner skulle implementeres i vores infrastruktur:
- Som erstatning for den (overvejende) traditionelle SQL-databaseløsning
- Sådan OLTP-løsning med OLAP-understøttelse
Note: For at gøre det nemt og lette at sammenligne sammenligner denne artikel Cloud Spanner med MySQL-varianterne af GCP Cloud SQL og Amazon AWS RDS-løsningsfamilierne.
Brug af Cloud Spanner som erstatning for en traditionel SQL-databaseløsning
I miljøet traditionel databaser, når databaseforespørgslens responstid nærmer sig eller endda overstiger foruddefinerede applikationstærskler (hovedsageligt på grund af en stigning i antallet af brugere og/eller anmodninger), er der flere måder at reducere responstiden til acceptable niveauer. De fleste af disse løsninger involverer dog manuel indgriben.
For eksempel er det første skridt at tage at se på de forskellige præstationsrelaterede databaseparametre og justere dem, så de bedst matcher applikationsbrugsmønstre. Hvis dette ikke er nok, kan du vælge at skalere databasen lodret eller vandret.
Vertikal skalering af en applikation indebærer opgradering af serverinstansen, typisk ved at tilføje flere processorer/kerner, mere RAM, hurtigere lagring osv. Tilføjelse af flere hardwareressourcer resulterer i øget databaseydeevne, målt primært i transaktioner i sekundet, og transaktionsforsinkelse for OLTP-systemer. Relationelle databasesystemer (som bruger en multi-threaded tilgang) såsom MySQL skalerer godt lodret.
Der er flere ulemper ved denne tilgang, men den mest åbenlyse er den maksimale serverstørrelse på markedet. Når grænsen for den største serverinstans er nået, er der kun én mulighed tilbage: vandret skalering.
Horisontal skalering er en tilgang, hvor flere servere føjes til en klynge, hvilket ideelt set øger ydeevnen lineært, efterhånden som antallet af servere tilføjes. Flertal traditionel Databasesystemer skalerer ikke horisontalt godt eller skalerer slet ikke. For eksempel kan MySQL skalere vandret til læseoperationer ved at tilføje slavelæsere, men kan ikke skalere vandret til skrivning.
På den anden side kan Cloud Spanner på grund af sin natur nemt skalere vandret med minimal indgriben.
Fuldt udstyret DBMS som en service skal vurderes fra forskellige vinkler. Som grundlag tog vi det mest populære DBMS i skyen - for Google, GCP Cloud SQL og for Amazon, AWS RDS. I vores vurdering fokuserede vi på følgende kategorier:
- Feature mapping: omfang SQL, DDL, DML; forbindelsesbiblioteker/forbindelser, transaktionssupport og så videre.
- Udviklingsstøtte: nem udvikling og test.
- Administrationsstøtte: instanshåndtering - for eksempel skalering op/ned og opgradering af instanser; SLA, backup og gendannelse; sikkerhed/adgangskontrol.
Brug af Cloud Spanner som en OLAP-aktiveret OLTP-løsning
Selvom Google ikke eksplicit hævder, at Cloud Spanner er designet til analytisk behandling, deler den nogle attributter med andre motorer såsom Apache Impala & Kudu og YugaByte, som er designet til OLAP-arbejdsbelastninger.
Selvom der kun var en lille chance for, at Cloud Spanner inkluderede en konsekvent udskalerings-HTAP-motor (hybrid transaktions-/analysebehandling) med et (mere eller mindre) brugbart OLAP-funktionssæt, synes vi, det ville være vores opmærksomhed værd.
Med dette i tankerne kiggede vi på følgende kategorier:
- Understøttelse af dataindlæsning, indekser og partitionering
- Query Performance og DML
2. Cloud Spanner i en nøddeskal
Google Spanner er et clustered relational database management system (RDBMS), som Google bruger til flere af sine egne tjenester. Google gjorde det generelt tilgængeligt for Google Cloud Platform-brugere i begyndelsen af 2017.
Her er nogle af Cloud Spanner-attributterne:
- Meget konsistent skalerbar RDBMS-klynge: Bruger hardware-tidssynkronisering for at sikre datakonsistens.
- Understøttelse af krydstabeltransaktioner: Transaktioner kan spænde over flere tabeller - ikke nødvendigvis begrænset til en enkelt tabel (i modsætning til Apache HBase eller Apache Kudu).
- Primærnøglebaserede tabeller: Alle tabeller skal have en erklæret primærnøgle (PC), som kan bestå af flere kolonner i tabellen. Tabeldata gemmes i pc-rækkefølge, hvilket gør det meget effektivt og hurtigt til pc-søgning. Som andre pc-baserede systemer skal implementeringen modelleres med foruddesignede use cases i tankerne for at opnå .
- Stribede tabeller: Tabeller kan have fysiske afhængigheder af hinanden. Rækker i en undertabel kan matches mod rækker i en overordnet tabel. Denne tilgang fremskynder søgningen efter relationer, der kan identificeres under datamodelleringsfasen, såsom samlokalisering af kunder og deres fakturaer.
- Indekser: Cloud Spanner understøtter sekundære indekser. Indekset består af de indekserede kolonner og alle PC-kolonner. Hvis det ønskes, kan indekset også indeholde andre ikke-indekserede kolonner. Indekset kan sammenflettes med den overordnede tabel for at fremskynde forespørgsler. Adskillige begrænsninger gælder for indekser, såsom det maksimale antal yderligere kolonner, der er gemt i indekset. Desuden er forespørgsler gennem indekser muligvis ikke så ligetil som i andre RDBMS'er.
"Cloud Spanner vælger kun et indeks automatisk i sjældne tilfælde. Især vælger Cloud Spanner ikke automatisk et sekundært indeks, hvis en forespørgsel anmoder om kolonner, der ikke er gemt i '.
- Service Level Agreement (SLA): Implementering i én region med en SLA på 99,99 %; multi-regionale implementeringer med 99,999 % SLA. Selvom SLA i sig selv kun er en aftale og ikke en garanti af nogen art, tror jeg, at folk hos Google har nogle hårde data til at fremsætte et så stærkt krav. (Til reference betyder 99,999 % 26,3 sekunders utilgængelighed pr. måned.)
- Mere:
Note: Apache Tephra-projektet tilføjer forbedret transaktionssupport til Apache HBase (også nu implementeret i Apache Phoenix som beta).
3. Vores vurdering
Så vi har alle læst Googles påstande om fordelene ved Cloud Spanner - praktisk talt ubegrænset horisontal skalering, samtidig med at høj konsistens og en meget høj SLA opretholdes. Selvom disse krav under alle omstændigheder er ekstremt vanskelige at opnå, var vores mål ikke at tilbagevise dem. Lad os i stedet fokusere på andre ting, som de fleste databasebrugere interesserer sig for: paritet og brugervenlighed.
Vi vurderede Cloud Spanner som en erstatning for Sharded MySQL
Google Cloud SQL og Amazon AWS RDS, to af de mest populære OLTP DBMS'er på cloudmarkedet, har et meget stort sæt funktioner. Men for at skalere disse databaser ud over størrelsen af en enkelt node, skal du udføre applikationspartitionering. Denne tilgang skaber yderligere kompleksitet for både applikationer og administration. Vi så på, hvordan Spanner passer ind i scenariet med at kombinere flere shards i en enkelt instans, og hvilke funktioner (hvis nogen) der muligvis skal ofres.
SQL, DML og DDL support, samt connector og biblioteker?
Først, når du starter med en database, skal du oprette en datamodel. Hvis du tror, du kan forbinde JDBC Spanner til dit foretrukne SQL-værktøj, vil du opdage, at du kan forespørge om dine data med det, men du kan ikke bruge det til at oprette en tabel eller ændre (DDL) eller nogen som helst indsæt/opdater/slet operationer (DML). Googles officielle JDBC understøtter ikke nogen af disse.
"Drivere understøtter i øjeblikket ikke DML- eller DDL-sætninger."
Nøgledokumentation
Situationen er ikke bedre med GCP-konsollen - du kan kun sende SELECT-forespørgsler. Heldigvis er der en JDBC-driver med understøttelse af DML og DDL fra fællesskabet, inklusive transaktioner . Selvom denne driver er yderst nyttig, er manglen på Googles egen JDBC-driver overraskende. Heldigvis tilbyder Google ret bred support til klientbiblioteker (baseret på gRPC): C#, Go, Java, node.js, PHP, Python og Ruby.
Den næsten obligatoriske brug af Cloud Spanner tilpassede API'er (på grund af manglen på DDL og DML i JDBC) resulterer i nogle begrænsninger for relaterede kodeområder såsom forbindelsespuljer eller databasebindingsrammer (f.eks. Spring MVC). Når du bruger JDBC, kan du typisk frit vælge din foretrukne forbindelsespulje (f.eks. HikariCP, DBCP, C3PO osv.), der er testet og fungerer godt. I tilfælde af brugerdefinerede Spanner API'er er vi nødt til at stole på rammer/bindingspuljer/sessioner, som vi selv har oprettet.
Det primære nøgle (PC)-centrerede design gør det muligt for Cloud Spanner at være meget hurtig, når man får adgang til data via pc, men introducerer også nogle forespørgselsproblemer.
- Du kan ikke opdatere den primære nøgleværdi. Du skal først slette posten fra den originale pc og genindsætte den med den nye værdi. (Dette ligner andre pc-orienterede database-/lagermotorer.)
- Eventuelle UPDATE- og DELETE-sætninger skal angive PC i WHERE, derfor kan der ikke være tomme DELETE alle sætninger - der skal altid være en underforespørgsel, for eksempel: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Manglende mulighed for automatisk stigning eller noget lignende, der sætter sekvensen for pc-feltet. For at dette virker, skal den tilsvarende værdi oprettes på applikationssiden.
Sekundære indekser?
Google Cloud Spanner har indbygget understøttelse af sekundære indekser. Dette er en meget fin funktion, som ikke altid er til stede i andre teknologier. Apache Kudu understøtter i øjeblikket slet ikke sekundære indekser, og Apache HBase understøtter ikke indekser direkte, men kan tilføje dem gennem Apache Phoenix.
Indekser i Kudu og HBase kan modelleres som en separat tabel med en anden sammensætning af primærnøgler, men atomiciteten af de operationer, der udføres på den overordnede tabel og tilhørende indekstabeller, skal udføres på applikationsniveau og er ikke triviel at implementere korrekt.
Som nævnt i Cloud Spanner-gennemgangen kan dens indekser afvige fra MySQL-indekser. Derfor bør der udvises særlig forsigtighed, når der konstrueres forespørgsler og profilering for at sikre, at det korrekte indeks bruges, hvor det er nødvendigt.
Repræsentation?
Et meget populært og nyttigt objekt i en database er visninger. De kan være nyttige til et stort antal brugssager; mine to favoritter er det logiske abstraktionslag og sikkerhedslaget. Cloud Spanner understøtter desværre IKKE visninger. Dette begrænser os dog kun delvist, fordi der ikke er nogen granularitet for adgangstilladelser på kolonneniveau, hvor visninger kan være en levedygtig løsning.
Se Cloud Spanner-dokumentationen for et afsnit, der beskriver kvoter og begrænsninger (), er der især én, der kan være problematisk for nogle applikationer: Cloud Spanner out of the box har en grænse på maksimalt 100 databaser pr. instans. Dette kan naturligvis være en stor flaskehals for en database, der er designet til at skalere til over 100 databaser. Heldigvis fandt vi ud af, efter at have talt med vores tekniske Google-repræsentant, at denne grænse kan øges til næsten enhver værdi gennem Google Support.
Udviklingsstøtte?
Cloud Spanner tilbyder ret anstændig programmeringssprogunderstøttelse til at arbejde med sin API. Officielt understøttede biblioteker er inden for områderne C#, Go, Java, node.js, PHP, Python og Ruby. Dokumentationen er ret detaljeret, men som med andre avancerede teknologier er fællesskabet ret lille i forhold til de mest populære databaseteknologier, hvilket kan føre til mere tid brugt på at løse mindre almindelige use cases eller problemer.
Så hvad med at støtte lokal udvikling?
Vi har ikke fundet en måde at oprette en Cloud Spanner-instans på stedet. Det nærmeste, vi kom, var et Docker-billede. , som er ens i princippet, men meget anderledes i praksis. For eksempel kan CockroachDB bruge PostgreSQL JDBC. Da udviklingsmiljøet skal være så tæt på produktionsmiljøet som muligt, er Cloud Spanner ikke ideelt, da det skal stole på en fuld Spanner-instans. For at spare omkostninger kan du vælge en enkeltregionsinstans.
Administrationsstøtte?
Det er meget enkelt at oprette en Cloud Spanner-instans. Du skal blot vælge mellem at oprette en multi-region eller single-region instans, specificere region(er) og antallet af noder. Om mindre end et minut vil din instans være oppe at køre.
Adskillige rudimentære metrics er direkte tilgængelige fra siden Skrue i Google Console. Mere detaljerede visninger er tilgængelige via Stackdriver, hvor du også kan indstille metriske tærskler og advarselspolitikker.
Adgang til ressourcer?
MySQL tilbyder omfattende og meget detaljerede indstillinger for brugertilladelser/roller. Du kan nemt konfigurere adgang til en specifik tabel eller endda bare en undergruppe af dens kolonner. Cloud Spanner bruger Googles Identity & Access Management (IAM) værktøj, som kun giver dig mulighed for at indstille politikker og tilladelser på et meget højt niveau. Den mest granulære mulighed er opløsning på databaseniveau, som ikke passer ind i de fleste produktionstilfælde. Denne begrænsning tvinger dig til at tilføje yderligere sikkerhedsforanstaltninger til din kode, infrastruktur eller begge dele for at forhindre uautoriseret brug af Spanner-ressourcer.
Sikkerhedskopier?
For at sige det enkelt, er der ingen sikkerhedskopier i Cloud Spanner. Selvom Googles høje SLA-krav kan sikre, at du ikke mister nogen data på grund af hardware- eller databasefejl, menneskelige fejl, applikationsfejl osv. Vi kender alle reglen: høj tilgængelighed er ikke en erstatning for en sund backup-strategi. I øjeblikket er den eneste måde at sikkerhedskopiere data på ved at streame dem programmæssigt fra en database til et separat lagermiljø.
Forespørgselsydelse?
Vi brugte Yahoo! til at indlæse data og teste forespørgsler. Cloud Serving Benchmark. Tabellen nedenfor viser YCSB-arbejdsbelastning B med et 95 % læse- til 5 % skriveforhold.
* Belastningstesten blev kørt på n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB hukommelse), og testinstansen var aldrig en flaskehals i testene.
** Det maksimale antal tråde i en enkelt YCSB-instans er 400. I alt seks parallelle instanser af YCSB-test skulle køres for at få i alt 2400 tråde.
Ser vi på benchmark-resultaterne, især kombinationen af CPU-belastning og TPS, kan vi tydeligt se, at Cloud Spanner skalerer ganske godt. Den store belastning, der skabes af det store antal tråde, opvejes af det store antal noder i Cloud Spanner-klyngen. Mens latensen ser ret høj ud, især når du kører med 2400 tråde, kan det være nødvendigt at genteste med 6 mindre forekomster af computermotoren for at få mere nøjagtige tal. Hver instans vil køre en YCSB-test i stedet for en stor CE-instans med 6 parallelle test. På denne måde bliver det nemmere at skelne mellem Cloud Spanner-anmodningsforsinkelse og latenstid tilføjet af netværksforbindelsen mellem Cloud Spanner og den CE-instans, der kører testen.
Hvordan fungerer Cloud Spanner som en OLAP?
Opdeling?
Opdeling af data i fysisk og/eller logisk uafhængige segmenter, kaldet partitioner, er et meget populært koncept, der findes i de fleste OLAP-motorer. Partitioner kan forbedre forespørgselsydeevne og databasevedligeholdelse markant. At gå dybere ind i partitionering ville være en eller flere separate artikler, så lad os bare nævne vigtigheden af at have et partitionerings- og underpartitioneringsskema. Evnen til at opdele data i partitioner og endnu længere i underpartitioner er nøglen til analytisk forespørgselsydeevne.
Cloud Spanner understøtter ikke partitioner som sådan. Det opdeler dataene internt i såkaldte delt-s baseret på primære nøgleområder. Partitionering udføres automatisk for at afbalancere belastningen i en Cloud Spanner-klynge. En meget nyttig funktion ved Cloud Spanner er opdelingen af den overordnede tabels basisbelastning (en tabel, der ikke er interleaves med en anden). Skruenøgle registrerer automatisk, om den indeholder delt data, der læses hyppigere end data i andre delt-ah, og kan beslutte om yderligere adskillelse. På denne måde kan flere noder involveres i en anmodning, hvilket også effektivt øger gennemløbet.
Indlæser data?
Cloud Spanner-metoden til massedata er den samme som ved normal indlæsning. For at opnå maksimal ydeevne skal du følge nogle retningslinjer, herunder:
- Sorter dine data efter primærnøgle.
- dividere dem med 10*antal noder separate afsnit.
- Opret et sæt arbejdsopgaver, der indlæser data parallelt.
Denne dataindlæsning bruger alle Cloud Spanner-noder.
Vi brugte YCSB arbejdsbelastning A til at generere et datasæt på 10M rækker.
* Belastningstesten blev kørt på n1-standard-32 compute engine (32 vCPU, 120 GB hukommelse), og testforekomsten var aldrig en flaskehals i testene.
**Opsætning af enkelt node anbefales ikke til nogen produktionsbelastning.
Som nævnt ovenfor behandler Cloud Spanner automatisk opdelinger baseret på deres belastning, så resultaterne forbedres efter flere på hinanden følgende gentagelser af testen. Resultaterne præsenteret her er de bedste resultater, vi har opnået. Ser vi på tallene ovenfor, kan vi se, hvordan Cloud Spanner skalerer (godt), når antallet af noder i klyngen stiger. De tal, der skiller sig ud, er de ekstremt lave gennemsnitlige latenser, som står i kontrast til resultaterne for blandede arbejdsbelastninger (95 % læser og 5 % skriver) som beskrevet i afsnittet ovenfor.
Skalering?
At øge og formindske antallet af Cloud Spanner-noder er en opgave med et enkelt klik. Hvis du vil indlæse data hurtigt, kan du overveje at booste din instans til det maksimale (i vores tilfælde var det 25 noder i USA-ØST-regionen) og derefter reducere antallet af noder, der er kvalificerede til din normale belastning, når alle data er i databasen, med henvisning til grænsen på 2 TB/node.
Vi blev mindet om denne grænse, selv med en meget mindre database. Efter adskillige kørsler af belastningstests var vores database omkring 155 GB i størrelse, og når den blev skaleret ned til en 1 node-forekomst, modtog vi følgende fejl:
Det lykkedes os at skalere ned fra 25 til 2 forekomster, men vi sad fast ved to noder.
Forøgelse og formindskelse af antallet af noder i en Cloud Spanner-klynge kan automatiseres ved hjælp af REST API. Dette kan især være nyttigt til at reducere øget systembelastning i travle arbejdstimer.
Ydeevne af OLAP-forespørgsler?
Vi planlagde oprindeligt at bruge en betydelig mængde tid på vores evaluering af Spanner på denne del. Efter adskillige SELECT COUNTs indså vi straks, at testning ville være kort, og at Spanner IKKE ville være en passende motor til OLAP. Uanset antallet af noder i klyngen tog det mellem 10 og 55 sekunder at vælge antallet af rækker i en 60M rækketabel. Derudover mislykkedes enhver forespørgsel, der krævede mere hukommelse til at gemme mellemresultater, med en OOM-fejl.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Nogle tal for TPC-H-forespørgsler kan findes i Todd Lipcons artikel , slides 42 og 43. Disse tal stemmer overens med vores egne resultater (desværre).
4. Vores konklusioner
I betragtning af den nuværende tilstand af Cloud Spanners funktioner er det svært at forestille sig, at det er en simpel erstatning for din eksisterende OLTP-løsning, især når dine behov vokser fra det. Der skulle bruges en betydelig mængde tid på at bygge en løsning omkring Cloud Spanners mangler.
Da vi begyndte at evaluere Cloud Spanner, forventede vi, at dens administrationsfunktioner var på niveau med eller i det mindste ikke for langt væk fra andre Google SQL-løsninger. Men vi blev overrasket over den fuldstændige mangel på sikkerhedskopier og meget begrænset kontrol over adgangen til ressourcer. For ikke at nævne ingen visninger, intet lokalt udviklingsmiljø, ikke-understøttede sekvenser, JDBC uden DML- og DDL-understøttelse og så videre.
Så hvor går en person, der har brug for at skalere en transaktionsdatabase hen? Der ser ikke ud til at være en eneste løsning på markedet, der passer til alle use cases. Der er mange lukkede og open source-løsninger (hvoraf nogle er nævnt i denne artikel), hver med deres egne styrker og svagheder, men ingen af dem tilbyder SaaS med en 99,999% SLA og høj konsistens. Hvis en høj SLA er dit hovedmål, og du ikke er tilbøjelig til at bygge en tilpasset multi-cloud-løsning, kan Cloud Spanner være den løsning, du leder efter. Men du bør være opmærksom på alle dens begrænsninger.
For at være retfærdig blev Cloud Spanner først udgivet til offentligheden i foråret 2017, så det er rimeligt at forvente, at nogle af dets nuværende mangler i sidste ende kan forsvinde (forhåbentlig), og når de gør det, kan det være en game changer. Cloud Spanner er trods alt ikke kun et sideprojekt for Google. Google bruger det som grundlag for andre Google-produkter. Og da Google for nylig erstattede Megastore i Google Cloud Storage med Cloud Spanner, tillod det Google Cloud Storage at blive meget konsistent for lister over objekter på global skala (hvilket stadig ikke er tilfældet for ).
Så der er stadig håb... håber vi.
Det er alt. Ligesom artiklens forfatter håber vi også fortsat, men hvad synes du om dette? Skriv i kommentarerne
Vi inviterer alle til at besøge vores hvor vi vil fortælle dig detaljeret om kurset fra OTUS.
Kilde: www.habr.com