Schaalbare en beter bruikbare tabellen ontwerpen
Tip
De inhoud in dit artikel is van toepassing op de oorspronkelijke versie van Azure Table Storage. Dezelfde concepten zijn echter van toepassing op de nieuwere Azure Cosmos DB for Table, die betere prestaties en beschikbaarheid, wereldwijde distributie en automatische secundaire indexen biedt. Deze is ook beschikbaar in een serverloze modus op basis van verbruik. Er zijn enkele functieverschillen tussen table-API in Azure Cosmos DB en Azure Table Storage. Zie Azure Cosmos DB for Table voor meer informatie. Voor het gemak van ontwikkeling bieden we nu een geïntegreerde Azure Tables SDK die kan worden gebruikt om zowel Azure Table Storage als Azure Cosmos DB for Table te targeten.
Als u schaalbare en performante 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 er zijn enkele overeenkomsten tussen het opslagmodel van de Azure Table-service en relationele modellen, maar er zijn ook belangrijke verschillen. Deze verschillen leiden doorgaans tot verschillende ontwerpen die kunnen lijken op teller-intuïtief of onjuist voor iemand die bekend is met relationele databases, maar toch 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 cloudtoepassingen die miljarden entiteiten (of rijen in relationele databaseterminologie) van gegevens kunnen bevatten of voor gegevenssets die grote transactievolumes moeten ondersteunen. Daarom moet u anders nadenken over hoe u uw gegevens opslaat en begrijpt hoe de Table-service werkt. Een goed ontworpen NoSQL-gegevensarchief kan uw oplossing veel verder schalen en tegen lagere kosten 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 gemarkeerd die met name relevant zijn voor het ontwerpen voor prestaties en schaalbaarheid. Als u geen kennis hebt met Azure Storage en de Table-service, 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 op de Table-service ligt, 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 kunt verwachten van de naam, gebruikt de Tabelservice een tabellaire indeling om gegevens op te slaan. In de standaardterminologie vertegenwoordigt elke rij van de tabel een entiteit en slaan de kolommen de verschillende eigenschappen van die entiteit op. Elke entiteit heeft een paar sleutels om deze uniek te identificeren en een tijdstempelkolom die door de Table-service 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 deze laatst gewijzigde tijdstempel (LMT) om optimistische gelijktijdigheid te beheren.
Notitie
De REST API-bewerkingen van de Table-service retourneren ook een ETag-waarde die is afgeleid van het LMT. In dit document worden de termen ETag en LMT door elkaar gebruikt, omdat ze verwijzen naar dezelfde onderliggende gegevens.
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.
| PartitionKey | RowKey | Tijdstempel | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Marketing | 00001 | 2014-08-22T00:50:32Z |
| ||||||||
| Marketing | 00002 | 2014-08-22T00:50:34Z |
| ||||||||
| Marketing | Afdeling | 2014-08-22T00:50:30Z |
|
||||||||
| Verkoop | 00010 | 2014-08-22T00:50:44Z |
|
Tot nu toe lijken deze gegevens op een tabel in een relationele database, waarbij de belangrijkste verschillen de verplichte kolommen zijn en de mogelijkheid om meerdere entiteitstypen in dezelfde tabel op te slaan. Bovendien heeft elk van de door de gebruiker gedefinieerde eigenschappen, zoals FirstName of Age , een gegevenstype, zoals geheel getal of tekenreeks, net als een kolom in een relationele database. Hoewel in tegenstelling tot een relationele database, betekent het schemaloze karakter van de Table-service 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 fundamenteel 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 Table-service maakt echter geen secundaire indexen, dus PartitionKey en RowKey zijn de enige geïndexeerde eigenschappen. Sommige 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, gaan over het kiezen van een geschikte PartitionKey en RowKey om uw oplossing te optimaliseren. Een oplossing kan bestaan uit één tabel die al uw entiteiten bevat die zijn ingedeeld in partities, maar meestal heeft een oplossing meerdere tabellen. Tabellen helpen u uw entiteiten logisch te organiseren, u te helpen de toegang tot de gegevens te beheren met behulp van toegangsbeheerlijsten en u kunt een hele tabel verwijderen met één opslagbewerking.
Tabelpartities
De accountnaam, tabelnaam en PartitionKey identificeren samen de partitie in de opslagservice waar de tabelservice de entiteit opslaat. Naast het adresseringsschema voor entiteiten definiëren partities een bereik voor transacties (zie Entiteitsgroeptransacties hieronder) en vormen ze de basis van de schaal van de tabelservice. Zie de controlelijst prestaties en schaalbaarheid voor Table Storage voor meer informatie over partities.
In de Table-service worden afzonderlijke knooppuntservices een of meer volledige partities en de service geschaald door dynamisch taakverdelingspartities tussen knooppunten. Als een knooppunt wordt belast, kan de tabelservice het bereik van partities splitsen die door dat knooppunt worden onderhouden op verschillende knooppunten. Wanneer verkeer afgaat, kan de service de partitiebereiken samenvoegen van stille knooppunten terug naar één knooppunt.
Zie het document Microsoft Azure Storage: 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 Table-service zijn Entiteitsgroeptransacties (EGT's) het enige ingebouwde mechanisme voor het uitvoeren van atomische updates voor meerdere entiteiten. EGT's worden soms ook wel batchtransacties genoemd. EGT's kunnen alleen worden uitgevoerd op entiteiten die zijn opgeslagen in dezelfde partitie (dat wil gezegd dezelfde partitiesleutel in een bepaalde tabel delen). Dus wanneer u atomisch transactioneel gedrag voor meerdere entiteiten nodig hebt, 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 bewaren en niet meerdere tabellen te gebruiken voor verschillende entiteitstypen. Eén EGT kan maximaal 100 entiteiten gebruiken. Als u meerdere gelijktijdige EGT's verzendt voor verwerking, is het belangrijk om ervoor te zorgen dat deze EGT's niet werken op entiteiten die gemeenschappelijk zijn tussen EGT's; anders kan de verwerking worden vertraagd.
EGT's introduceren ook een mogelijke afweging die u in uw ontwerp kunt evalueren. Dat wil gezegd, het gebruik van meer partities verhoogt de schaalbaarheid van uw toepassing, omdat Azure meer mogelijkheden heeft voor taakverdelingsaanvragen tussen 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 Standard Storage-accounts in Azure voor meer informatie over schaalbaarheidsdoelen voor Standaardopslagaccounts. 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.
| Bron | Doel |
|---|---|
| Aantal tabellen in een Azure Storage-account | Alleen beperkt door de capaciteit van het opslagaccount |
| Aantal partities in een tabel | Alleen beperkt door de capaciteit van het opslagaccount |
| Aantal entiteiten in een partitie | Alleen beperkt door de capaciteit van het opslagaccount |
| Maximale grootte van één tabel | 500 TiB |
| Maximale grootte van één entiteit, inclusief alle eigenschapswaarden | 1 MiB |
| Maximum aantal eigenschappen in een tabelentiteit | 255 (inclusief de drie systeemeigenschappen, PartitionKey, RowKey en Timestamp) |
| Maximale totale grootte van een afzonderlijke eigenschap in een entiteit | Verschilt per eigenschapstype. Zie voor meer informatie Eigenschapstypen in Het gegevensmodel van de tabelservice. |
| Grootte van de PartitionKey | Een tekenreeks van maximaal 1024 tekens |
| Grootte van de RowKey | Een tekenreeks van maximaal 1024 tekens |
| Grootte van een transactie van entiteitsgroepen | Een transactie kan maximaal 100 entiteiten bevatten en de payload moet kleiner zijn dan 4 MiB. Een transactie van entiteitsgroepen mag slechts één keer een update naar een entiteit bevatten. |
| Maximaal aantal opgeslagen toegangsbeleidsregels per tabel | 5 |
| Maximum aantal aanvragen per opslagaccount | 20.000 transacties per seconde, uitgaande van een entiteitsgrootte van 1 KiB |
| Doeldoorvoer voor één tabelpartitie (entiteiten van 1 KiB) | Maximaal 2000 entiteiten per seconde |
Kostenoverwegingen
Table Storage is relatief goedkoop, maar u moet kostenramingen opnemen voor zowel capaciteitsgebruik als het aantal transacties als onderdeel van uw evaluatie van een Table Service-oplossing. In veel scenario's is het opslaan van gedenormaliseerde of dubbele gegevens echter een geldige benadering om de prestaties of schaalbaarheid van uw oplossing te verbeteren. Zie Prijzen voor Azure Storage voor meer informatie over prijzen.