Utforma skalbara och högpresterande tabeller

Om du vill utforma skalbara och högpresterande tabeller måste du överväga faktorer som prestanda, skalbarhet och kostnad. Om du tidigare har utformat scheman för relationsdatabaser är dessa överväganden bekanta, men även om det finns vissa likheter mellan Azure Table-tjänstlagringsmodellen och relationsmodellerna finns det också viktiga skillnader. Dessa skillnader leder vanligtvis till olika design som kan se kontraintuitiva eller felaktiga ut för någon som är bekant med relationsdatabaser, men ändå är meningsfull om du designar för ett Nyckel-/värdearkiv för NoSQL, till exempel Azure Table-tjänsten. Många av dina designskillnader återspeglar det faktum att tabelltjänsten är utformad för att stödja molnskaliga program som kan innehålla miljarder entiteter (eller rader i relationsdatabasterminologi) för data eller för datauppsättningar som måste ha stöd för stora transaktionsvolymer. Därför måste du tänka annorlunda på hur du lagrar dina data och förstå hur tabelltjänsten fungerar. Ett väldesignat NoSQL-datalager kan göra det möjligt för din lösning att skalas mycket längre och till en lägre kostnad än en lösning som använder en relationsdatabas. Den här guiden hjälper dig med de här ämnena.

Om Azure Table-tjänsten

Det här avsnittet belyser några av de viktigaste funktionerna i tabelltjänsten som är särskilt relevanta för design för prestanda och skalbarhet. Om du inte har använt Azure Storage och table-tjänsten tidigare läser du Kom igång med Azure Table Storage med hjälp av .NET innan du läser resten av den här artikeln. Även om fokus för den här guiden ligger på tabelltjänsten innehåller den en diskussion om Azure Queue- och Blob-tjänsterna och hur du kan använda dem med tabelltjänsten.

Vad är tabelltjänsten? Som du kan förvänta dig av namnet använder tabelltjänsten ett tabellformat för att lagra data. I standardterminologin representerar varje rad i tabellen en entitet och kolumnerna lagrar de olika egenskaperna för den entiteten. Varje entitet har ett par nycklar för att unikt identifiera den och en tidsstämpelkolumn som tabelltjänsten använder för att spåra när entiteten senast uppdaterades. Tidsstämpeln tillämpas automatiskt och du kan inte skriva över tidsstämpeln manuellt med ett godtyckligt värde. Tabelltjänsten använder den senaste ändrade tidsstämpeln (LMT) för att hantera optimistisk samtidighet.

I följande exempel visas en enkel tabelldesign för att lagra anställda och avdelningsentiteter. Många av exemplen som visas senare i den här guiden baseras på den här enkla designen.

Hittills verkar dessa data likna en tabell i en relationsdatabas, där de viktigaste skillnaderna är de obligatoriska kolumnerna och möjligheten att lagra flera entitetstyper i samma tabell. Dessutom har var och en av de användardefinierade egenskaperna, till exempel FirstName eller Age , en datatyp, till exempel heltal eller sträng, precis som en kolumn i en relationsdatabas. Till skillnad från i en relationsdatabas innebär tabelltjänstens schemalösa karaktär att en egenskap inte behöver ha samma datatyp för varje entitet. Om du vill lagra komplexa datatyper i en enda egenskap måste du använda ett serialiserat format som JSON eller XML. Mer information om tabelltjänsten, till exempel datatyper som stöds, datumintervall som stöds, namngivningsregler och storleksbegränsningar finns i Förstå tabelltjänstdatamodellen.

Valet av PartitionKey och RowKey är grundläggande för en bra tabelldesign. Varje entitet som lagras i en tabell måste ha en unik kombination av PartitionKey och RowKey. Precis som med nycklar i en relationsdatabastabell indexeras värdena PartitionKey och RowKey för att skapa ett grupperat index för att aktivera snabba uppslag. Tabelltjänsten skapar dock inga sekundära index, så PartitionKey och RowKey är de enda indexerade egenskaperna. Några av de mönster som beskrivs i tabelldesignmönster visar hur du kan kringgå den här uppenbara begränsningen.

En tabell består av en eller flera partitioner, och många av de designbeslut du fattar handlar om att välja en lämplig PartitionKey och RowKey för att optimera din lösning. En lösning kan bestå av en enda tabell som innehåller alla dina entiteter ordnade i partitioner, men vanligtvis har en lösning flera tabeller. Tabeller hjälper dig att logiskt organisera dina entiteter, hjälpa dig att hantera åtkomst till data med hjälp av åtkomstkontrollistor och du kan släppa en hel tabell med en enda lagringsåtgärd.

Tabellpartitioner

Kontonamnet, tabellnamnet och PartitionKey identifierar tillsammans partitionen i lagringstjänsten där tabelltjänsten lagrar entiteten. Förutom att vara en del av adressschemat för entiteter definierar partitioner ett omfång för transaktioner (se Entitetsgrupptransaktioner nedan) och utgör grunden för hur tabelltjänsten skalar. Mer information om partitioner finns i checklista för prestanda och skalbarhet för Table Storage.

I tabelltjänsten servar en enskild nod en eller flera fullständiga partitioner och tjänsten skalas av dynamiskt belastningsutjämningspartitioner mellan noder. Om en nod är under belastning kan tabelltjänsten dela upp intervallet med partitioner som betjänas av noden till olika noder. När trafiken avtar kan tjänsten slå samman partitionsintervallen från tysta noder tillbaka till en enda nod.

Mer information om den interna informationen om table-tjänsten och i synnerhet hur tjänsten hanterar partitioner finns i dokumentet Microsoft Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency(Microsoft Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency).

Entitetsgrupptransaktioner

I tabelltjänsten är entitetsgrupptransaktioner (EGT) den enda inbyggda mekanismen för att utföra atomiska uppdateringar över flera entiteter. EGT kallas ibland även batchtransaktioner. EGT:erna kan endast användas på entiteter som lagras i samma partition (dvs. dela samma partitionsnyckel i en viss tabell). Så varje gång du behöver atomiska transaktionsbeteenden mellan flera entiteter måste du se till att dessa entiteter finns i samma partition. Detta är ofta en anledning till att behålla flera entitetstyper i samma tabell (och partition) och inte använda flera tabeller för olika entitetstyper. En enskild EGT kan fungera på högst 100 entiteter. Om du skickar flera samtidiga EGT för bearbetning är det viktigt att se till att dessa EGT inte fungerar på entiteter som är gemensamma för EGT: er. annars kan bearbetningen fördröjas.

Egts introducerar också en potentiell kompromiss som du kan utvärdera i din design. Att använda fler partitioner ökar alltså programmets skalbarhet, eftersom Azure har fler möjligheter till belastningsutjämningsbegäranden mellan noder. Men att använda fler partitioner kan begränsa programmets möjlighet att utföra atomiska transaktioner och upprätthålla stark konsekvens för dina data. Dessutom finns det specifika skalbarhetsmål på nivån för en partition som kan begränsa dataflödet för transaktioner som du kan förvänta dig för en enskild nod. Mer information om skalbarhetsmål för Azures standardlagringskonton finns i Skalbarhetsmål för standardlagringskonton. Mer information om skalbarhetsmål för tabelltjänsten finns i Skalbarhets- och prestandamål för Table Storage.

Överväganden för kapaciteter

Följande tabell beskriver kapacitets-, skalbarhets- och prestandamål för tabellagring.

Kostnadsöverväganden

Tabelllagring är relativt billigt, men du bör inkludera kostnadsuppskattningar för både kapacitetsanvändning och antalet transaktioner som en del av utvärderingen av en tabelltjänstlösning. I många scenarier är dock lagring av avnormaliserade eller duplicerade data för att förbättra lösningens prestanda eller skalbarhet en giltig metod. Mer information om priser finns i Prissättning för Azure Storage.

Nästa steg

• Mönster för tabelldesign
• Modelleringsrelationer
• Design för frågor
• Kryptera tabelldata
• Design för dataändring