Design 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 design som optimerar för att köra frågor mot design som optimerar för dataändring precis som du gör i design för relationsdatabaser (även om teknikerna för att hantera designen skiljer sig åt i en relationsdatabas). I avsnittet Tabelldesignmönster beskrivs några detaljerade designmönster för tabelltjänsten och vissa avvägningar markeras. 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 åtgärder för att infoga, uppdatera och ta bort

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 partition eller tabellgenomsökning för att hitta en entitet för att identifiera de PartitionKey - och RowKey-värden som du behöver för att uppdatera eller ta bort den.

Följande mönster i avsnittet Tabelldesignmönster hanterar optimering av prestanda eller åtgärder för att infoga, uppdatera och ta bort:

• 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 sin egen separata tabell. du tar bort entiteterna genom att ta bort tabellen.
• Mönster för dataserier – 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 bloblagring 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 atomiska 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 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 .
• 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.
• Indexentitetsmönster – Underhåll indexentiteter för att möjliggöra effektiva sökningar som returnerar listor över entiteter.
• Avormaliseringsmönster – Kombinera relaterade data i en enda entitet så att du kan hämta alla data du behöver med en enskild punktfråga.
• Mönster för dataserier – 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 sökning 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 hanterar kompromisser mellan utformning av effektiva frågor och utformning 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.
• 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.