SQL Academy · Lektion

Forespørgsler på tværs af shards: Det svære problem

Forstå, hvorfor joins og transaktioner på tværs af shards er det sværeste problem i distribuerede databaser, samt mønstrene, der minimerer dem.

Lektion 2 af 413 trin

Forespørgsler på tværs af shards: Det svære problem er en gratis SQL Academy-lektion på CoddyKit. Dette er lektion 2 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i SQL Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. SQL Academy-kurset indeholder 4 lektioner i alt.

Omkostningen ved sharding

Sharding skalerer skriveoperationer og kapacitet, men gør forespørgsler, der spænder over flere shards, besværlige: alle forespørgsler på tværs af shards er fan-out-forespørgsler.

Forespørgsler til én shard er enkle

Hvis din shard-nøgle findes i WHERE-delen, sender routeren én forespørgsel 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-forespørgsler

Uden shard-nøglen forespørger routeren alle shards og sammenfletter resultaterne:

-- 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 hentes delresultater fra hver shard, hvorefter de kombineres i routeren eller applikationen:

-- 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.

JOINs på tværs af shards

Hvis begge sider er opdelt efter den samme nøgle (samplacerede), er JOIN'et lokalt på shard-niveau. Ellers er det i praksis umuligt i stor skala.

Referencetabeller (replikeret overalt)

Små "opslagstabeller" replikeres til hver shard, så JOINs til dem forbliver lokale. Citus kalder dem "referencetabeller".

Undgå mønstre på tværs af shards

Tricks til skemadesign:

Denormalisér — kopiér data om den overordnede post til den shard, der indeholder den underordnede post
Brug shard-nøglen overalt — også når det virker "unødvendigt"
Forudberegn rapporter i en separat analyse-database

Sideinddeling på tværs af shards

OFFSET 1000 LIMIT 10 på tværs af mange shards er elendigt — hver shard skal producere 1010 rækker. Brug i stedet sideinddeling baseret på nøgler.

Distribuerede transaktioner

Two-phase commit (2PC) koordinerer atomiske commits på tværs af shards. Det er langsomt og skrøbeligt under partitionering. I praksis bør du designe efter 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

Varme shards

En kendt bruger eller et viralt produkt — koncentreret trafik på én shard ødelægger din skaleringsstrategi. Opdag problemet, og opdel shard'en yderligere eller flyt dataene.

Fremmednøgler på tværs af shards

RDBMS'ets FK'er går ikke på tværs af shards. Du håndhæver referentiel integritet i applikationen eller accepterer eventuel konsistens for relationer på tværs af shards.

Opsummering

Sharding flytter udfordringen fra "skalér skriveoperationer" til "form forespørgslerne, så de forbliver lokale på en shard".

Forespørgsler til én shard er hurtige
Forespørgsler til alle shards er langsomme
Denormalisér for at holde arbejdet lokalt
Referencetabeller til delte dimensioner
Sagaer i stedet for 2PC

Hurtigt tjek

Hvorfor er en SELECT uden shard-nøglen i WHERE-delen dyr på en database med sharding?

Besvar den i den interaktive lektion

Gratis at komme i gang

Lær SQL med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 46
Lektioner: 183

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Forespørgsler på tværs af shards: Det svære problem” gratis?

Ja — hele teksten til “Forespørgsler på tværs af shards: Det svære problem” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af SQL Academy-kurset, skal du opgradere til CoddyKit PRO. SQL Academy-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Forespørgsler på tværs af shards: Det svære problem”?

Forstå, hvorfor joins og transaktioner på tværs af shards er det sværeste problem i distribuerede databaser, samt mønstrene, der minimerer dem. Du øver dig i SQL Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på SQL Academy?

Der kræves ingen tidligere erfaring. SQL Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 2 af 4.

Hvor lang tid tager lektionen “Forespørgsler på tværs af shards: Det svære problem”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne SQL Academy-lektion?

Ja. Alle SQL Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Strategier til sharding: Range, hash og directory
Forespørgsler på tværs af shards: Det svære problem
Citus og distribueret Postgres
Hvornår De IKKE skal bruge sharding

← Tilbage til SQL Academy