Skalerbarhet

Det er to vanlige tilnærminger til å skalere en server: vertikal skalering og horisontal skalering. Vertikal skalering eller oppskalering er hvor du legger til mer kraft og ressurser til serveren din, for eksempel flere CPUer, minne og lagring, noe som er kostbart. På den annen side er horisontal skalering å legge til flere noder til din eksisterende ressurspool. Dette kalles utskalering. Så, basert på dine begrensninger og krav, er det opp til deg å ha en enkelt større serverforekomst eller distribuere flere servernoder.

Anta at du har 100 GB RAM og trenger å holde 200 GB data. I dette tilfellet har du to valg:

• Skaler opp ved å legge til mer RAM til systemet
• Skaler ut ved å legge til en annen serverforekomst med 100 GB RAM

Hvis du har nådd den maksimale RAM-grensen i infrastrukturen din, er utskalering den ideelle tilnærmingen. I tillegg vil utskalering øke databasegjennomstrømningen med en enorm margin.

Redis Sharding

Det er et kjent faktum at Redis opererer på en enkelt tråd. Så Redis er ikke i stand til å bruke flere kjerner av serverens CPU for å behandle kommandoer. Derfor, å legge til flere CPU-kjerner gir deg ikke mye gjennomstrømning eller ytelse med Redis. Det er ikke tilfelle med å dele dataene dine mellom flere serverforekomster. Ved å legge til flere servere og distribuere datasettet mellom disse, kan behandlingen av klientforespørsler parallelt, noe som øker gjennomstrømningen. I tillegg kan den totale ytelsen øke nær lineært.

Denne tilnærmingen med å dele eller distribuere data mellom flere servere med skalering i tankene kalles skjæring . Alle serverne som lagrer deler av data kalles opp skår .

Hvordan skjæring gjøres - Algoritmisk skjæring

En av de største bekymringene med sharding var hvordan man kunne finne en gitt nøkkel blant flere Redis-noder. Fordi en gitt nøkkel kan lagres i alle tilgjengelige shards, er det ikke det beste alternativet å spørre alle shards for å finne en bestemt nøkkel. Så det bør være en måte å kartlegge hver nøkkel til et spesifikt shard, og Redis bruker en algoritmisk sharding-strategi.

Den vanligste tilnærmingen er å beregne en hash-verdi ved å bruke Redis-nøkkelnavnet og modulo. Deretter deler du den med de tilgjengelige Redis-skårene i systemet.

Det er en ganske god løsning så lenge det totale antallet skår er konstant. Hver gang du legger til en ny Reids-serverforekomst, kan den resulterende verdien for en gitt nøkkel endres siden det totale antallet shards har økt. Det vil ende opp med å spørre feil Redis-skjær. Derfor bør du følge omfordelingsprosessen ved å beregne den nye shard for hver nøkkel og overføre data til riktig server, noe som er tungvint og ikke en triviell oppgave hvis det totale shard-antallet øker fra tid til annen.

Redis bruker en ny logisk enhet kalt a hash-spor for å forhindre dette problemet. Flere hash-spor er tilgjengelige for en gitt shard, og en enkelt hash-spor kan inneholde flere Redis-nøkler. Det er 16384 hash-spor i en Redis-databaseklynge som forblir uendret. Modulo-divisjonen gjøres med antall hash-spor i stedet for shard-tellingen. Den gir riktig plassering av hash-sporet for den spesifiserte nøkkelen selv når antall shards har økt. Det forenkler omdelingsprosessen ved å flytte hash-sporene fra ett shard til det nye som deler data på tvers av de forskjellige Redis-forekomstene i henhold til krav.

Fordeler med Redis Sharding

Redis sharding muliggjør flere fordeler for databasesystemet med minimale endringer.

Høy gjennomstrømming

Siden Redis er entrådet, kan behandling av flere klientforespørsler ikke behandles parallelt med flere CPU-kjerner. Så å legge til nye shards eller serverforekomster garanterer at du kan utføre Redis-operasjoner parallelt. Det øker operasjonene per sekund i din Redis-database, noe som til slutt gir deg høy gjennomstrømning.

Høy tilgjengelighet

Med sharding-tilnærmingen kan Redis-klyngen sette opp en master-replika-arkitektur som sikrer høy tilgjengelighet og holdbarhet.

Les kopier

Deling lar deg beholde en nøyaktig kopi av dataene dine og gi leseoperasjoner gjennom separate Redis-forekomster, noe som øker ytelsen til kjøringen av lesespørringen din.

Bortsett fra disse fordelene, kan sharding forårsake splittede hjernesituasjoner når du har et jevnt antall shards i Redis-klyngen. Så det anbefales å beholde et oddetall skår i Redis-klyngen.

Konklusjon

For å oppsummere deler Redis sharding data mellom flere servere, noe som muliggjør skalering og høy gjennomstrømning for databasen din. Som diskutert bruker Redis en algoritmisk sharding-strategi for å peke klientforespørsler til riktig shard. Dette har noen ulemper når det totale antallet skår øker. Så, i stedet for det totale antallet shards, bruker Redis antall hash-spor for å beregne riktig shard. Med sharding introdusert, gir Redis-databaser høy tilgjengelighet, høy gjennomstrømning og høy ytelse.