Hei, Khabrovites. Tradisjonelt fortsetter vi å dele interessant materiale like før oppstart av nye kurs. I dag, spesielt for deg, har vi oversatt en artikkel om Google Cloud Spanner, tidsbestemt til å falle sammen med lanseringen av kurset .
Opprinnelig publisert i .
Som et selskap som tilbyr en rekke skybaserte POS-løsninger for forhandlere, restauratører og nettbutikker over hele verden, bruker Lightspeed flere forskjellige typer databaseplattformer for en rekke transaksjons-, analytiske- og søketilfeller. Hver av disse databaseplattformene har sine egne styrker og svakheter. Derfor, da Google introduserte Cloud Spanner på markedet – lovende funksjoner som ikke er sett i verden av relasjonsdatabaser, for eksempel praktisk talt ubegrenset horisontal skalerbarhet og en 99,999 % servicenivåavtale (SLA) , Vi kunne ikke gå glipp av muligheten til å ha henne i våre hender!
For å gi en omfattende oversikt over vår erfaring med Cloud Spanner, samt evalueringskriteriene vi brukte, vil vi dekke følgende emner:
- Våre evalueringskriterier
- Cloud Spanner i et nøtteskall
- Vår vurdering
- Våre funn
1. Våre evalueringskriterier
Før vi dykker ned i detaljene til Cloud Spanner, dets likheter og forskjeller med andre løsninger på markedet, la oss først snakke om de viktigste brukstilfellene vi hadde i tankene da vi vurderte hvor vi skulle distribuere Cloud Spanner i infrastrukturen vår:
- Som erstatning for den (rådende) tradisjonelle SQL-databaseløsningen
- Som en OLAP-aktivert OLTP-løsning
Merk: For å lette sammenligningen sammenligner denne artikkelen Cloud Spanner med MySQL-variantene av GCP Cloud SQL og Amazon AWS RDS-løsningsfamiliene.
Bruker Cloud Spanner som erstatning for en tradisjonell SQL-databaseløsning
I miljøet tradisjonelle databaser, når responstiden for en databasespørring nærmer seg eller til og med overskrider forhåndsdefinerte applikasjonsterskler (primært på grunn av en økning i antall brukere og/eller forespørsler), er det flere måter å redusere responstiden til akseptable nivåer. De fleste av disse løsningene innebærer imidlertid manuell intervensjon.
Det første trinnet å ta er for eksempel å se på de ulike ytelsesrelaterte databaseinnstillingene og justere dem for å matche applikasjonsbruksscenariomønstrene best. Hvis dette ikke er nok, kan du velge å skalere databasen vertikalt eller horisontalt.
Oppskalering av en applikasjon innebærer å oppdatere serverforekomsten, typisk ved å legge til flere prosessorer/kjerner, mer RAM, raskere lagring osv. Å legge til flere maskinvareressurser resulterer i økt databaseytelse, målt primært i transaksjoner per sekund, og transaksjonsforsinkelse for OLTP-systemer. Relasjonsdatabasesystemer (som bruker en flertråds tilnærming) som MySQL skalerer godt vertikalt.
Det er flere ulemper med denne tilnærmingen, men den mest åpenbare er den maksimale serverstørrelsen på markedet. Når den største serverinstansgrensen er nådd, er det bare én bane igjen: skaler ut.
Skalering er en tilnærming som legger til flere servere til en klynge for ideelt sett å øke ytelsen lineært etter hvert som flere servere legges til. Flertall tradisjonelle databasesystemer skalerer ikke godt eller skalerer ikke i det hele tatt. For eksempel kan MySQL skalere ut for lesninger ved å legge til slavelesere, men den kan ikke skalere ut for å skrive.
På den annen side, på grunn av sin natur, kan Cloud Spanner enkelt skalere horisontalt med minimal intervensjon.
Full funksjon DBMS som en tjeneste må vurderes fra ulike perspektiver. Som grunnlag tok vi det mest populære DBMS i skyen – for Google, GCP Cloud SQL og for Amazon, AWS RDS. I vår evaluering fokuserte vi på følgende kategorier:
- Funksjonskartlegging: SQL-utstrekning, DDL, DML; tilkoblingsbiblioteker/koblinger, transaksjonsstøtte og så videre.
- Utviklingsstøtte: Enkel utvikling og testing.
- Administrasjonsstøtte: Forekomstadministrasjon som skalering opp/ned og oppgradering av forekomster; SLA, sikkerhetskopiering og gjenoppretting; sikkerhet/tilgangskontroll.
Bruk av Cloud Spanner som en OLAP-aktivert OLTP-løsning
Selv om Google ikke eksplisitt oppgir at Cloud Spanner er for analyse, deler den noen attributter med andre motorer som Apache Impala & Kudu og YugaByte som er designet for OLAP-arbeidsbelastninger.
Selv om det bare var en liten sjanse for at Cloud Spanner inkluderte en konsekvent utskalert HTAP (Hybrid Transactional/Analytic Processing)-motor med et (mer eller mindre) brukbart OLAP-funksjonssett, tror vi det vil fortjene vår oppmerksomhet.
Med det i tankene så vi på følgende kategorier:
- Datalasting, indekser og partisjoneringsstøtte
- Spørringsytelse og DML
2. Cloud Spanner i et nøtteskall
Google Spanner er et clustered relational database management system (RDBMS) som Google bruker for flere av sine egne tjenester. Google gjorde den offentlig tilgjengelig for Google Cloud Platform-brukere tidlig i 2017.
Her er noen av Cloud Spanner-attributtene:
- Svært konsistent, skalerbar RDBMS-klynge: Bruker maskinvaretidssynkronisering for å sikre datakonsistens.
- Krysstabelltransaksjonsstøtte: Transaksjoner kan spenne over flere tabeller - ikke nødvendigvis begrenset til en enkelt tabell (i motsetning til Apache HBase eller Apache Kudu).
- Primærnøkkelbaserte tabeller: Alle tabeller må ha en deklarert primærnøkkel (PC), som kan bestå av flere tabellkolonner. Tabelldata lagres i PC-rekkefølge, noe som gjør det svært effektivt og raskt for PC-søk. Som med andre PC-baserte systemer, må implementeringen modelleres mot forutinntatte brukstilfeller for å oppnå .
- Stripete tabeller: Tabeller kan ha fysiske avhengigheter av hverandre. Radene i den underordnede tabellen kan matches med radene i den overordnede tabellen. Denne tilnærmingen fremskynder søket etter relasjoner som kan bestemmes på datamodelleringsstadiet, for eksempel når kunder og deres fakturaer plasseres sammen.
- Indekser: Cloud Spanner støtter sekundære indekser. En indeks består av indekserte kolonner og alle PC-kolonner. Eventuelt kan indeksen også inneholde andre ikke-indekserte kolonner. Indeksen kan sammenflettes med den overordnede tabellen for å øke hastigheten på spørringene. Flere begrensninger gjelder for indekser, for eksempel maksimalt antall ekstra kolonner som kan lagres i en indeks. Forespørsler gjennom indekser er kanskje ikke like enkle som i andre RDBMS-er.
"Cloud Spanner velger en indeks automatisk bare i sjeldne tilfeller. Spesielt velger ikke Cloud Spanner automatisk en sekundær indeks hvis spørringen ber om noen kolonner som ikke er lagret i '.
- Service Level Agreement (SLA): Distribusjon i én region med 99,99 % SLA; flerregionsdistribusjoner med 99,999 % SLA. Selv om SLA i seg selv bare er en avtale og ikke en garanti av noe slag, tror jeg at Google-folk har noen vanskelige data for å komme med et så sterkt krav. (Til referanse betyr 99,999 % 26,3 sekunders nedetid per måned.)
- mer:
Merk: Apache Tephra-prosjektet legger til avansert transaksjonsstøtte til Apache HBase (nå også implementert i Apache Phoenix som en beta).
3. Vår evaluering
Så vi har alle lest Googles uttalelser om fordelene med Cloud Spanner – praktisk talt ubegrenset horisontal skalering samtidig som den opprettholder høy konsistens og en svært høy SLA. Selv om disse påstandene i alle fall er ekstremt vanskelige å oppnå, var målet vårt ikke å tilbakevise dem. La oss heller fokusere på andre ting som de fleste databasebrukere bryr seg om: paritet og brukervennlighet.
Vi vurderte Cloud Spanner som en erstatning for Sharded MySQL
Google Cloud SQL og Amazon AWS RDS, to av de mest populære OLTP-databasene i skymarkedet, har et veldig stort funksjonssett. Men for å skalere disse databasene utover størrelsen til en enkelt node, må du utføre applikasjonsdeling. Denne tilnærmingen skaper ekstra kompleksitet for både applikasjoner og administrasjon. Vi så på hvordan Spanner passer inn i scenariet med å kombinere flere shards i en instans og hvilke funksjoner (hvis noen) som måtte ofres.
Støtte for SQL, DML og DDL, samt koblingen og bibliotekene?
Først, når du starter med en hvilken som helst database, må du lage en datamodell. Hvis du tror du kan koble JDBC Spanner til ditt favoritt SQL-verktøy, vil du finne at du kan spørre etter dataene dine med det, men du kan ikke bruke det til å lage en tabell eller oppdatering (DDL) eller sette inn/oppdatere/slette operasjoner (DML). Googles offisielle JDBC støtter heller ikke.
"Drivere støtter for øyeblikket ikke DML- eller DDL-setninger."
Snøkkeldokumentasjon
Situasjonen er ikke bedre med GCP-konsollen - du kan bare sende SELECT-spørringer. Heldigvis er det en JDBC-driver med DML- og DDL-støtte fra samfunnet inkludert transaksjoner . Selv om denne driveren er ekstremt nyttig, er fraværet av Googles egen JDBC-driver overraskende. Heldigvis tilbyr Google ganske bred klientbibliotekstøtte (basert på gRPC): C#, Go, Java, node.js, PHP, Python og Ruby.
Den nesten obligatoriske bruken av Cloud Spanners tilpassede API-er (på grunn av mangelen på DDL og DML i JDBC) resulterer i noen begrensninger for relaterte kodeområder, for eksempel tilkoblingspooling eller databasebindingsrammeverk (som Spring MVC). Generelt, når du bruker JDBC, står du fritt til å velge din favoritt tilkoblingspool (f.eks. HikariCP, DBCP, C3PO, etc.) som er testet og fungerer bra. Når det gjelder tilpassede Spanner APIer, må vi stole på rammeverk/binding/session pools som vi har laget selv.
Den primærnøkkel (PC)-orienterte designen gjør at Cloud Spanner kan være veldig rask når du får tilgang til data via PC-en, men introduserer også noen spørringsproblemer.
- Du kan ikke oppdatere verdien til en primærnøkkel; Du må først slette den opprinnelige PC-oppføringen og sette den inn på nytt med den nye verdien. (Dette ligner på andre PC-orienterte database-/lagringsmotorer.)
- Eventuelle UPDATE- og DELETE-setninger må spesifisere PC-en i WHERE, derfor kan det ikke være tomme DELETE alle setninger - det må alltid være en underspørring, for eksempel: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Mangel på et alternativ for automatisk økning eller noe lignende som setter sekvensen for PC-feltet. For at dette skal fungere, må tilsvarende verdi opprettes på applikasjonssiden.
Sekundære indekser?
Google Cloud Spanner har innebygd støtte for sekundære indekser. Dette er en veldig fin funksjon som ikke alltid finnes i andre teknologier. Apache Kudu støtter for øyeblikket ikke sekundære indekser i det hele tatt, og Apache HBase støtter ikke indekser direkte, men kan legge dem til via Apache Phoenix.
Indekser i Kudu og HBase kan modelleres som en egen tabell med forskjellig sammensetning av primærnøkler, men atomiteten til operasjonene som utføres på overordnet tabell og relaterte indekstabeller må utføres på applikasjonsnivå og er ikke triviell å implementere riktig.
Som nevnt i Cloud Spanner-gjennomgangen, kan indeksene avvike fra MySQL-indekser. Det må derfor utvises spesiell forsiktighet ved spørrebygging og profilering for å sikre at riktig indeks brukes der det er behov for det.
Representasjon?
Et veldig populært og nyttig objekt i en database er visninger. De kan være nyttige for et stort antall brukstilfeller; mine to favoritter er det logiske abstraksjonslaget og sikkerhetslaget. Dessverre støtter Cloud Spanner IKKE visninger. Dette begrenser oss imidlertid bare delvis, siden det ikke er noen granularitet på kolonnenivå for tilgangstillatelser, der visninger kan være en akseptabel løsning.
Se Cloud Spanner-dokumentasjonen for en del som beskriver kvoter og grenser (), er det spesielt én som kan være problematisk for enkelte applikasjoner: Cloud Spanner ut av boksen har maksimalt 100 databaser per forekomst. Selvfølgelig kan dette være et stort hinder for en database som er designet for å skalere til over 100 databaser. Heldigvis, etter å ha snakket med vår tekniske representant for Google, fant vi ut at denne grensen kan økes til nesten hvilken som helst verdi gjennom Google Support.
Utviklingsstøtte?
Cloud Spanner tilbyr ganske anstendig programmeringsspråkstøtte for å jobbe med API-en. De offisielt støttede bibliotekene er i området C#, Go, Java, node.js, PHP, Python og Ruby. Dokumentasjonen er ganske detaljert, men som med andre banebrytende teknologier er fellesskapet ganske lite sammenlignet med de fleste populære databaseteknologier, noe som kan resultere i mer tid brukt på mindre vanlige brukstilfeller eller problemer.
Så hva med lokal utviklingsstøtte?
Vi har ikke funnet en måte å lage en Cloud Spanner-forekomst på stedet. Det nærmeste vi kom er et Docker-bilde som er likt i prinsippet, men veldig forskjellig i praksis. For eksempel kan CockroachDB bruke PostgreSQL JDBC. Siden utviklingsmiljøet skal være så nært produksjonsmiljøet som mulig, er ikke Cloud Spanner ideelt fordi du må stole på en full Spanner-instans. For å spare kostnader kan du velge en enkelt regionforekomst.
Administrasjonsstøtte?
Det er veldig enkelt å lage en Cloud Spanner-forekomst. Du trenger bare å velge mellom å lage en multi-region eller en enkelt-region forekomst, spesifisere regionen(e) og antall noder. Om mindre enn ett minutt vil forekomsten være oppe og gå.
Flere elementære beregninger er direkte tilgjengelige på Spanner-siden i Google-konsollen. Mer detaljerte visninger er tilgjengelige via Stackdriver, hvor du også kan angi metriske terskler og varslingspolicyer.
Tilgang til ressurser?
MySQL tilbyr omfattende og svært detaljerte brukertillatelser/rolleinnstillinger. Du kan enkelt tilpasse tilgangen til en bestemt tabell, eller til og med bare en undergruppe av kolonnene. Cloud Spanner bruker verktøyet Google Identity & Access Management (IAM), som bare lar deg angi retningslinjer og tillatelser på et veldig høyt nivå. Det mest detaljerte alternativet er tillatelse på databasenivå, som ikke passer i de fleste produksjonstilfeller. Denne begrensningen tvinger deg til å legge til ytterligere sikkerhetstiltak til koden, infrastrukturen eller begge deler for å forhindre uautorisert bruk av Spanner-ressurser.
Sikkerhetskopier?
For å si det enkelt, det er ingen sikkerhetskopier i Cloud Spanner. Mens Googles høye SLA-krav kan sikre at du ikke mister data på grunn av maskinvare- eller databasefeil, menneskelige feil, applikasjonsfeil osv. Vi kjenner alle regelen: høy tilgjengelighet er ingen erstatning for en smart sikkerhetskopieringsstrategi. Foreløpig er den eneste måten å sikkerhetskopiere data på å programmatisk streame dem fra databasen til et separat lagringsmiljø.
Spørre ytelse?
Vi brukte Yahoo! til å laste inn data og teste forespørsler. Cloud Serving Benchmark. Tabellen nedenfor viser B YCSB-arbeidsbelastningen med et 95 % lese- til 5 % skriveforhold.
* Lastetesten ble kjørt på n1-standard-32 Compute Engine (CE) (32 vCPUer, 120 GB minne) og testforekomsten var aldri flaskehalsen i testene.
** Maksimalt antall tråder i én YCSB-forekomst er 400. Totalt måtte seks parallelle forekomster av YCSB-tester kjøres for å få totalt 2400 tråder.
Ser vi på referanseresultatene, spesielt kombinasjonen av CPU-belastning og TPS, kan vi tydelig se at Cloud Spanner skalerer ganske bra. Den store belastningen som skapes av et stort antall tråder, oppveies av et stort antall noder i Cloud Spanner-klyngen. Selv om ventetiden ser ganske høy ut, spesielt når du kjører på 2400 tråder, kan det være nødvendig å teste på nytt med 6 mindre forekomster av beregningsmotoren for å få mer nøyaktige tall. Hver forekomst vil kjøre én YCSB-test i stedet for én stor CE-forekomst med 6 parallelle tester. Dette vil gjøre det lettere å skille mellom Cloud Spanner-forespørselsforsinkelser og forsinkelser lagt til av nettverksforbindelsen mellom Cloud Spanner og CE-forekomsten som kjører testen.
Hvordan fungerer Cloud Spanner som en OLAP?
Oppdeling?
Å dele data inn i fysisk og/eller logisk uavhengige segmenter, kalt partisjoner, er et veldig populært konsept som finnes i de fleste OLAP-motorer. Partisjoner kan i stor grad forbedre spørringsytelsen og databasevedlikeholdbarheten. Ytterligere dypdykk i partisjonering vil være en(e) egen(e) artikkel(er), så la oss bare nevne viktigheten av å ha et partisjoneringsskjema og underpartisjonering. Evnen til å dele data i partisjoner og enda lenger i underpartisjoner er nøkkelen til ytelsen til analytiske spørringer.
Cloud Spanner støtter ikke partisjoner i seg selv. Den skiller data internt i såkalte splittet-er basert på primærnøkkelområder. Partisjoneringen gjøres automatisk for å balansere belastningen på Cloud Spanner-klyngen. En veldig nyttig funksjon i Cloud Spanner er å dele grunnbelastningen til en overordnet tabell (en tabell som ikke er sammenflettet med en annen). Skiftnøkkel oppdager automatisk om den inneholder splittet data som leses oftere enn data i andre splittet-ah, og kan bestemme seg for en ytterligere separasjon. Dermed kan flere noder være involvert i en forespørsel, noe som også effektivt øker gjennomstrømningen.
Laster inn data?
Cloud Spanner-metoden for massedata er den samme som for en vanlig opplasting. For maksimal ytelse må du følge noen retningslinjer, inkludert:
- Sorter dataene dine etter primærnøkkel.
- Del dem med 10*antall noder individuelle seksjoner.
- Lag et sett med arbeidsoppgaver som laster data parallelt.
Denne datainnlastingen bruker alle Cloud Spanner-noder.
Vi brukte A YCSB-arbeidsmengden til å generere et 10M raddatasett.
* Belastningstesten ble kjørt på n1-standard-32-datamaskinen (32 vCPUer, 120 GB minne) og testforekomsten var aldri flaskehalsen i testene.
** Et 1 nodeoppsett anbefales ikke for noen produksjonsarbeidsbelastning.
Som nevnt ovenfor, behandler Cloud Spanner automatisk splittelser avhengig av belastningen, slik at resultatene forbedres etter flere påfølgende iterasjoner av testen. Resultatene som presenteres her er de beste resultatene vi har mottatt. Når vi ser på tallene ovenfor, kan vi se hvordan Cloud Spanner skalerer (vel) når antall noder i klyngen øker. Tallene som skiller seg ut er ekstremt lav gjennomsnittlig ventetid, som står i kontrast til resultater fra blandede arbeidsbelastninger (95 % lesing og 5 % skriving) som beskrevet i avsnittet ovenfor.
Skalering?
Å øke og redusere antall Cloud Spanner-noder er en oppgave med ett klikk. Hvis du vil laste data raskt, kan det være lurt å vurdere å øke forekomsten til det maksimale (i vårt tilfelle var det 25 noder i USA-ØST-regionen) og deretter redusere antall noder som passer for normal belastning etter alle dataene i databasen, og husk grensen på 2 TB/node.
Vi ble påminnet om denne grensen selv med en mye mindre database. Etter flere belastningstestkjøringer var databasen vår omtrent 155 GB stor, og når vi skalert ned til en nodeforekomst, fikk vi følgende feil:
Vi var i stand til å skalere ned fra 25 til 2 forekomster, men vi sitter fast på to noder.
Økning og reduksjon av antall noder i en Cloud Spanner-klynge kan automatiseres ved hjelp av REST API. Dette kan være spesielt nyttig for å redusere den økte belastningen på systemet i travle timer.
Ytelse for OLAP-søk?
Vi planla opprinnelig å bruke mye tid på vår evaluering av Spanner på denne delen. Etter noen SELECT COUNTs, innså vi umiddelbart at testen ville bli kort og at Spanner IKKE ville være en passende motor for OLAP. Uavhengig av antall noder i klyngen, tok det 10 til 55 sekunder å velge antall rader i en 60M radtabell. Alle spørringer som krevde mer minne for å lagre mellomresultater mislyktes med en OOM-feil.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Noen tall for TPC-H-spørringer finnes i Todd Lipcons artikkel , lysbilde 42 og 43. Disse tallene stemmer overens med våre egne resultater (dessverre).
4. Våre funn
Gitt den nåværende tilstanden til Cloud Spanners funksjoner, er det vanskelig å se det som en enkel erstatning for en eksisterende OLTP-løsning, spesielt når behovene dine vokser fra den. En betydelig mengde tid ville måtte brukes til å bygge en løsning rundt manglene til Cloud Spanner.
Da vi begynte å evaluere Cloud Spanner, forventet vi at administrasjonsfunksjonene var på nivå med, eller i det minste ikke langt unna, andre Google SQL-løsninger. Men vi ble overrasket over den fullstendige mangelen på sikkerhetskopier og svært begrenset tilgangskontroll til ressurser. For ikke å nevne ingen visninger, ingen lokalt utviklingsmiljø, ikke-støttede sekvenser, JDBC uten DML- og DDL-støtte, og så videre.
Så, hvor skal du gå for noen som trenger å skalere en transaksjonsdatabase? Det ser ikke ut til å være en eneste løsning på markedet ennå som passer alle brukstilfeller. Det finnes mange lukkede og åpen kildekode-løsninger (hvorav noen er nevnt i denne artikkelen), hver med sine egne styrker og svakheter, men ingen av dem tilbyr SaaS med 99,999 % SLA og høy grad av konsistens. Hvis en høy SLA er hovedmålet ditt og du ikke er tilbøyelig til å bygge din egen løsning for flere skyer, kan Cloud Spanner være løsningen du leter etter. Men du bør være klar over alle dens begrensninger.
For å være rettferdig, ble Cloud Spanner først utgitt til offentligheten våren 2017, så det er rimelig å forvente at noen av de nåværende feilene til slutt kan forsvinne (forhåpentligvis), og når den gjør det, kan det være en game-changer. Tross alt er Cloud Spanner ikke bare et sideprosjekt for Google. Google bruker det som grunnlag for andre Google-produkter. Og da Google nylig erstattet Megastore i Google Cloud Storage med Cloud Spanner, tillot det Google Cloud Storage å bli svært konsistent for objektlister på global skala (noe som fortsatt ikke er tilfelle for ).
Så, det er fortsatt håp... håper vi.
Det er alt. I likhet med artikkelforfatteren fortsetter vi også å håpe, men hva synes du om dette? Skriv i kommentarfeltet
Vi inviterer alle til å besøke vår der vi vil fortelle deg i detalj om kurset fra OTUS.
Kilde: www.habr.com