Utforma för dataändring

Den här artikeln fokuserar på designöverväganden för att optimera infogningar, uppdateringar och borttagningar. I vissa fall måste du utvärdera kompromissen mellan designer som optimerar för frågor mot mönster som optimerar för dataändring precis som du gör i design för relationsdatabaser (även om teknikerna för att hantera designvägningarna skiljer sig åt i en relationsdatabas). Avsnittet Tabelldesignmönster beskriver några detaljerade designmönster för tabelltjänsten och belyser några av dessa kompromisser. I praktiken ser du att många designer som är optimerade för att fråga entiteter också fungerar bra för att ändra entiteter.

Optimera prestanda för infognings-, uppdaterings- och borttagningsåtgärder

Om du vill uppdatera eller ta bort en entitet måste du kunna identifiera den med värdena PartitionKey och RowKey . I det här avseendet bör ditt val av PartitionKey och RowKey för att ändra entiteter följa liknande kriterier som ditt val för att stödja punktfrågor eftersom du vill identifiera entiteter så effektivt som möjligt. Du vill inte använda en ineffektiv partitions- eller tabellgenomsökning för att hitta en entitet för att identifiera värdena PartitionKey och RowKey som du behöver uppdatera eller ta bort.

Följande mönster i avsnittet Tabelldesignmönster hanterar optimering av prestanda eller åtgärder för infogning, uppdatering och borttagning:

• Mönster för borttagning av stora volymer – Aktivera borttagning av en stor mängd entiteter genom att lagra alla entiteter för samtidig borttagning i en egen separat tabell. du tar bort entiteterna genom att ta bort tabellen.
• Dataseriemönster – Lagra fullständiga dataserier i en enda entitet för att minimera antalet begäranden som du gör.
• Mönster för breda entiteter – Använd flera fysiska entiteter för att lagra logiska entiteter med fler än 252 egenskaper.
• Mönster för stora entiteter – Använd Blob Storage för att lagra stora egenskapsvärden.

Se till att dina lagrade entiteter är konsekventa

Den andra nyckelfaktorn som påverkar ditt val av nycklar för att optimera dataändringar är hur du säkerställer konsekvens med hjälp av atomära transaktioner. Du kan bara använda en EGT för att arbeta på entiteter som lagras i samma partition.

Följande mönster i artikeln Tabelldesignmönster hanterar konsekvens:

• Sekundärt indexmönster mellan partitioner – Lagra flera kopior av varje entitet med olika RowKey-värden (i samma partition) för att möjliggöra 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 möjliggöra snabba och effektiva sökningar och alternativa sorteringsordningar med hjälp av olika RowKey-värden .
• Så småningom konsekventa transaktionsmönster – Aktivera så småningom konsekvent beteende över partitionsgränser eller lagringssystemgränser med hjälp av Azure-köer.
• Mönster för indexentiteter – Underhåll indexentiteter för att möjliggöra effektiva sökningar som returnerar listor över entiteter.
• Avnormaliseringsmönster – Kombinera relaterade data i en enda entitet så att du kan hämta alla data som du behöver med en enskild punktfråga.
• Dataseriemönster – Lagra fullständiga dataserier i en enda entitet för att minimera antalet begäranden som du gör.

Information om entitetsgrupptransaktioner finns i avsnittet Entitetsgrupptransaktioner.

Se till att din design för effektiva ändringar underlättar effektiva frågor

I många fall resulterar en design för effektiv frågekörning i effektiva ändringar, men du bör alltid utvärdera om detta är fallet för ditt specifika scenario. Några av mönstren i artikeln Tabelldesignmönster utvärderar uttryckligen kompromisser mellan att fråga och ändra entiteter, och du bör alltid ta hänsyn till antalet för varje typ av åtgärd.

Följande mönster i artikeln Tabelldesignmönster löser avvägningar mellan att designa för effektiva frågor och att utforma för effektiv dataändring:

• Sammansatt nyckelmönster – Använd sammansatta RowKey-värden för att göra det möjligt för en klient att söka efter relaterade data med en enskild punktfråga.
• Loggslutsmönster – Hämta de n entiteter som senast lagts till i en partition med hjälp av ett RowKey-värde som sorterar i omvänd datum- och tidsordning.