Databasshardning och replikering

När applikationer växer kan en enda databas bli en flaskhals. Hög trafik, komplexa frågor eller stora datamängder kan göra systemet långsammare.

För att hantera ökad belastning och säkerställa god respons behöver databaser skalas. Den här lektionen utforskar två viktiga tekniker: replikering och sharding.

Databasreplikering är processen att skapa och underhålla flera kopior av en databas.

Dessa kopior, som ofta finns på olika servrar, har två huvudsakliga syften:

• Förbättrad läsprestanda: Fördela läsförfrågningar mellan flera kopior.
• Hög tillgänglighet: Om en server slutar fungera kan en annan kopia ta över.

Den vanligaste replikeringsmodellen är Master-Slave. Så här fungerar den:

• En databasserver utses till master. Den hanterar alla skrivoperationer (infogningar, uppdateringar och borttagningar).
• Övriga servrar är slavar. De tar emot en kopia av masterns data och hanterar läsoperationer.
• Ändringar från mastern synkroniseras kontinuerligt till slavarna.

Även om Master-Slave är robust gör Multi-Master-replikering det möjligt för flera databasservrar att ta emot skrivoperationer.

Det kan ytterligare förbättra skalbarheten och tillgängligheten vid skrivningar, men innebär betydande komplexitet när datakonsistens ska hanteras och potentiella konflikter lösas om samma data uppdateras på olika masterservrar samtidigt.

Fördelar med replikering:

• Lässkalbarhet: Fördelar läsbelastningen och förbättrar svarstiderna.
• Hög tillgänglighet: Ger feltålighet; en slav kan bli master vid behov.
• Katastrofåterställning: Datakopior finns tillgängliga om data går förlorade på en server.

Nackdelar:

• Skrivfördröjning: Alla skrivningar går fortfarande via mastern.
• Inaktuella data: Slavarna kan släpa efter mastern, vilket leder till "eventual consistency".
• Komplexitet: Konfiguration och hantering kräver noggrann planering.

Databas-sharding är en teknik som delar upp en stor databas i mindre, mer lätthanterliga delar som kallas shards. Varje shard är en komplett, fristående databas.

I stället för en enda massiv databas har ni flera mindre databaser som var och en lagrar en delmängd av den totala datamängden. Detta kallas även horisontell partitionering.

Kärnan i sharding är shard-nyckeln (eller partitionsnyckeln). Det är en kolumn eller uppsättning kolumner i era data som avgör vilken shard en viss rad tillhör.

Det är mycket viktigt att välja en effektiv shard-nyckel för att fördela data jämnt och göra frågor effektiva. Vanliga val är user_id, tenant_id eller en geografisk region.

Hur avgör vi vilka data som ska hamna var?

• Intervallbaserad sharding: Data partitioneras utifrån ett värdeintervall i shard-nyckeln (till exempel användare A–M på Shard 1 och N–Ö på Shard 2).
• Hashbaserad sharding: En hashfunktion tillämpas på shard-nyckeln och resultatet avgör vilken shard som ska användas. Detta leder ofta till en jämnare fördelning.
• Katalogbaserad sharding: En uppslagstabell (katalog) mappar shard-nyckeln till rätt shard.

Sharding ger mycket god skalbarhet, men medför betydande utmaningar:

• Ökad komplexitet: Fler databaser att hantera, distribuera och säkerhetskopiera.
• Frågor över flera shards: Frågor som kräver data från flera shards är komplexa och ofta mindre effektiva.
• Ombalansering av data: Om en shard blir för stor eller överbelastad är det svårt att omfördela data mellan shards (ombalansera).
• Val av shard-nyckel: En olämplig shard-nyckel kan leda till en ojämn fördelning (”hot spots”).

Vi har gått igenom två kraftfulla tekniker för databasskalning:

• Replikering: Skapar kopior av data för skalbar läsning och hög tillgänglighet, ofta med en Master-Slave-modell.
• Sharding: Partitionerar data horisontellt i oberoende shards och använder en shard-nyckel för att distribuera data och skala skrivoperationer.

Båda teknikerna förbättrar prestanda och motståndskraft avsevärt, men ökar den operativa komplexiteten. Vilken strategi som är rätt beror på applikationens specifika behov och trafikmönster.