Hej alla invånare i Khabrovsk. Som vanligt fortsätter vi att dela med oss av intressant material inför start av nya kurser. Idag, speciellt för dig, har vi publicerat en artikel om Google Cloud Spanner för att sammanfalla med lanseringen av kursen .
Ursprungligen publicerad i .
Som ett företag som erbjuder en mängd olika molnbaserade POS-lösningar till återförsäljare, krögare och onlineförsäljare runt om i världen, använder Lightspeed flera olika typer av databasplattformar för en mängd olika transaktions-, analytiska och sökanvändningsfall. Var och en av dessa databasplattformar har sina egna styrkor och svagheter. Därför, när Google introducerade Cloud Spanner på marknaden - lovande funktioner osynliga i världen av relationsdatabaser, som praktiskt taget obegränsad horisontell skalbarhet och ett 99,999 % servicenivåavtal (SLA), — vi kunde inte missa möjligheten att lägga vantarna på det!
För att ge en heltäckande översikt över vår erfarenhet av Cloud Spanner, såväl som de utvärderingskriterier vi använde, kommer vi att täcka följande ämnen:
- Våra utvärderingskriterier
- Cloud Spanner i ett nötskal
- Vår bedömning
- Våra resultat
1. Våra utvärderingskriterier
Innan vi dyker in i detaljerna för Cloud Spanner, dess likheter och skillnader med andra lösningar på marknaden, låt oss först prata om de viktigaste användningsfallen vi hade i åtanke när vi övervägde var vi skulle distribuera Cloud Spanner i vår infrastruktur:
- Som en ersättning för den (dominerande) traditionella SQL-databaslösningen
- Hur man OLTP-lösning med OLAP-stöd
Notera: För enkelhetens skull och för enkel jämförelse jämför denna artikel Cloud Spanner med MySQL-varianterna av GCP Cloud SQL och Amazon AWS RDS-lösningsfamiljerna.
Använder Cloud Spanner som en ersättning för en traditionell SQL-databaslösning
I miljön traditionella databaser, när svarstiden för databasfrågan närmar sig eller till och med överskrider fördefinierade tillämpningströsklar (främst på grund av en ökning av antalet användare och/eller förfrågningar), finns det flera sätt att minska svarstiden till acceptabla nivåer. De flesta av dessa lösningar innebär dock manuella ingrepp.
Till exempel, det första steget att ta är att titta på de olika prestationsrelaterade databasparametrarna och ställa in dem så att de bäst matchar tillämpningsmönster. Om detta inte räcker kan du välja att skala databasen vertikalt eller horisontellt.
Vertikal skalning av en applikation innebär att man uppgraderar serverinstansen, vanligtvis genom att lägga till fler processorer/kärnor, mer RAM, snabbare lagring, etc. Att lägga till fler hårdvaruresurser resulterar i ökad databasprestanda, mätt främst i transaktioner i sekunden, och transaktionslatens för OLTP-system. Relationella databassystem (som använder ett flertrådigt tillvägagångssätt) som MySQL skalar väl vertikalt.
Det finns flera nackdelar med detta tillvägagångssätt, men den mest uppenbara är den maximala serverstorleken på marknaden. När gränsen för den största serverinstansen har nåtts finns det bara ett alternativ kvar: horisontell skalning.
Horisontell skalning är ett tillvägagångssätt där fler servrar läggs till i ett kluster, vilket idealiskt ökar prestandan linjärt när antalet servrar läggs till. Majoritet traditionella Databassystem skalas inte horisontellt bra eller skalas inte alls. Till exempel kan MySQL skala horisontellt för läsoperationer genom att lägga till slavläsare, men kan inte skala horisontellt för skrivning.
Å andra sidan, på grund av sin natur, kan Cloud Spanner enkelt skala horisontellt med minimala ingrepp.
Fullt utrustad DBMS som en tjänst måste bedömas från olika vinklar. Som grund tog vi den mest populära DBMS i molnet - för Google, GCP Cloud SQL och för Amazon, AWS RDS. I vår bedömning fokuserade vi på följande kategorier:
- Funktionsmappning: omfattning SQL, DDL, DML; anslutningsbibliotek/anslutningar, transaktionsstöd och så vidare.
- Utvecklingsstöd: enkel utveckling och testning.
- Administrationsstöd: instanshantering - till exempel skala upp/ned och uppgradera instanser; SLA, säkerhetskopiering och återställning; säkerhet/tillträdeskontroll.
Använder Cloud Spanner som en OLAP-aktiverad OLTP-lösning
Även om Google inte uttryckligen hävdar att Cloud Spanner är designad för analytisk bearbetning, delar den vissa attribut med andra motorer som Apache Impala & Kudu och YugaByte, som är designade för OLAP-arbetsbelastningar.
Även om det bara fanns en liten chans att Cloud Spanner inkluderade en konsekvent utskalad HTAP-motor (hybrid transaktions-/analytisk bearbetning) med en (mer eller mindre) användbar OLAP-funktionsuppsättning, tycker vi att den skulle vara värd vår uppmärksamhet.
Med detta i åtanke tittade vi på följande kategorier:
- Dataladdning, index och partitioneringsstöd
- Query Performance och DML
2. Cloud Spanner i ett nötskal
Google Spanner är ett klustrat relationsdatabashanteringssystem (RDBMS) som Google använder för flera av sina egna tjänster. Google gjorde det allmänt tillgängligt för Google Cloud Platform-användare i början av 2017.
Här är några av Cloud Spanner-attributen:
- Mycket konsekvent skalbart RDBMS-kluster: Använder maskinvarutidssynkronisering för att säkerställa datakonsistens.
- Transaktionsstöd för korstabeller: Transaktioner kan sträcka sig över flera tabeller - inte nödvändigtvis begränsade till en enda tabell (till skillnad från Apache HBase eller Apache Kudu).
- Primärnyckelbaserade tabeller: Alla tabeller måste ha en deklarerad primärnyckel (PC), som kan bestå av flera kolumner i tabellen. Tabelldata lagras i PC-ordning, vilket gör det mycket effektivt och snabbt för PC-sökning. Liksom andra PC-baserade system måste implementeringen modelleras med förutformade användningsfall i åtanke för att uppnås .
- Randiga tabeller: Tabeller kan ha fysiska beroenden av varandra. Rader i en underordnad tabell kan matchas mot rader i en överordnad tabell. Detta tillvägagångssätt påskyndar sökandet efter relationer som kan identifieras under datamodelleringsfasen, som att samlokalisera kunder och deras fakturor.
- Index: Cloud Spanner stöder sekundära index. Indexet består av de indexerade kolumnerna och alla PC-kolumner. Om så önskas kan indexet även innehålla andra icke-indexerade kolumner. Indexet kan interfolieras med den överordnade tabellen för att påskynda frågor. Flera begränsningar gäller för index, till exempel det maximala antalet ytterligare kolumner som lagras i indexet. Dessutom kanske frågor genom index inte är lika enkla som i andra RDBMS.
"Cloud Spanner väljer ett index automatiskt endast i sällsynta fall. I synnerhet väljer Cloud Spanner inte automatiskt ett sekundärt index om en fråga begär några kolumner som inte är lagrade i ".
- Service Level Agreement (SLA): Implementering i en region med en SLA på 99,99 %; multiregionala distributioner med 99,999 % SLA. Även om SLA i sig bara är ett avtal och inte en garanti av något slag, tror jag att folket på Google har några svåra uppgifter att göra ett så starkt påstående. (För referens betyder 99,999 % 26,3 sekunders otillgänglighet per månad.)
- mer:
Notera: Apache Tephra-projektet lägger till utökat transaktionsstöd till Apache HBase (nu också implementerat i Apache Phoenix som beta).
3. Vår bedömning
Så vi har alla läst Googles påståenden om fördelarna med Cloud Spanner - praktiskt taget obegränsad horisontell skalning samtidigt som den bibehåller hög konsistens och en mycket hög SLA. Även om dessa krav i alla fall är extremt svåra att uppnå, var vårt mål inte att motbevisa dem. Låt oss istället fokusera på andra saker som de flesta databasanvändare bryr sig om: paritet och användbarhet.
Vi utvärderade Cloud Spanner som en ersättning för Sharded MySQL
Google Cloud SQL och Amazon AWS RDS, två av de mest populära OLTP DBMS:erna på molnmarknaden, har en mycket stor uppsättning funktioner. Men för att skala dessa databaser utöver storleken på en enda nod måste du utföra programpartitionering. Detta tillvägagångssätt skapar ytterligare komplexitet för både applikationer och administration. Vi tittade på hur Spanner passar in i scenariot att kombinera flera skärvor till en enda instans och vilka funktioner (om några) som kan behöva offras.
SQL, DML och DDL-stöd, samt kopplingar och bibliotek?
Först, när du börjar med vilken databas som helst, måste du skapa en datamodell. Om du tror att du kan ansluta JDBC Spanner till ditt favorit SQL-verktyg, kommer du att upptäcka att du kan fråga efter dina data med det, men du kan inte använda det för att skapa en tabell eller ändra (DDL) eller någon infoga/uppdatera/ta bort operationer (DML). Googles officiella JDBC stöder inte någon av dessa.
"Drivrutiner stöder för närvarande inte DML- eller DDL-satser."
Nyckeldokumentation
Situationen är inte bättre med GCP-konsolen - du kan bara 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 den här drivrutinen är extremt användbar, är avsaknaden av Googles egen JDBC-drivrutin förvånande. Lyckligtvis erbjuder Google ganska brett stöd för klientbibliotek (baserat på gRPC): C#, Go, Java, node.js, PHP, Python och Ruby.
Den nästan obligatoriska användningen av Cloud Spanner anpassade API:er (på grund av bristen på DDL och DML i JDBC) resulterar i vissa begränsningar för relaterade kodområden som anslutningspooler eller databasbindningsramverk (t.ex. Spring MVC). Vanligtvis när du använder JDBC är du fri att välja din favoritanslutningspool (t.ex. HikariCP, DBCP, C3PO, etc.) som är testad och fungerar bra. När det gäller anpassade Spanner API:er måste vi förlita oss på ramverk/bindande pooler/sessioner som vi har skapat själva.
Den primära nyckeln (PC)-centrerad design gör att Cloud Spanner kan vara mycket snabb när du kommer åt data via PC, men introducerar också vissa frågeproblem.
- Du kan inte uppdatera det primära nyckelvärdet. Du måste först ta bort posten från den ursprungliga datorn och sätta in den igen med det nya värdet. (Detta liknar andra PC-orienterade databas-/lagringsmotorer.)
- Alla UPDATE- och DELETE-satser måste ange PC i WHERE, därför kan det inte vara tomma DELETE alla satser - det måste alltid finnas en underfråga, till exempel: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Brist på alternativ för automatisk ökning eller något liknande som anger sekvensen för PC-fältet. För att detta ska fungera måste motsvarande värde skapas på applikationssidan.
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 tekniker. Apache Kudu stöder för närvarande inte sekundära index alls, och Apache HBase stöder inte index direkt, men kan lägga till dem genom Apache Phoenix.
Index i Kudu och HBase kan modelleras som en separat tabell med en annan sammansättning av primärnycklar, men atomiciteten för de operationer som utförs på den överordnade tabellen och tillhörande indextabeller måste göras på applikationsnivå och är inte trivialt att implementera korrekt.
Som nämnts i Cloud Spanner-recensionen kan dess index skilja sig från MySQL:s index. Därför bör särskild försiktighet iakttas vid konstruktion av frågor och profilering för att säkerställa att rätt index används där det behövs.
Representation?
Ett mycket populärt och användbart objekt i en databas är vyer. De kan vara användbara för ett stort antal användningsfall; mina två favoriter är det logiska abstraktionsskiktet och säkerhetsskiktet. Tyvärr stöder Cloud Spanner INTE vyer. Detta begränsar oss dock bara delvis eftersom det inte finns någon granularitet för åtkomstbehörigheter på kolumnnivå där vyer kan vara en genomförbar lösning.
Se Cloud Spanner-dokumentationen för ett avsnitt som beskriver kvoter och begränsningar (), finns det en i synnerhet som kan vara problematisk för vissa applikationer: Cloud Spanner out of the box har en gräns på maximalt 100 databaser per instans. Uppenbarligen kan detta vara en stor flaskhals för en databas som är designad för att skalas till över 100 databaser. Lyckligtvis, efter att ha pratat med vår tekniska representant för Google, fick vi reda på att denna gräns kan höjas till nästan vilket värde som helst genom Googles support.
Utvecklingsstöd?
Cloud Spanner erbjuder ganska anständigt programmeringsspråksstöd för att arbeta med sitt API. Officiellt stödda bibliotek finns inom områdena C#, Go, Java, node.js, PHP, Python och Ruby. Dokumentationen är ganska detaljerad, men som med andra avancerade teknologier är communityn ganska liten jämfört med de mest populära databasteknikerna, vilket kan leda till att mer tid spenderas på att lösa mindre vanliga användningsfall eller problem.
Så hur är det med att stödja lokal utveckling?
Vi har inte hittat något sätt att skapa en Cloud Spanner-instans på plats. Det närmaste vi kom var en Docker-bild. , som är lika i princip, men väldigt olika i praktiken. Till exempel kan CockroachDB använda PostgreSQL JDBC. Eftersom utvecklingsmiljön ska ligga så nära produktionsmiljön som möjligt är Cloud Spanner inte idealiskt eftersom det måste förlita sig på en fullständig Spanner-instans. För att spara kostnader kan du välja en enregionsinstans.
Administrationsstöd?
Att skapa en Cloud Spanner-instans är väldigt enkelt. Du behöver bara välja mellan att skapa en multiregion- eller enregionsinstans, ange region(er) och antalet noder. Om mindre än en minut kommer din instans att vara igång.
Flera rudimentära mätvärden är direkt tillgängliga från sidan Nyckel i Google Console. Mer detaljerade vyer är tillgängliga via Stackdriver, där du också kan ställa in metriska trösklar och varningspolicyer.
Tillgång till resurser?
MySQL erbjuder omfattande och mycket detaljerade inställningar för användarbehörigheter/roller. Du kan enkelt konfigurera åtkomst till en specifik tabell, eller till och med bara en delmängd av dess kolumner. Cloud Spanner använder Googles verktyg för Identity & Access Management (IAM), som bara låter dig ställa in policyer och behörigheter på en mycket hög nivå. Det mest detaljerade alternativet är upplösning på databasnivå, som inte passar in i de flesta produktionsanvändningsfall. Denna begränsning tvingar dig att lägga till ytterligare säkerhetsåtgärder till din kod, infrastruktur eller båda för att förhindra obehörig användning av Spanner-resurser.
Säkerhetskopieringar?
För att uttrycka det enkelt, det finns inga säkerhetskopior i Cloud Spanner. Även om Googles höga SLA-krav kan säkerställa att du inte förlorar någon data på grund av maskinvaru- eller databasfel, mänskliga fel, applikationsdefekter, etc. Vi känner alla till regeln: hög tillgänglighet är inte en ersättning för en sund säkerhetskopieringsstrategi. För närvarande är det enda sättet att säkerhetskopiera data att programmera streama den från en databas till en separat lagringsmiljö.
Fråga prestanda?
Vi använde Yahoo! för att ladda data och testa frågor. Molnserving Benchmark. Tabellen nedan visar YCSB-arbetsbelastning B med 95 % läs till 5 % skrivförhållande.
* Belastningstestet kördes på n1-standard-32 Compute Engine (CE) (32 vCPU, 120 GB minne), och testinstansen var aldrig en flaskhals i testerna.
** Det maximala antalet trådar i en enda YCSB-instans är 400. Totalt sex parallella instanser av YCSB-tester måste köras för att få totalt 2400 trådar.
Om vi tittar på benchmarkresultaten, särskilt kombinationen av CPU-belastning och TPS, kan vi tydligt se att Cloud Spanner skalar ganska bra. Den tunga belastningen som skapas av det stora antalet trådar kompenseras av det stora antalet noder i Cloud Spanner-klustret. Även om latensen ser ganska hög ut, särskilt när man kör med 2400 trådar, kan det vara nödvändigt att testa om 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 skilja mellan Cloud Spanner-förfråganslatens och latens som lagts till av nätverksanslutningen mellan Cloud Spanner och CE-instansen som kör testet.
Hur fungerar Cloud Spanner som en OLAP?
Partitionering?
Att dela upp data i fysiskt och/eller logiskt oberoende segment, så kallade partitioner, är ett mycket populärt koncept som finns i de flesta OLAP-motorer. Partitioner kan avsevärt förbättra frågeprestanda och databasunderhållbarhet. Att gå djupare in på partitionering skulle vara en separat artikel, så låt oss bara nämna vikten av att ha ett partitionerings- och underpartitioneringsschema. Möjligheten att dela upp data i partitioner och ännu längre i underpartitioner är nyckeln till analytisk frågeprestanda.
Cloud Spanner stöder inte partitioner som sådana. Den delar upp datan internt i sk delas-s baserat på primära nyckelområden. Partitionering utförs automatiskt för att balansera belastningen i ett Cloud Spanner-kluster. En mycket användbar funktion i Cloud Spanner är uppdelningen av den överordnade tabellens basbelastning (en tabell som inte är interfolierad med en annan). Nyckel känner automatiskt av om den innehåller delas data som läses oftare än data i andra delas-ah, och kan besluta om ytterligare separation. På så sätt kan fler noder involveras i en begäran, vilket också effektivt ökar genomströmningen.
Laddar data?
Cloud Spanner-metoden för massdata är densamma som för normal laddning. För att uppnå maximal prestanda måste du följa några riktlinjer, inklusive:
- Sortera dina data efter primärnyckel.
- Dividera dem med 10*antal noder separata avsnitt.
- Skapa en uppsättning arbetsuppgifter som laddar data parallellt.
Denna dataladdning använder alla Cloud Spanner-noder.
Vi använde YCSB arbetsbelastning A för att generera en datauppsättning med 10 miljoner rader.
* Belastningstestet kördes på n1-standard-32-beräkningsmotorn (32 vCPU, 120 GB minne), och testinstansen var aldrig en flaskhals i testerna.
**Inställning av en nod rekommenderas inte för någon produktionsbelastning.
Som nämnts ovan, bearbetar Cloud Spanner automatiskt delningar baserat på deras belastning, så resultaten förbättras efter flera på varandra följande testrepetitioner. Resultaten som presenteras här är de bästa resultaten vi fått. Om vi tittar på siffrorna ovan kan vi se hur Cloud Spanner skalar (bra) när antalet noder i klustret ökar. Siffrorna som sticker ut är de extremt låga genomsnittliga latenserna, som står i kontrast till resultaten för blandade arbetsbelastningar (95 % läser och 5 % skriver) som beskrivs i avsnittet ovan.
Skalning?
Att öka och minska antalet Cloud Spanner-noder är en uppgift med ett klick. Om du vill ladda data snabbt kan du överväga att öka din instans till det maximala (i vårt fall var det 25 noder i USA-ÖST-regionen) och sedan minska antalet noder som är kvalificerade för din normala belastning när all data är i databasen , med hänvisning till 2TB/nodgränsen.
Vi blev påminda om denna gräns även med en mycket mindre databas. Efter flera körningar av belastningstester var vår databas cirka 155 GB stor, och när vi skalade ner till en nodinstans fick vi följande fel:
Vi lyckades skala ner från 25 till 2 instanser, men vi satt fast vid två noder.
Att öka och minska antalet noder i ett Cloud Spanner-kluster kan automatiseras med REST API. Detta kan vara särskilt användbart för att minska ökad systembelastning under hektisk arbetstid.
Prestanda för OLAP-frågor?
Vi planerade ursprungligen att spendera en betydande tid i vår utvärdering av Spanner på denna del. Efter flera SELECT COUNTs insåg vi direkt att testningen skulle bli kort och att Spanner INTE skulle vara en lämplig motor för OLAP. Oavsett antalet noder i klustret tog det mellan 10 och 55 sekunder att helt enkelt välja antalet rader i en 60M radtabell. Dessutom misslyckades varje fråga som krävde mer minne för att lagra mellanliggande resultat med ett OOM-fel.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
Vissa siffror för TPC-H-frågor finns i Todd Lipcons artikel , bild 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 för Cloud Spanners funktioner är det svårt att föreställa sig att det är en enkel ersättning för din befintliga OLTP-lösning, särskilt när dina behov växer ifrån dem. En betydande mängd tid skulle behöva läggas på att bygga en lösning kring Cloud Spanners brister.
När vi började utvärdera Cloud Spanner förväntade vi oss att dess hanteringsfunktioner skulle vara i nivå med, eller åtminstone inte alltför långt ifrån, andra Google SQL-lösningar. Men vi blev förvånade över den totala bristen på säkerhetskopior och mycket begränsad kontroll över tillgången till resurser. För att inte tala om inga vyer, ingen lokal utvecklingsmiljö, sekvenser som inte stöds, JDBC utan DML- och DDL-stöd och så vidare.
Så vart tar någon som behöver skala en transaktionsdatabas vägen? Det verkar inte finnas en enda lösning på marknaden som passar alla användningsfall. Det finns många lösningar med stängd och öppen källkod (av vilka några nämns i den här artikeln), var och en med sina egna styrkor och svagheter, men ingen av dem erbjuder SaaS med 99,999 % SLA och hög konsistens. Om en hög SLA är ditt huvudmål och du inte är benägen att bygga en anpassad multimolnlösning, kan Cloud Spanner vara lösningen du letar efter. Men du bör vara medveten om alla dess begränsningar.
För att vara rättvis släpptes Cloud Spanner först till allmänheten under våren 2017, så det är rimligt att förvänta sig att några av dess nuvarande brister så småningom kan försvinna (förhoppningsvis), och när de gör det kan det vara en spelförändring. Cloud Spanner är trots allt inte bara ett sidoprojekt för Google. Google använder det som grund för andra Google-produkter. Och när Google nyligen ersatte Megastore i Google Cloud Storage med Cloud Spanner, gjorde det möjligt för Google Cloud Storage att bli mycket konsekvent för listor över objekt i global skala (vilket fortfarande inte är fallet för ).
Så, det finns fortfarande hopp... hoppas vi.
Det är allt. Liksom artikelförfattaren fortsätter vi också att hoppas, men vad tycker du om detta? Skriv i kommentarerna
Vi inbjuder alla att besöka vår där vi kommer att berätta i detalj om kursen från OTUS.
Källa: will.com