Database-sharding og replikering

Etter hvert som applikasjoner vokser, kan én enkelt database bli en flaskehals. Høy trafikk, komplekse spørringer eller store datamengder kan redusere ytelsen.

For å håndtere økende belastning og sikre god respons må databaser skaleres. Denne leksjonen tar for seg to sentrale teknikker: replikering og sharding.

Databasereplikering er prosessen med å opprette og vedlikeholde flere kopier av en database.

Disse kopiene, ofte på ulike servere, har to hovedformål:

• Bedre lese-ytelse: Fordel leseforespørsler mellom flere kopier.
• Høy tilgjengelighet: Hvis én server svikter, kan en annen kopi ta over.

Den vanligste replikasjonsmodellen er Master-Slave. Slik fungerer den:

• Én databaseserver utpekes som master. Den håndterer alle skriveoperasjoner (innsettinger, oppdateringer og slettinger).
• De andre serverne er slaver. De mottar en kopi av masterens data og håndterer leseoperasjoner.
• Endringer fra masteren synkroniseres kontinuerlig til slavene.

Selv om Master-Slave er robust, gjør Multi-Master-replikering det mulig for flere databaseservere å ta imot skriveoperasjoner.

Dette kan gi enda bedre skalerbarhet og tilgjengelighet for skriving, men introduserer betydelig kompleksitet når datakonsistens skal håndteres og potensielle konflikter skal løses dersom de samme dataene oppdateres på ulike mastere samtidig.

Fordeler ved replikering:

• Skalerbar lesing: Fordeler lesebelastningen og forbedrer svartidene.
• Høy tilgjengelighet: Gir feiltoleranse; en slave kan bli master ved behov.
• Katastrofegjenoppretting: Datakopier er tilgjengelige hvis data går tapt på én server.

Ulemper:

• Skriveforsinkelse: All skriving går fortsatt gjennom masteren.
• Utdaterte data: Slavene kan ligge etter masteren, noe som fører til «eventuell konsistens».
• Kompleksitet: Oppsett og administrasjon krever grundig planlegging.

Databasesharding er en teknikk som deler en stor database opp i mindre og mer håndterbare deler kalt shards. Hver shard er en komplett, uavhengig database.

I stedet for én enorm database har De flere mindre databaser, som hver lagrer et delsett av de samlede dataene. Dette kalles også horisontal partisjonering.

Kjernen i sharding er shard-nøkkelen (eller partisjoneringsnøkkelen). Dette er en kolonne eller et sett med kolonner i dataene som avgjør hvilken shard en bestemt rad tilhører.

Det er avgjørende å velge en effektiv shard-nøkkel for å oppnå jevn datafordeling og effektive spørringer. Vanlige valg er user_id, tenant_id eller en geografisk region.

Hvordan avgjør vi hvilke data som skal ligge hvor?

• Områdebasert sharding: Data partisjoneres basert på et verdiområde i shard-nøkkelen (f.eks. brukere A–M på Shard 1 og N–Z på Shard 2).
• Hashbasert sharding: En hashfunksjon brukes på shard-nøkkelen, og resultatet avgjør hvilken shard som skal brukes. Dette gir ofte en jevnere fordeling.
• Katalogbasert sharding: En oppslagstabell (katalog) kobler shard-nøkkelen til riktig shard.

Selv om sharding gir svært gode skaleringsmuligheter, medfører det betydelige utfordringer:

• Økt kompleksitet: Flere databaser som skal administreres, distribueres og sikkerhetskopieres.
• Spørringer på tvers av shards: Spørringer som krever data fra flere shards, er komplekse og ofte mindre effektive.
• Rebalansering av data: Hvis én shard blir for stor eller overbelastet, er det krevende å omfordele data på tvers av shards (rebalansering).
• Valg av shard-nøkkel: En dårlig shard-nøkkel kan føre til ujevn fordeling («hot spots»).

Vi har sett på to kraftige teknikker for databaseskalering:

• Replikering: Oppretter kopier av data for skalerbar lesing og høy tilgjengelighet, ofte ved hjelp av en Master-Slave-modell.
• Sharding: Partisjonerer data horisontalt i uavhengige shards og bruker en shard-nøkkel til å fordele data og skalere skriveoperasjoner.

Begge teknikkene forbedrer ytelse og robusthet betydelig, men introduserer operasjonell kompleksitet. Valg av riktig strategi avhenger av de spesifikke behovene og trafikkmønstrene i applikasjonen.