Den här artikeln dök upp först i InfoWorld . Den trycks om med tillstånd. © IDG Communications, Inc., 2020. Alla rättigheter reserverade Hur MariaDB uppnår global skala med Xpand. Xpand är nu tillgängligt i MariaDB SkySQL och lägger till distribuerad SQL för skalbarhet och elasticitet i molnet.
I takt med att informations- och bearbetningsbehoven har ökat, har smärtpunkter som prestanda och resiliens krävt nya lösningar. Databaser måste upprätthålla ACID-efterlevnad och konsistens, ge hög tillgänglighet och hög prestanda, och hantera massiva arbetsbelastningar utan att bli ett dränering på resurser. Sharding har erbjudit en lösning, men för många företag har skärningen nått sina gränser, på grund av dess komplexitet och resurskrav. En bättre lösning är distribuerad SQL.
I en distribuerad SQL-implementering distribueras databasen över flera fysiska system, och levererar transaktioner på en globalt skalbar nivå. MariaDB Platform X5, en stor utgåva som inkluderar uppgraderingar till alla aspekter av MariaDB Platform, ger distribuerad SQL och massiv skalbarhet genom tillägget av en ny smart lagringsmotor som heter Xpand. Med en delad ingenting-arkitektur, fullt distribuerade ACID-transaktioner och stark konsistens låter Xpand dig skala till miljontals transaktioner per sekund.
Optimerade pluggbara smarta motorer
MariaDB Enterprise Server är utformad för att använda pluggbara lagringsmotorer (som Xpand) för att optimera för särskilda arbetsbelastningar från en enda plattform. Det finns inget behov av specialiserade databaser för att hantera specifika arbetsbelastningar. MariaDB Xpand, vår smarta motor för distribuerad SQL, är det senaste tillskottet till vår lineup. Xpand lägger till massivt skalbara distribuerade transaktionsmöjligheter till alternativen som tillhandahålls av våra andra motorer. Våra andra pluggbara motorer ger optimering för analytiska (kolumnära), lästunga arbetsbelastningar och skrivtunga arbetsbelastningar. Du kan blanda och matcha replikerade, distribuerade och kolumnära tabeller för att optimera varje databas för dina specifika krav.
Genom att lägga till MariaDB Xpand kan företagskunder få alla fördelar med distribuerad SQL – hastighet, tillgänglighet och skalbarhet – samtidigt som de behåller MariaDB-fördelarna de är vana vid.
Låt oss ta en titt på hög nivå på hur MariaDB Xpand tillhandahåller distribuerad SQL.
Distribuerade SQL ner till indexen
Xpand tillhandahåller distribuerad SQL genom att dela upp, replikera och distribuera data över noder. Vad betyder det här? Vi kommer att använda ett mycket enkelt exempel med en tabell och tre noder för att demonstrera koncepten. Det som inte visas i det här exemplet är att alla skivor är replikerade.
I figur 1 ovan har vi en tabell med två index. Tabellen har några datum och vi har ett index på kolumn två, och ett annat på kolumn tre och ett. Index är på sätt och vis tabeller själva. De är delmängder av tabellen. Den primära nyckeln är id , det första indexet i tabellen. Det är vad som kommer att användas för att hasha och sprida tabelldata runt om i databasen.
Nu lägger vi till begreppet skivor . Skivor är i huvudsak horisontella partitioner av bordet. Vi har fem rader i vår tabell. I figur 2 har bordet skivats och fördelats. Nod #1 har två rader. Nod #2 har två rader och Nod #3 har en rad. Målet är att få data fördelade så jämnt som möjligt över noderna.
indexen har också skivats och distribuerats. Detta är en viktig skillnad mellan Xpand och andra distribuerade lösningar. Vanligtvis har distribuerade databaser lokala index, så varje nod har ett index med sina egna data. I Xpand distribueras och lagras index oberoende av tabellen. Detta eliminerar behovet av att skicka en fråga till alla noder (scatter/samla). I exemplet ovan innehåller Nod #1 raderna 2 och 4 i tabellen, och innehåller även index för raderna 32 och 35 och raderna april och mars. Tabellen och indexen delas upp, distribueras och replikeras oberoende av varandra över noderna.
Frågemotorn använder de distribuerade indexen för att avgöra var data ska hittas. Den letar bara upp de indexpartitioner som behövs och skickar sedan frågor endast till de platser där den nödvändiga informationen finns. Alla frågor distribueras. De görs samtidigt och parallellt. Vart de tar vägen beror helt på data och vad som behövs för att lösa frågan.
Alla skivor replikeras minst två gånger. För varje segment finns det repliker som finns på andra noder. Som standard kommer det att finnas tre kopior av den datan – segmentet och två repliker. Varje kopia kommer att finnas på en annan nod, och om du körde i flera tillgänglighetszoner, skulle dessa kopior också sitta i olika tillgänglighetszoner.
Läs- och skrivhantering
Låt oss ta ett annat exempel. I figur 3 har vi fem instanser av MariaDB Enterprise Server med Xpand (noder). Det finns en tabell för att lagra kundprofiler. Skivan med Shanes profil finns på nod #1 med kopior på nod #3 och nod #5. Frågor kan komma in på vilken nod som helst och kommer att bearbetas på olika sätt beroende på om de är läser eller skrivs.
Skrivningar görs till alla kopior synkront i en distribuerad transaktion. Varje gång jag uppdaterar min "Shane"-profil för att jag har ändrat min e-postadress eller ändrat min adress, går dessa skrivningar till alla kopior samtidigt i en transaktion. Det är detta som ger stark konsekvens.
I figur 3 gick UPDATE-satsen till nod #2. Det finns inget på nod #2 angående min profil men nod #2 vet var min profil är och skickar uppdateringar till nod #1, nod #3 och nod #5, begår sedan transaktionen och återgår till applikationen.
Avläsningar hanteras olika. I diagrammet är skivan med min profil på nod #1 med kopior på nod #3 och nod #5. Detta gör Node #1 till den rankade repliken. Varje skiva har en rankningsreplik, som kan sägas vara den nod som "äger" data. Som standard, oavsett vilken nod en läsning kommer in på, går den alltid till rankningsrepliken, så varje SELECT som löser sig för mig kommer att gå till Nod #1.
Ge elasticitet
Distribuerade databaser som Xpand förändras och utvecklas kontinuerligt beroende på data i applikationen. Ombalanseringsprocessen ansvarar för att anpassa datadistributionen till aktuella behov och upprätthålla den optimala fördelningen av skivor över noder. Det finns tre generella scenarier som kräver omfördelning:lägga till noder, ta bort noder och förhindra ojämn arbetsbelastning eller "hot spots".
Säg till exempel att vi kör med tre noder men upptäcker att trafiken ökar och vi behöver skala – vi lägger till en fjärde nod för att hantera trafiken. Nod #4 är tom när vi lägger till den som visas i figur 4. Rebalanseraren flyttar automatiskt skivor och repliker för att använda nod #4, som visas i figur 5.
Om Nod #4 skulle misslyckas, kommer rebalancern automatiskt att fungera igen; denna gång återskapa skivor från sina repliker. Ingen data går förlorad. Repliker återskapas också för att ersätta de som fanns på Nod #4, så alla skivor har återigen repliker på andra noder för att säkerställa hög tillgänglighet.
Figur 6. Om en nod misslyckas, återskapar Xpand rebalancer skivorna och replikerna som fanns på den misslyckade noden från replikdata på de andra noderna.
Balansera arbetsbelastningen
Förutom utskalning och hög tillgänglighet, mildrar rebalancern ojämn arbetsbelastningsfördelning – antingen hot spots eller underutnyttjande. Även när data distribueras slumpmässigt med en perfekt hashalgoritm kan hot spots uppstå. Till exempel kan det hända av en slump att de 10 produkterna på rea denna månad råkar vara på Nod #1. Datan är jämnt fördelad men arbetsbelastningen inte (Figur 7). I den här typen av scenario kommer rebalanseraren att omfördela skivor för att balansera resursutnyttjandet (Figur 8).
Figur 7. Xpand har fördelat data jämnt men arbetsbelastningen är ojämn. Nod 1 har en betydligt högre arbetsbelastning än de andra tre noderna.
Figur 8. Xpand rebalancer omfördelar datasegment för att balansera arbetsbelastningen över noder.
Skalbarhet, hastighet, tillgänglighet, balans
Informations- och bearbetningsbehoven kommer att fortsätta att växa. Det är givet. MariaDB Xpand tillhandahåller en konsekvent, ACID-kompatibel skalningslösning för företag med krav som inte kan uppfyllas med andra alternativ som replikering och skärning.
Distribuerad SQL ger skalbarhet, och MariaDB Xpand ger flexibiliteten att välja hur mycket skalbarhet du behöver. Fördela en tabell eller flera tabeller eller till och med hela din databas, valet är ditt. Operativt anpassas kapaciteten enkelt för att möta förändrade arbetsbelastningskrav vid varje given tidpunkt. Du behöver aldrig vara överprovisionerad.
Xpand skyddar också transparent mot ojämnt resursutnyttjande och omfördelar data dynamiskt för att balansera arbetsbelastningen över noder och förhindra hot spots. För utvecklare behöver du inte oroa dig för skalbarhet och prestanda. Xpand är elastisk. Xpand ger också redundans och hög tillgänglighet. Med data skivad, replikerad och distribuerad över noder skyddas data och redundans bibehålls i händelse av maskinvarufel.
Och med MariaDB:s arkitektur kommer dina distribuerade bord att spela bra – inklusive cross-engine JOINs – med dina andra MariaDB-bord. Skapa den databaslösning du behöver genom att blanda och matcha replikerade, distribuerade eller kolumnära tabeller på en enda databas på MariaDB Platform.