SQL Academy · leksjon

Spørringer på tvers av shards: Det vanskelige problemet

Forstå hvorfor joins og transaksjoner på tvers av shards er det vanskeligste problemet i distribuerte databaser, og hvilke mønstre som minimerer dem.

Leksjon 2 av 413 trinn

Spørringer på tvers av shards: Det vanskelige problemet er en gratis leksjon i SQL Academy på CoddyKit. Dette er leksjon 2 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-kostnaden

Sharding skalerer skriveoperasjoner og kapasitet, men gjør spørringer som går på tvers av shards smertefulle: Alle spørringer på tvers av shards blir en fan-out.

Spørringer mot én shard er enkle

Hvis shard-nøkkelen finnes i WHERE-uttrykket, sender ruteren én spørring til én shard:

-- shard_id = hash(user_id) % N
SELECT * FROM orders WHERE user_id = 42;
-- Router computes shard, sends one query, gets one result.

Fan-out-spørringer

Uten shard-nøkkelen spør ruteren hver shard og slår sammen resultatene:

-- WHERE status = 'paid' — no user_id
SELECT * FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 100;
-- Must query all N shards, merge results, sort, take top 100.

Fan-out-aggregeringer

For COUNT/SUM/AVG: Hent delresultater fra hver shard, og kombiner dem deretter i ruteren eller appen:

-- On each shard:
SELECT COUNT(*), SUM(total) FROM orders;

-- Aggregator:
final_count = SUM(counts), final_sum = SUM(sums)

-- AVG is trickier — need SUM and COUNT, can't average averages.

JOIN-er på tvers av shards

Hvis begge sidene er shardet etter den samme nøkkelen (samlokaliserte), utføres JOIN-en lokalt på sharden. Ellers er dette i praksis umulig i stor skala.

Referansetabeller (replikert overalt)

Små «oppslagstabeller» replikeres til hver shard, slik at JOIN-er mot dem forblir lokale. Citus kaller dem «referansetabeller».

Unngå mønstre på tvers av shards

Triks for skjemadesign:

Denormaliser – dupliser data om forelderen i sharden som inneholder barnet
Bruk shard-nøkkelen overalt – også når den virker «unødvendig»
Forhåndsberegn rapporter i en separat analyse-DB

Sideinndeling på tvers av shards

OFFSET 1000 LIMIT 10 over mange shards er svært ineffektivt – hver shard må produsere 1010 rader. Bruk keyset-sideinndeling i stedet.

Distribuerte transaksjoner

Two-phase commit (2PC) koordinerer atomiske bekreftelser på tvers av shards. Det er tregt og sårbart ved nettverkspartisjonering. I praksis bør du utforme løsningen for «saga»-mønstre:

// Saga pattern (conceptual):
//   1. Local TX on shard A: mark as pending, log
//   2. RPC to shard B: do its part
//   3. Local TX on shard A: mark as committed
//   4. On failure: compensating transactions

Overbelastede shards

En kjendisbruker eller et viralt produkt – konsentrert trafikk på én shard ødelegger hele skaleringsstrategien. Oppdag problemet og del sharden videre (sub-sharding), eller flytt dataene.

Fremmednøkler på tvers av shards

Fremmednøkler i RDBMS går ikke på tvers av shards. Du håndhever referanseintegritet i appen, eller godtar eventuell konsistens for relasjoner på tvers av shards.

Oppsummering

Sharding flytter utfordringen fra «skaler skriveoperasjoner» til «utform spørringene slik at de forblir lokale på sharden».

Spørringer mot én shard er raske
Fan-out er tregt
Denormaliser for å holde arbeidet lokalt
Referansetabeller for delte dimensjoner
Sagaer i stedet for 2PC

Hurtigsjekk

Hvorfor er en SELECT uten shard-nøkkelen i WHERE-uttrykket kostbar i en sharded database?

Besvar den i den interaktive leksjonen

Gratis å komme i gang

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

Start læringen gratis Se hele kurset

Ofte stilte spørsmål

Er leksjonen «Spørringer på tvers av shards: Det vanskelige problemet» gratis?

Ja – hele teksten i «Spørringer på tvers av shards: Det vanskelige problemet» 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 «Spørringer på tvers av shards: Det vanskelige problemet»?

Forstå hvorfor joins og transaksjoner på tvers av shards er det vanskeligste problemet i distribuerte databaser, og hvilke mønstre som minimerer dem. 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 2 av 4.

Hvor lang tid tar leksjonen «Spørringer på tvers av shards: Det vanskelige problemet»?

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

← Tilbake til SQL Academy