Når du IKKE bør bruke sharding
Lesereplikaer, partisjonering og kraftigere maskiner løser de fleste skaleringsproblemer – lær når sharding er feil løsning.
Når du IKKE bør bruke sharding er en gratis leksjon i SQL Academy på CoddyKit. Dette er leksjon 4 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i SQL Academy, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i SQL Academy inneholder totalt 4 leksjoner.
Sharding er siste utvei
Sharding mangedobler den operasjonelle kompleksiteten. De fleste apper trenger det aldri. Prøv enklere alternativer først.
Trinn 1: Vertikal skalering
En kraftigere server. Moderne skyinstanser håndterer enkelt:
- 128 kjerner
- 1 TB RAM
- 50 000 IOPS NVMe
Det tilsvarer 100k-500k QPS på én enkelt Postgres-node. De fleste apper får god plass.
Trinn 2: Lesereplikaer
Hvis lesing dominerer, legger du til replikaer. Én primærnode + 3 replikaer kan håndtere ti ganger så mye lesing.
Trinn 3: Bufring
Redis/memcached foran spørringer som brukes ofte. Ofte den rimeligste forbedringen.
Trinn 4: Partisjonering
Innebygd deklarativ partisjonering i PG løser problemet med «for stor tabell» på én enkelt server. Det er ofte 100 ganger enklere enn sharding.
Trinn 5: Dele opp tjenester
Flytt ulike domener til ulike databaser – en database for ordrer, en for brukere og en for analyse. Hver database kan skaleres uavhengig.
Trinn 6: Flytt analysen ut
OLTP-spørringer → Postgres. Analysespørringer → ClickHouse / BigQuery / Snowflake. Mange historier om at «vi må sharde» handler egentlig om at «analysen spiser opp OLTP-kapasiteten vår».
Deretter, kanskje, sharding
Hvis du fortsatt går tom for kapasitet ved 50 TB med data som bare brukes til OLTP, og arbeidsbelastningen krever flere skriveoperasjoner enn én server kan håndtere, bør du begynne å planlegge shards.
Operasjonelle kostnader ved sharding
- Flere servere å overvåke og oppdatere
- Sikkerhetskopiering på tvers av shards må koordineres
- Spørringer på tvers av shards havner i appkoden
- Resharding er vanskelig
- Overbelastede shards krever aktiv rebalansering
Strategien «shard sent»
Bygg med sharding-bevisste mønstre (ta alltid med tenant_id, og bruk aldri globalt økende tellere), slik at du KAN sharde senere. Men ikke shard før du blir tvunget til det.
Skjema som er egnet for sharding
Selv om du forblir på én node, bør du utforme løsningen som om du kanskje skal sharde:
- Tenant_id på hver rad
- UUID eller distribuerte ID-er (ikke auto-increment)
- Ingen globalt unike sekvenser
- Fremmednøkler innenfor en tenants område
Erkjenn avveiningen
Sharding gir mer kapasitet på bekostning av funksjonalitet. JOIN-er, transaksjoner og spørringer blir vanskeligere. Vær sikker på at gevinsten er verdt det.
Oppsummering
Sharding løser et reelt problem – men det er en omfattende løsning.
- Skaler vertikalt først
- Lesereplikaer + bufring
- Partisjonering før sharding
- Flytt analysen bort fra OLTP
- Utform løsningen for sharding, men utsett selve sharding-prosessen
Hurtigsjekk
Du vurderer sharding fordi OLTP-spørringene er trege. Hvilket trinn vil mest sannsynlig hjelpe før du sharder?
Lær deg SQL med en AI-veileder – gratis
Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.
- Kurs
- 46
- Leksjoner
- 183
Ofte stilte spørsmål
Er leksjonen «Når du IKKE bør bruke sharding» gratis?
Ja – hele teksten i «Når du IKKE bør bruke sharding» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av SQL Academy-kurset, kan du oppgradere til CoddyKit PRO. Kurset i SQL Academy inneholder totalt 4 leksjoner.
Hva lærer jeg i «Når du IKKE bør bruke sharding»?
Lesereplikaer, partisjonering og kraftigere maskiner løser de fleste skaleringsproblemer – lær når sharding er feil løsning. Du øver på SQL Academy med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.
Trenger jeg erfaring for å begynne med SQL Academy?
Ingen tidligere erfaring er nødvendig. SQL Academy på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 4 av 4.
Hvor lang tid tar leksjonen «Når du IKKE bør bruke sharding»?
De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.
Kan jeg skrive og kjøre kode i denne SQL Academy-leksjonen?
Ja. Alle SQL Academy-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.
Alle leksjonene i dette kurset
- Strategier for sharding: Område, hash, katalog
- Spørringer på tvers av shards: Det vanskelige problemet
- Citus og distribuert Postgres
- Når du IKKE bør bruke sharding