Valg af shard key: kardinalitet, frekvens og monotonitet

Shard-nøglen er uforanderlig, når den først er angivet, og kan ikke ændres uden at ophæve sharding og sharde hele samlingen igen — en dyr og forstyrrende operation. Hvis du vælger den forkerte shard-nøgle, fører det til varme shards, dårlig forespørgselsrouting og spildt hardware. Du skal vurdere kandidater ud fra tre dimensioner: kardinalitet, frekvens og monotonicitet.

Kardinalitet er antallet af forskellige værdier, som shard-nøglen kan antage. Høj kardinalitet (f.eks. userId, email, orderId) er godt — det giver MongoDB mange mulige chunk-grænser og lader balanceren fordele data fint. Lav kardinalitet (f.eks. status: 'active' | 'inactive' og country med 50 værdier) skaber jumbo-chunks, som ikke kan opdeles eller migreres.

Frekvens måler, hvor mange dokumenter der deler hver shard-nøgleværdi. Selv nøgler med høj kardinalitet kan give problemer, hvis et lille antal værdier forekommer i langt størstedelen af dokumenterne. Et felt som countryCode kan for eksempel have 200 forskellige værdier, men 90 % af brugerne kan komme fra ét enkelt land — hvilket skaber en massiv varm chunk, der ikke kan opdeles.

Monotonicitet handler om, hvorvidt shard-nøgleværdier altid stiger (eller falder) over tid. Felter som tidsstempler i createdAt og ObjectId (_id) stiger monotonisk. Det er problematisk, fordi alle nye indsættelser lander i den samme 'maksimale' chunk på én shard, hvilket skaber et varmt skrivepunkt, selv når data historisk set er jævnt fordelt.

Den ideelle shard-nøgle har: Høj kardinalitet — tusinder eller millioner af forskellige værdier. Lav skævhed i frekvensen — ingen enkelt værdi dominerer. Ikke-monotonisk fordeling — værdierne stiger ikke altid, eller også bruger du hashed sharding. Tilpasning til forespørgsler — den matcher filtrene i dine hyppigste forespørgsler, hvor latenstid er vigtig, så routingen kan målrettes.

En sammensat shard-nøgle kombinerer to felter for at opnå en bedre fordeling. For eksempel fordeler { tenantId: 1, createdAt: 1 } data på tværs af tenants (høj kardinalitet) og tillader intervalforespørgsler inden for hver tenant. Det første felt bestemmer den overordnede fordeling, mens det andet giver mulighed for finopdeling. Sammensatte nøgler kan opfylde forespørgselsprædikater med flere felter som målrettede forespørgsler.

En hashed shard-nøgle anvender en hashfunktion på feltets værdi, før den knytter værdien til en chunk. Det omdanner monotone nøgler (f.eks. ObjectId) til tilfældigt fordelte hashværdier og fjerner varme skrivepunkter. Ulempen er, at intervalforespørgsler på feltet bliver til scatter-gather-forespørgsler, fordi hashværdierne ikke gemmes i den oprindelige rækkefølge.

MongoDB giver mulighed for zone-sharding, hvor du tildeler shard-nøgleintervaller til bestemte shards ved hjælp af tags (zoner). Det er nyttigt til krav om dataplacering: Europæiske brugerdata kan bindes til shards i EU-regionen, og amerikanske data til shards i USA. Zone-sharding kræver en sammensat shard-nøgle med et regionspræfiks som første komponent.

Når du vurderer kandidater til shard-nøgler: 1) Kør et kardinalitetstjek — db.col.distinct('field').length bør være i tusindvis eller mere. 2) Kontrollér frekvensfordelingen med en aggregering. 3) Afgør, om feltet er monotont (tidsstempler, automatisk inkrementering). 4) Gennemgå dine 5 hyppigste forespørgsler — optræder kandidatfeltet i deres filter?

En almindelig og sikker standardløsning til mange arbejdsbelastninger er at bruge { _id: 'hashed' }. MongoDB ObjectId-værdier bliver, selv om de er monotone, jævnt fordelt efter hashing. Det giver en ensartet skrivefordeling med det samme. Den største begrænsning er, at alle intervalforespørgsler på _id bliver til scatter-gather-forespørgsler — men for de fleste opslag af dokumenter er det acceptabelt.

MongoDB Atlas indeholder en Shard Key Advisor i Performance Advisor, som analyserer dine forespørgselsmønstre og anbefaler shard-nøgler baseret på den faktiske brug. Den kan registrere monotone nøgler, skæv frekvensfordeling og manglende indekser. Det er især nyttigt at bruge rådgiveren før sharding i produktionsarbejdsbelastninger, hvor forespørgselsmønstrene allerede er etableret.

I denne lektion har du lært, at en god shard-nøgle har høj kardinalitet, lav skævhed i frekvensen og undgår monotone værdier, at sammensatte shard-nøgler kombinerer dækning til fordeling og målretning af forespørgsler, og at hashed sharding neutraliserer varme punkter fra monotone nøgler på bekostning af effektiviteten ved intervalforespørgsler. Som det næste sammenligner vi strategierne ranged sharding og hashed sharding i detaljer.