Databasedeling er en teknikk for å oppnå horisontal skalerbarhet i store systemer.
Nesten alle systemer i den virkelige verden består av en databaseserver som mottar mange leseforespørsler og en ikke ubetydelig mengde skriveforespørsler. Dette kan overbelaste serveren og kan hemme systemytelsen.
For å redusere slike påvirkninger og forbedre ytelsen til et system, finnes det tilnærminger som databasereplikering og databasedeling. I denne veiledningen skal vi først utforske teknikker for å forbedre systemytelsen, inkludert:
- Oppskalering av databaseserveren
- Databasereplikering
- Horisontal partisjonering
Etter å ha diskutert disse teknikkene, vil vi fortsette å lære hvordan databasedeling fungerer og også se på fordelene og begrensningene ved denne tilnærmingen.
La oss begynne!
Innholdsfortegnelse
Teknikker for å forbedre systemytelsen
La oss starte med å diskutere teknikker for å forbedre systemytelsen når det er flaskehalser på grunn av databaseserveren:
#1. Oppskalering av databaseserveren
Å skalere opp databaseserverforekomsten kan virke som en enkel tilnærming for å forbedre systemytelsen. Dette inkluderer å forbedre prosessorkraften, legge til mer RAM og lignende.
Imidlertid kommer denne teknikken med følgende begrensning. Vi kan ikke ha en server med uendelig lagring og prosessorkraft. Og utover en viss grense får vi avtagende avkastning.
#2. Databasereplikering
Når databaseserverforekomsten overbelastning oppstår på grunn av innkommende forespørsler, kan vi vurdere databasereplikering.
Under databasereplikering har vi én hovednode som vanligvis mottar skriveforespørsler. Det er flere leste kopier.
Dette forbedrer tilgjengeligheten og reduserer systemoverbelastning. Vi kan nå behandle flere spørringer parallelt ettersom leseforespørslene kan rutes til en av lesereplikaene.
Men dette introduserer et annet problem. Skriveforespørsler til masternoden kan endre dataene, og disse oppdateringene spres med jevne mellomrom til lesereplikaene.
Anta at det er en leseforespørsel til en av lesereplikaene samtidig som en skriveoperasjon pågår på masternoden.
Endringene i masternoden vil ikke ha forplantet seg til de lese-replikaene ennå. I dette tilfellet kan vi lese utdaterte data, noe som ikke er ønskelig.
#3. Horisontal partisjonering
Horisontal partisjonering er en annen teknikk for å optimalisere systemytelsen. Vi kan ha en enkelt stor tabell med milliarder av rader (som en tabell over kunder og transaksjonsdata).
Leseoperasjonene fra en slik databasetabell er tregere. Men ved å bruke horisontal partisjonering er den store enkelttabellen nå delt inn i flere partisjoner (eller mindre tabeller) som vi kan lese fra. Relasjonsdatabaser som PostgreSQL støtter partisjonering.
Imidlertid er alle partisjonene fortsatt inne i en enkelt databaseserverforekomst. Den eneste forskjellen er at vi nå kan lese fra partisjonene i stedet for den eneste store tabellen.
Derfor, når det er en økning i antall innkommende forespørsler, kan det hende at serveren ikke kan støtte den økte etterspørselen.
Hvordan fungerer databasedeling?
Nå som vi har diskutert tilnærmingene for å forbedre systemytelsen og deres begrensninger, la oss forstå hvordan databasedeling fungerer.
Ved sharding deler vi den store enkeltdatabasen i flere mindre databaser, som hver kjører på en databaseserverforekomst. Hver slik mindre database kalles en shard. Og hvert shard inneholder et unikt delsett av dataene.
Men hvordan deler vi databasen i shards? Og hvordan bestemmer vi hvilken av radene som går inn i hvilke av skårene?
🔑 Skriv inn skjæringsnøkkelen.
Forstå Sharding Key
La oss forstå rollen til skjæringsnøkkelen.
Sharding-nøkkelen, som vanligvis er en kolonne (eller en kombinasjon av kolonner) i databasetabellen, bør velges slik at fordelingen av data er jevn over flere shards. Fordi vi ikke vil at et bestemt skår skal være mye større enn de andre skårene.
I en database som lagrer data om kunder og transaksjoner, er customer_ID en god kandidat for sharding-nøkkelen.
Når vi har bestemt oss for sharding-nøkkelen, kan vi komme opp med en hashing-funksjon som bestemmer hvilken av radene som går inn i hvilke shards.
I dette eksemplet, si at vi må dele databasen i fem shards (shard #0 til shard #4) ved å bruke customer_ID som sharding-nøkkel. I dette tilfellet er en enkel hashing-funksjon kunde_ID % 5.
Alle customer_ID-verdier som etterlater en rest av null når de er delt på 5, vil kartlegges til shard #0. Og customer_ID-verdier som etterlater restene 1 til 4 vil kartles til henholdsvis shard #1 til shard #4.
Etter at databasedelingen er implementert på denne måten, er det viktig å ha et rutinglag som ruter innkommende forespørsler til riktig databaseskjær.
Fordeler med databasedeling
Her er noen av fordelene med databasedeling:
#1. Høy skalerbarhet
Det er alltid mulig å dele en større database i flere mindre skår. Så databasedeling lar oss skalere ut horisontalt.
#2. Høy tilgjengelighet
Når det er en enkelt databaseserverforekomst som håndterer alle innkommende forespørsler, har vi ett enkelt feilpunkt. Hvis databaseserveren er nede, er hele applikasjonen nede.
Med databaseskjæring er sannsynligheten for at alle databaseskjærene er nede på et gitt øyeblikk relativt lav. Derfor, hvis en bestemt shard er nede, vil vi ikke kunne behandle leseforespørsler til den sharden. Men de andre skårene kan fortsatt behandle de innkommende forespørslene. Dette resulterer i høy tilgjengelighet og økt feiltoleranse.
Begrensninger for deling av database
La oss nå gå over noen av begrensningene ved databasedeling:
#1. Kompleksitet
Selv om sharding har fordeler når det gjelder skalerbarhet og feiltoleranse, introduserer det kompleksitet til systemet.
Fra kartlegging av poster til partisjoner til implementering av rutinglaget for å rute spørringer til de respektive shards, er det betydelig kompleksitet involvert med sharding av databaser.
#2. Omharding
En annen begrensning ved sharding er behovet for resharding.
Selv om vi bruker hashing-funksjon for å få en jevn fordeling av dataposter, er det mulig at ett av shards er mye større enn de andre shards, og det kan bli uttømt før. I dette tilfellet må vi ta hensyn til omdeling (eller omstokking), og det kommer med betydelige kostnader.
#3. Kjører komplekse spørringer
Når du trenger å kjøre spørringer for analyse som involverer sammenføyninger, må du bruke poster fra flere shards i motsetning til en enkelt database. Så dette kan være en utfordring når du trenger å kjøre for mange analytiske søk. Du kan komme deg rundt dette ved å denormalisere databaser, men det krever fortsatt litt innsats!
Konklusjon
La oss avslutte diskusjonen med en oppsummering av det vi har lært.
Å skalere opp maskinvaren er ikke alltid optimalt. Så det anbefales ikke å forbedre serverforekomsten. Vi har også gjennomgått teknikker som databasereplikering og horisontal partisjonering og deres begrensninger.
Deretter lærte vi hvordan databasedeling fungerer ved å dele opp en stor database i mindre og enkle å administrere shards. Vi diskuterte hvordan sharding-nøkkelen bør velges nøye for å få jevne partisjoner og behovet for et rutelag for å rute innkommende forespørsler til riktig database shard.
Databasedeling har fordeler som høy tilgjengelighet og skalerbarhet. Noen av ulempene inkluderer kompleksiteten ved å sette opp sharding og resharding når ett eller flere shards blir oppbrukt.
Så du kan vurdere sharding når du tror fordelene oppveier kompleksiteten introdusert av sharding. Deretter kan du sjekke sammenligningen av de forskjellige AWS relasjonsdatabasene.