Schaalbare en beter bruikbare tabellen ontwerpen

Als u schaalbare en goed presterende tabellen wilt ontwerpen, moet u rekening houden met factoren zoals prestaties, schaalbaarheid en kosten. Als u eerder schema's voor relationele databases hebt ontworpen, zijn deze overwegingen bekend, maar hoewel er enkele overeenkomsten zijn tussen het opslagmodel van de Azure Table-service en relationele modellen, zijn er ook belangrijke verschillen. Deze verschillen leiden meestal tot verschillende ontwerpen die er contra-intuïtief of verkeerd uitzien voor iemand die bekend is met relationele databases, maar die zinvol zijn als u ontwerpt voor een NoSQL-sleutel-/waardearchief, zoals de Azure Table-service. Veel van uw ontwerpverschillen weerspiegelen het feit dat de Table-service is ontworpen ter ondersteuning van toepassingen op cloudschaal die miljarden entiteiten (of rijen in relationele databaseterminologie) aan gegevens kunnen bevatten of voor gegevenssets die grote transactievolumes moeten ondersteunen. Daarom moet u anders nadenken over hoe u uw gegevens opslaat en begrijpen hoe de Table-service werkt. Met een goed ontworpen NoSQL-gegevensarchief kan uw oplossing veel verder en tegen lagere kosten worden geschaald dan een oplossing die gebruikmaakt van een relationele database. Deze handleiding helpt u bij deze onderwerpen.

Over de Azure Table-service

In deze sectie worden enkele van de belangrijkste functies van de Table-service besproken die met name relevant zijn voor het ontwerpen van prestaties en schaalbaarheid. Als u niet eerder met Azure Storage en de Table-service werkt, leest u eerst Aan de slag met Azure Table Storage met behulp van .NET voordat u de rest van dit artikel leest. Hoewel de focus van deze handleiding ligt op de Table-service, bevat deze een bespreking van de Azure Queue- en Blob-services en hoe u deze kunt gebruiken met de Table-service.

Wat is de Table-service? Zoals u van de naam mag verwachten, gebruikt de Tabelservice een tabellaire indeling om gegevens op te slaan. In de standaardterminologie vertegenwoordigt elke rij van de tabel een entiteit en worden in de kolommen de verschillende eigenschappen van die entiteit opgeslagen. Elke entiteit heeft een paar sleutels om de entiteit uniek te identificeren en een tijdstempelkolom die door de Tabelservice wordt gebruikt om bij te houden wanneer de entiteit voor het laatst is bijgewerkt. De tijdstempel wordt automatisch toegepast en u kunt de tijdstempel niet handmatig overschrijven met een willekeurige waarde. De Table-service gebruikt dit laatst gewijzigde tijdstempel (LMT) om optimistische gelijktijdigheid te beheren.

In het volgende voorbeeld ziet u een eenvoudig tabelontwerp voor het opslaan van werknemers- en afdelingsentiteiten. Veel van de voorbeelden die verderop in deze handleiding worden weergegeven, zijn gebaseerd op dit eenvoudige ontwerp.

Tot nu toe lijken deze gegevens op een tabel in een relationele database met als belangrijkste verschillen de verplichte kolommen en de mogelijkheid om meerdere entiteitstypen in dezelfde tabel op te slaan. Bovendien heeft elk van de door de gebruiker gedefinieerde eigenschappen, zoals Voornaam of Leeftijd , een gegevenstype, zoals een geheel getal of tekenreeks, net als een kolom in een relationele database. Hoewel anders dan in een relationele database, betekent de schemaloze aard van de Tabelservice dat een eigenschap niet hetzelfde gegevenstype voor elke entiteit hoeft te hebben. Als u complexe gegevenstypen in één eigenschap wilt opslaan, moet u een geserialiseerde indeling gebruiken, zoals JSON of XML. Zie Inzicht in het tabelservicegegevensmodel voor meer informatie over de tabelservice, zoals ondersteunde gegevenstypen, ondersteunde datumbereiken, naamgevingsregels en groottebeperkingen.

Uw keuze voor PartitionKey en RowKey is essentieel voor een goed tabelontwerp. Elke entiteit die in een tabel is opgeslagen, moet een unieke combinatie van PartitionKey en RowKey hebben. Net als bij sleutels in een relationele databasetabel worden de waarden PartitionKey en RowKey geïndexeerd om een geclusterde index te maken om snelle zoekacties mogelijk te maken. De Tabelservice maakt echter geen secundaire indexen, dus PartitionKey en RowKey zijn de enige geïndexeerde eigenschappen. Enkele van de patronen die worden beschreven in Tabelontwerppatronen laten zien hoe u deze schijnbare beperking kunt omzeilen.

Een tabel bestaat uit een of meer partities en veel van de ontwerpbeslissingen die u neemt, hebben te maken met het kiezen van een geschikte PartitionKey en RowKey om uw oplossing te optimaliseren. Een oplossing kan bestaan uit één tabel die al uw entiteiten in partities bevat, maar meestal heeft een oplossing meerdere tabellen. Tabellen helpen u bij het logisch organiseren van uw entiteiten, helpen u bij het beheren van de toegang tot de gegevens met behulp van toegangsbeheerlijsten en u kunt een hele tabel verwijderen met één opslagbewerking.

Tabelpartities

De accountnaam, tabelnaam en PartitionKey identificeren samen de partitie binnen de opslagservice waar de tabelservice de entiteit opslaat. Partities maken niet alleen deel uit van het adresseringsschema voor entiteiten, maar definiëren ook een bereik voor transacties (zie Entiteitsgroeptransacties hieronder) en vormen de basis voor de schaal van de tabelservice. Zie Controlelijst voor prestaties en schaalbaarheid voor Table Storage voor meer informatie over partities.

In de Table-service biedt een afzonderlijk knooppunt een of meer volledige partities en wordt de service geschaald door partities dynamisch te verdelen over knooppunten. Als een knooppunt wordt belast, kan de tabelservice het bereik van partities dat door dat knooppunt wordt onderhouden , splitsen op verschillende knooppunten; wanneer het verkeer afneemt, kan de service de partitiebereiken van stille knooppunten samenvoegen tot één knooppunt.

Zie de papieren Microsoft Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency (Een maximaal beschikbare cloudopslagservice met sterke consistentie) voor meer informatie over de interne details van de Table-service en met name hoe de service partities beheert.

Entiteitsgroeptransacties

In de Tabelservice zijn Entiteitsgroeptransacties (EGT's) het enige ingebouwde mechanisme voor het uitvoeren van atomische updates voor meerdere entiteiten. EGT's worden soms ook batchtransacties genoemd. EGT's kunnen alleen worden uitgevoerd op entiteiten die zijn opgeslagen in dezelfde partitie (dat wil gezegd, dezelfde partitiesleutel delen in een bepaalde tabel). Dus wanneer u atomisch transactioneel gedrag tussen meerdere entiteiten vereist, moet u ervoor zorgen dat deze entiteiten zich in dezelfde partitie bevinden. Dit is vaak een reden om meerdere entiteitstypen in dezelfde tabel (en partitie) te houden en niet meerdere tabellen voor verschillende entiteitstypen te gebruiken. Eén EGT kan worden uitgevoerd op maximaal 100 entiteiten. Als u meerdere gelijktijdige EGT's voor verwerking indient, is het belangrijk om ervoor te zorgen dat deze EGT's niet werken op entiteiten die gemeenschappelijk zijn in EGT's; anders kan de verwerking worden vertraagd.

EGT's introduceren ook een mogelijke afweging die u in uw ontwerp kunt evalueren. Dat wil dat het gebruik van meer partities de schaalbaarheid van uw toepassing verhoogt, omdat Azure meer mogelijkheden heeft voor taakverdelingsaanvragen over knooppunten. Maar het gebruik van meer partities kan de mogelijkheid van uw toepassing beperken om atomische transacties uit te voeren en sterke consistentie voor uw gegevens te behouden. Bovendien zijn er specifieke schaalbaarheidsdoelen op het niveau van een partitie die de doorvoer van transacties die u voor één knooppunt kunt verwachten, kan beperken. Zie Schaalbaarheidsdoelen voor standaardopslagaccounts voor meer informatie over schaalbaarheidsdoelen voor Azure Standard Storage-accounts. Zie Schaalbaarheids- en prestatiedoelen voor de Table service voor meer informatie over de schaalbaarheidsdoelen voor Table-opslag.

Overwegingen bij capaciteitsbepaling

In de volgende tabel worden de capaciteit, schaalbaarheid en prestatiedoelen voor Table Storage beschreven.

Kostenoverwegingen

Table Storage is relatief goedkoop, maar u moet kostenramingen voor zowel capaciteitsgebruik als het aantal transacties opnemen als onderdeel van uw evaluatie van een Table-serviceoplossing. In veel scenario's is het opslaan van gedenormaliseerde of dubbele gegevens om de prestaties of schaalbaarheid van uw oplossing te verbeteren echter een geldige benadering. Zie Prijzen voor Azure Storage voor meer informatie over prijzen.

Volgende stappen

• Tabelontwerppatronen
• Relaties modelleren
• Ontwerp voor query's
• Tabelgegevens versleutelen
• Ontwerp voor gegevenswijziging