ProductKey og PartitionKey i Azure DataTables


Jeg får ofte spørsmål om riktig bruk og definisjon av disse to begrepene innenfor DataTables i Azure. Derfor tenkte jeg at et kort blogginnlegg om dette kunne være på sin plass:

PartitionKey

Denne delen av nøkkelen handler om ytelse, og hvordan Azure kan sørge for å levere en lavest mulig responstid. Dersom en partisjon er mye brukt, så flyttes den til en en server som støtter den høyere trafikken. Om den blir stor, så flyttes den til en server med tilsvarende lagringskapasitet. Partisjoner generelt, er forskjellige for de ulike tjenestene innenfor Azure lagring:

· I Blob storage er hver enkelt blob en separat partisjon. Det betyr at blobs alltid kan få den beste throughputen systemet kan levere

· I køer er hver enkelt kø en separat partisjon

· I tabeller bestemmer du, ved å angi partisjonsnøkkel, hvordan data sameksisterer i systemet

Dette betyr med andre ord at det er du selv som er ansvarlig for ytelsen i løsningen din ved å tenke smart mht partitionkey.

Merk:

Azure lagring kan selv finne ut at den trenger å spalte opp partisjoner i såkalte “Range Partitions”. Se følgende lenke for mer informasjon:
http://msdn.microsoft.com/en-us/library/windowsazure/hh508997.aspx.

RowKey

Din RowKey (radnøkkel) er ganske enkelt din «primærnøkkel» innenfor den partisjonen som du har valgt. Sammen med PartitionKey har du dermed en unik kombinasjon for din entitet. Du kan kun ha en radnøkkel pr partisjon, men dersom du opererer med flere partisjoner, kan radnøkkelen angis om igjen.

For eksempel:

PartitionKey

RowKey

Entitet

ProduktPris

123

<Entitet som beskriver prisen>

ProduktDimensjon

123

<Entitet som beskriver mål og vekt>

ProduktPlassering

123

<Entitet som beskriver plassering av produkt på lager>

ProduktDetalj

123

<Entitet som beskriver detaljer om produktet>

Tabellen over viser kombinasjonen av ulike partisjoner for samme produkt id.

Ytelse

Det er fornuftig å tenke gjennom hvordan du bruker kombinasjonen av PartitionKey og RowKey før du skriver koden din. Ikke bare gi de en tilfeldig verdi/GUID, fordi dette har konsekvenser for ytelsen du får.

Den raskeste måten å få svar fra DataTables oppnås ved å spesifisere PartitionKey og RowKey samtidig. Ved å gjøre dette så vil DataTabellen vite hvilken partisjon den skal spørre på.

Litt mindre raskt (men fremdeles raskt nok!) er å spørre ved å spesifisere PartitionKey.

Mindre raskt er å spørre på RowKey. Ved å gjøre dette vet ikke Storage hvilken partisjon den skal starte i,  slik at den gjør en “fan out” spørring mot alle partisjoner, og dermed, potensielt flere systemer. Innenfor en partisjon er søk på PartitionKey ekstremt raskt, siden dette er en unik indeks.

Tregt: Søk på andre felter i tabellen (fordi dette spenner over flere partisjoner i søk etter egenskapene

Øvelse

La oss si at du skal lagre kunder, Ordre, og Ordrelinjer. Hva bør du velge som PartitionKey  og RowKey ?

Et “ideelt” oppsett kan se slik ut, avhengig av hvordan du ønsker å spørre etter data:

Tabell PartitionKey RowKey Kommentar
Kunde SalgsRegion KundeId Gir raske søk på region og kundens id
Ordre KundeId OrdreId Gir meg muligheten til å raskt søke opp alle ordrene til en bestemt kunde. Det går også raskt å søke opp spesifikk ordreId.
Ordrelinje OrdreId OrdrelinjeId Raskt oppslag på ordreId og ordrelinjeId

Avhengig av systemet som bygges, så er kanskje dette et bedre oppsett:

Tabell PartitionKey RowKey Kommentar
Kunde KundeId VisningsNavn Raske søk både på kundeId og visningsnavnet
Ordre KundeId OrdreId Gir meg muligheten til å raskt søke opp alle ordrene til en bestemt kunde. Det går også raskt å søke opp spesifikk ordreId.
Ordrelinje OrdreId ProduktId Raskt oppslag på ordreId og hvilket produkt som ble kjøpt

Som sagt, det å tenke gjennom løsningen og hvordan man ser for seg bruken av datatabeller er viktig. Det er også et viktig poeng at du ikke må velge enten/eller! Det er helt normalt å denormalisere sine data og lagre de dobbelt under ulike formater for å støtte flere spørringsalternativer!

Det finnes en siste “index”!

Nemlig! Tabellnavnet er også en index! La oss kikke på eksemplet ordre-ordrelinje en gang til:

Det å ha en kundetabell som inneholder alle kunder er interessant å søke etter innenfor den typen data, men å ha en ordretabell som inneholder alle ordre for alle kunder er kanskje ikke en ideell løsning. En tanke er derfor å lage en ordretabell pr.Kunde? Dersom du gjør dette, så kan du veldig raskt spørre etter ordre Ider (tabellnavnet) og innenfor ordretabellen kan du da legge flere detaljer i PartitionKey og PrimaryKey.

Og.. ENDA en: Du kan faktisk også splitte data over flere lagringskontoer for å få nok en “partisjon”

Konklusjon

Tenk godt gjennom PartitionKey og RowKey slik at de gir mening for den løsningen eller forretningsdomenet. Da oppnår du raskere spørringer og en effektiv bruk av DataTables i lengden.

Comments (0)

Skip to main content