Denne artikel dukkede først op i InfoWorld . Den er genoptrykt med tilladelse. © IDG Communications, Inc., 2020. Alle rettigheder forbeholdes Hvordan MariaDB opnår global skala med Xpand. Xpand er nu tilgængelig i MariaDB SkySQL og tilføjer distribueret SQL for skalerbarhed og elasticitet i skyen.
Efterhånden som informations- og behandlingsbehovene er vokset, har smertepunkter som ydeevne og robusthed nødvendiggjort nye løsninger. Databaser skal opretholde ACID-overholdelse og konsistens, give høj tilgængelighed og høj ydeevne og håndtere massive arbejdsbelastninger uden at blive et ressourceforbrug. Sharding har tilbudt en løsning, men for mange virksomheder har sharding nået sine grænser på grund af dets kompleksitet og ressourcekrav. En bedre løsning er distribueret SQL.
I en distribueret SQL-implementering er databasen fordelt på tværs af flere fysiske systemer, der leverer transaktioner på et globalt skalerbart niveau. MariaDB Platform X5, en stor udgivelse, der inkluderer opgraderinger til alle aspekter af MariaDB Platform, giver distribueret SQL og massiv skalerbarhed gennem tilføjelsen af en ny smart storage-motor kaldet Xpand. Med en delt ingenting-arkitektur, fuldt distribuerede ACID-transaktioner og stærk konsistens giver Xpand dig mulighed for at skalere til millioner af transaktioner pr. sekund.
Optimerede pluggbare smarte motorer
MariaDB Enterprise Server er designet til at bruge pluggbare lagermotorer (som Xpand) til at optimere til bestemte arbejdsbelastninger fra en enkelt platform. Der er ikke behov for specialiserede databaser til at håndtere specifikke arbejdsbelastninger. MariaDB Xpand, vores smarte motor til distribueret SQL, er den seneste tilføjelse til vores lineup. Xpand tilføjer massivt skalerbare distribuerede transaktionsmuligheder til mulighederne fra vores andre motorer. Vores andre pluggbare motorer giver optimering til analytiske (kolonne), læsetunge arbejdsbelastninger og skrivetunge arbejdsbelastninger. Du kan blande og matche replikerede, distribuerede og søjleformede tabeller for at optimere hver database til dine specifikke krav.
Tilføjelse af MariaDB Xpand gør det muligt for virksomhedskunder at opnå alle fordelene ved distribueret SQL – hastighed, tilgængelighed og skalerbarhed – samtidig med at de bibeholder de MariaDB-fordele, de er vant til.
Lad os tage et kig på højt niveau på, hvordan MariaDB Xpand leverer distribueret SQL.
Distribueret SQL ned til indekserne
Xpand leverer distribueret SQL ved at opdele, replikere og distribuere data på tværs af noder. Hvad betyder det? Vi vil bruge et meget simpelt eksempel med en tabel og tre noder til at demonstrere koncepterne. Ikke vist i dette eksempel er, at alle skiver er replikeret.
I figur 1 ovenfor har vi en tabel med to indekser. Tabellen har nogle datoer, og vi har et indeks på kolonne 2, og en anden på kolonne 3 og 1. Indekser er på en måde selv tabeller. De er undergrupper af tabellen. Den primære nøgle er id , det første indeks i tabellen. Det er det, der vil blive brugt til at hash og sprede tabeldataene rundt i databasen.
Nu tilføjer vi begrebet udsnit . Skiver er i det væsentlige vandrette skillevægge af bordet. Vi har fem rækker i vores tabel. I figur 2 er bordet blevet skåret i skiver og fordelt. Node #1 har to rækker. Node #2 har to rækker, og Node #3 har en række. Målet er at få dataene fordelt så jævnt som muligt på tværs af noderne.
indekserne er også blevet skåret i skiver og fordelt. Dette er en vigtig forskel mellem Xpand og andre distribuerede løsninger. Normalt har distribuerede databaser lokale indekser, så hver node har et indeks over sine egne data. I Xpand distribueres og gemmes indekser uafhængigt af tabellen. Dette eliminerer behovet for at sende en forespørgsel til alle noder (scatter/samler). I eksemplet ovenfor indeholder Node #1 række 2 og 4 i tabellen, og indeholder også indekser for række 32 og 35 og rækker april og marts. Tabellen og indekserne opdeles uafhængigt, distribueres og replikeres på tværs af noderne.
Forespørgselsmotoren bruger de distribuerede indekser til at bestemme, hvor dataene skal findes. Den slår kun de nødvendige indekspartitioner op og sender derefter kun forespørgsler til de steder, hvor de nødvendige data findes. Forespørgsler er alle distribueret. De udføres sideløbende og parallelt. Hvor de går hen afhænger helt af dataene og hvad der er nødvendigt for at løse forespørgslen.
Alle skiver replikeres mindst to gange. For hvert udsnit er der replikaer på andre noder. Som standard vil der være tre kopier af disse data - udsnittet og to replikaer. Hver kopi vil være på en anden node, og hvis du kørte i flere tilgængelighedszoner, ville disse kopier også sidde i forskellige tilgængelighedszoner.
Læse- og skrivehåndtering
Lad os tage et andet eksempel. I figur 3 har vi fem forekomster af MariaDB Enterprise Server med Xpand (noder). Der er en tabel til at gemme kundeprofiler. Udsnittet med Shanes profil er på Node #1 med kopier på Node #3 og Node #5. Forespørgsler kan komme ind på enhver node og vil blive behandlet forskelligt afhængigt af, om de er læst eller skrevet.
Der skrives til alle kopier synkront inde i en distribueret transaktion. Hver gang jeg opdaterer min "Shane"-profil, fordi jeg har ændret min e-mail, eller jeg har ændret min adresse, går disse skrifter til alle kopier på samme tid i en transaktion. Det er det, der giver stærk konsistens.
I figur 3 gik UPDATE-sætningen til node #2. Der er intet på Node #2 vedrørende min profil, men Node #2 ved, hvor min profil er og sender opdateringer til Node #1, Node #3 og Node #5, forpligter derefter transaktionen og vender tilbage til applikationen.
Aflæsninger håndteres forskelligt. I diagrammet er udsnittet med min profil på node #1 med kopier på node #3 og node #5. Dette gør Node #1 til den rangerende replika. Hver skive har en rangerende replika, som kan siges at være den node, der "ejer" dataene. Som standard, uanset hvilken node en læsning kommer ind på, går den altid til rangeringsreplikaen, så hver SELECT, der løses for mig, vil gå til node #1.
Giver elasticitet
Distribuerede databaser som Xpand ændrer sig og udvikler sig løbende afhængigt af dataene i applikationen. Rebalancer-processen er ansvarlig for at tilpasse datafordelingen til aktuelle behov og opretholde den optimale fordeling af skiver på tværs af noder. Der er tre generelle scenarier, der kræver omfordeling:tilføjelse af noder, fjernelse af noder og forebyggelse af ujævne arbejdsbelastninger eller "hot spots".
Lad os f.eks. sige, at vi kører med tre knudepunkter, men opdager, at trafikken er stigende, og vi er nødt til at skalere - vi tilføjer en fjerde knude for at håndtere trafikken. Node #4 er tom, når vi tilføjer den som vist i figur 4. Rebalanceren flytter automatisk skiver og replikaer for at gøre brug af node #4, som vist i figur 5.
Hvis Node #4 skulle fejle, går rebalanceren automatisk i gang igen; denne gang genskaber skiver fra deres replikaer. Ingen data går tabt. Replikaer er også genskabt for at erstatte dem, der var bosat på node #4, så alle udsnit igen har replikaer på andre noder for at sikre høj tilgængelighed.
Figur 6. Hvis en node fejler, genskaber Xpand-rebalanceren udsnittene og replikaerne, der befandt sig på den mislykkede node, fra replikadataene på de andre noder.
Afbalancering af arbejdsbyrden
Ud over udskalering og høj tilgængelighed afbøder rebalanceren ulige fordeling af arbejdsbyrden – enten hot spots eller underudnyttelse. Selv når data er tilfældigt fordelt med en perfekt hash-algoritme, kan der opstå hot spots. For eksempel kan det ske ved en tilfældighed, at de 10 produkter på udsalg i denne måned tilfældigvis sidder på Node #1. Dataene er jævnt fordelt, men arbejdsbyrden er det ikke (figur 7). I denne type scenarie vil rebalanceren omfordele skiver for at balancere ressourceudnyttelsen (figur 8).
Figur 7. Xpand har jævnt fordelt dataene, men arbejdsbelastningen er ujævn. Node 1 har en væsentlig højere arbejdsbelastning end de tre andre noder.
Figur 8. Xpand rebalancer omfordeler dataudsnit for at balancere arbejdsbyrden på tværs af noder.
Skalerbarhed, hastighed, tilgængelighed, balance
Behovet for information og behandling vil fortsætte med at vokse. Det er givet. MariaDB Xpand leverer en konsistent, ACID-kompatibel skaleringsløsning til virksomheder med krav, der ikke kan opfyldes med andre alternativer som replikering og sharding.
Distribueret SQL giver skalerbarhed, og MariaDB Xpand giver fleksibiliteten til at vælge, hvor meget skalerbarhed du har brug for. Fordel en tabel eller flere tabeller eller endda hele din database, valget er dit. Driftsmæssigt kan kapaciteten nemt justeres for at imødekomme skiftende arbejdsbelastningskrav til enhver tid. Du behøver aldrig at være overprovisioneret.
Xpand beskytter også gennemsigtigt mod ujævn ressourceudnyttelse, og omdistribuerer data dynamisk for at balancere arbejdsbyrden på tværs af noder og forhindre hot spots. For udviklere er der ingen grund til at bekymre sig om skalerbarhed og ydeevne. Xpand er elastisk. Xpand giver også redundans og høj tilgængelighed. Med data opdelt, replikeret og distribueret på tværs af noder, er data beskyttet, og redundans opretholdes i tilfælde af hardwarefejl.
Og med MariaDB's arkitektur vil dine distribuerede borde spille pænt - inklusive cross-engine JOINs - med dine andre MariaDB-borde. Skab den databaseløsning, du har brug for, ved at blande og matche replikerede, distribuerede eller søjleformede tabeller på en enkelt database på MariaDB Platform.