Designa för frågeställningar

Tabelltjänstlösningar kan vara läsintensiva, skrivintensiva eller en blandning av de två. Den här artikeln fokuserar på saker att tänka på när du utformar tabelltjänsten för att effektivt stödja läsåtgärder. Vanligtvis är en design som stöder läsåtgärder effektivt också effektiv för skrivåtgärder. Det finns dock ytterligare saker att tänka på när du utformar för att stödja skrivåtgärder, som beskrivs i artikeln Design för dataändring.

En bra utgångspunkt för att utforma tabelltjänstlösningen så att du kan läsa data effektivt är att fråga "Vilka frågor måste mitt program köra för att hämta de data som behövs från tabelltjänsten?"

Det här avsnittet fokuserar på de viktiga problem som du måste åtgärda när du utformar tabellerna för frågor. De ämnen som beskrivs i det här avsnittet är:

• Hur ditt val av PartitionKey och RowKey påverkar frågeprestanda
• Välja en lämplig PartitionKey
• Optimera frågor för tabelltjänsten
• Sortera data i tabelltjänsten

Hur ditt val av PartitionKey och RowKey påverkar frågeprestanda

Följande exempel förutsätter att tabelltjänsten lagrar anställdatiteter med följande struktur (de flesta av exemplen utelämnar timestamp-egenskapen för tydlighetens skull):

Artikeln Översikt över Azure Table Storage beskriver några av de viktigaste funktionerna i Azure Table-tjänsten som har direkt påverkan på utformningen av frågor. Dessa resulterar i följande allmänna riktlinjer för att utforma tabelltjänstfrågor. Observera att filtersyntaxen som används i exemplen nedan kommer från REST-API:et för tabelltjänsten för mer information i Fråga entiteter.

• En punktfråga är den mest effektiva sökningen att använda och rekommenderas att användas för sökningar med stora volymer eller sökningar som kräver lägsta svarstid. En sådan fråga kan använda indexen för att hitta en enskild entitet mycket effektivt genom att välja både PartitionKey-värdena och RowKey. Till exempel: $filter=(PartitionKey eq 'Sales') och (RowKey eq '2')
• Det näst bästa är en intervallfråga som använder PartitionKey och filtrerar på ett intervall med RowKey-värden för att returnera mer än en entitet. Värdet PartitionKey identifierar en specifik partition och RowKey-värdena identifierar en delmängd av entiteterna i partitionen. Till exempel: $filter=PartitionKey eq "Sales" och RowKey ge "S" och RowKey lt "T"
• Det tredje bästa är en partitionsgenomsökning som använder PartitionKey och filtrerar på en annan icke-nyckelegenskap och som kan returnera mer än en entitet. Värdet PartitionKey identifierar en specifik partition och egenskapsvärdena väljer för en delmängd av entiteterna i partitionen. Till exempel: $filter=PartitionKey eq "Sales" och LastName eq 'Smith'
• En tabellgenomsökning innehåller inte PartitionKey och är mycket ineffektiv eftersom den söker i alla partitioner som utgör tabellen i tur och ordning efter matchande entiteter. Den utför en tabellgenomsökning oavsett om filtret använder RowKey eller inte. Till exempel: $filter=LastName eq 'Jones'
• Frågor som returnerar flera entiteter returnerar dem sorterade i PartitionKey - och RowKey-ordning . Om du vill undvika att använda entiteterna i klienten väljer du en RowKey som definierar den vanligaste sorteringsordningen.

Observera att användning av ett "eller" för att ange ett filter baserat på RowKey-värden resulterar i en partitionsgenomsökning och behandlas inte som en intervallfråga. Därför bör du undvika frågor som använder filter som: $filter=PartitionKey eq "Sales" och (RowKey eq '121' eller RowKey eq '322')

Exempel på kod på klientsidan som använder lagringsklientbiblioteket för att köra effektiva frågor finns i:

• Köra en punktfråga med hjälp av lagringsklientbiblioteket
• Hämta flera entiteter med LINQ
• Projektion på serversidan

Exempel på kod på klientsidan som kan hantera flera entitetstyper som lagras i samma tabell finns i:

• Arbeta med heterogena entitetstyper

Välja en lämplig PartitionKey

Ditt val av PartitionKey bör balansera behovet av att aktivera användning av entitetsgrupptransaktioner (för att säkerställa konsekvens) mot kravet på att distribuera dina entiteter över flera partitioner (för att säkerställa en skalbar lösning).

På en extrem nivå kan du lagra alla dina entiteter i en enda partition, men detta kan begränsa lösningens skalbarhet och förhindra att tabelltjänsten kan lastbalansera begäranden. I den andra extremiteten kan du lagra en entitet per partition, vilket skulle vara mycket skalbart och som gör det möjligt för tabelltjänsten att lastbalansera begäranden, men som hindrar dig från att använda entitetsgrupptransaktioner.

En idealisk PartitionKey är en som gör att du kan använda effektiva frågor och som har tillräckligt med partitioner för att säkerställa att din lösning är skalbar. Vanligtvis upptäcker du att dina entiteter har en lämplig egenskap som distribuerar dina entiteter över tillräckligt många partitioner.

Det finns ytterligare överväganden i valet av PartitionKey som relaterar till hur du ska infoga, uppdatera och ta bort entiteter. Mer information finns i Designa tabeller för dataändring.

Optimera frågor för tabelltjänsten

Tabelltjänsten indexerar automatiskt dina entiteter med värdena PartitionKey och RowKey i ett enda klustrat index, vilket är anledningen till att punktsökningar är de mest effektiva att använda. Det finns dock inga andra index än det i det klustrade indexet på PartitionKey och RowKey.

Många designer måste uppfylla kraven för att aktivera uppslag av entiteter baserat på flera kriterier. Du kan till exempel hitta entiteter för anställda baserat på e-post, medarbetar-ID eller efternamn. Mönstren som beskrivs i Tabelldesignmönster hanterar dessa typer av krav och beskriver olika sätt att kringgå det faktum att tabelltjänsten inte tillhandahåller sekundära index:

• Sekundärt indexmönster mellan partitioner – Lagra flera kopior av varje entitet med olika RowKey-värden (i samma partition) för att aktivera snabba och effektiva sökningar och alternativa sorteringsordningar med hjälp av olika RowKey-värden .
• Sekundärt indexmönster mellan partitioner – Lagra flera kopior av varje entitet med olika RowKey-värden i separata partitioner eller i separata tabeller för att aktivera snabba och effektiva sökningar och alternativa sorteringsordningar med hjälp av olika RowKey-värden .
• Mönster för indexentiteter – Underhåll indexentiteter för att möjliggöra effektiva sökningar som returnerar listor över entiteter.

Sortera data i tabelltjänsten

Tabelltjänsten returnerar entiteter sorterade i stigande ordning baserat på PartitionKey och sedan efter RowKey. Dessa nycklar är strängvärden och för att säkerställa att numeriska värden sorteras korrekt bör du konvertera dem till en fast längd och fylla dem med nollor. Om värdet för medarbetar-ID som du använder som RowKey till exempel är ett heltalsvärde bör du konvertera medarbetar-ID 123 till 00000123.

Många program har krav på att använda data sorterade i olika ordningar: till exempel sortering av anställda efter namn eller genom anslutningsdatum. Följande mönster hanterar hur du växlar mellan sorteringsordningar för dina entiteter.

• Sekundärt indexmönster mellan partitioner – Lagra flera kopior av varje entitet med olika RowKey-värden (i samma partition) för att aktivera snabba och effektiva sökningar och alternativa sorteringsordningar med hjälp av olika RowKey-värden.
• Sekundärt indexmönster mellan partitioner – Lagra flera kopior av varje entitet med olika RowKey-värden i separata partitioner i separata tabeller för att aktivera snabba och effektiva sökningar och alternativa sorteringsordningar med hjälp av olika RowKey-värden.
• Loggsvansmönster – Hämta de n entiteter som senast har lagts till i en partition med hjälp av ett RowKey-värde som sorterar i omvänd datum- och tidsordning.

Nästa steg

• Designmönster för tabeller
• Relationer genom modellering
• Kryptera tabelldata
• Design för dataändring