Delen via

Ontwerp voor opvragen

Tabelserviceoplossingen kunnen leesintensief, schrijfintensief of een combinatie van de twee zijn. Dit artikel is gericht op de dingen die u in gedachten moet houden wanneer u uw Table-service ontwerpt om leesbewerkingen efficiënt te ondersteunen. Een ontwerp dat efficiënt leesbewerkingen ondersteunt, is doorgaans ook efficiënt voor schrijfbewerkingen. Er zijn echter aanvullende overwegingen waarmee u rekening moet houden bij het ontwerpen om schrijfbewerkingen te ondersteunen, die worden besproken in het artikel Ontwerpen voor gegevenswijziging.

Een goed uitgangspunt voor het ontwerpen van uw Table-serviceoplossing om u in staat te stellen gegevens efficiënt te lezen, is door te vragen 'Welke query's moet mijn toepassing uitvoeren om de gegevens op te halen die nodig zijn uit de Table-service?'

Opmerking

Met de Table-service is het belangrijk om het ontwerp vanaf het begin goed te krijgen, omdat het later lastig en kostbaar is om het te wijzigen. In een relationele database is het bijvoorbeeld vaak mogelijk om prestatieproblemen op te lossen door indexen toe te voegen aan een bestaande database: dit is geen optie met de Tabelservice.

Deze sectie is gericht op de belangrijkste problemen die u moet oplossen wanneer u uw tabellen ontwerpt voor het uitvoeren van query's. De onderwerpen die in deze sectie worden behandeld, zijn onder andere:

Hoe uw keuze voor PartitionKey en RowKey van invloed is op de prestaties van query's

In de volgende voorbeelden wordt ervan uitgegaan dat de tabelservice werknemersentiteiten opslaat met de volgende structuur (de meeste voorbeelden laten de eigenschap Timestamp voor duidelijkheid weg):

Kolomnaam Gegevenstype
PartitionKey (afdelingsnaam ) Touwtje
RowKey (werknemer-id) Touwtje
FirstName Touwtje
LastName Touwtje
Leeftijd Integer
EmailAddress Touwtje

In het artikel Overzicht van Azure Table Storage worden enkele van de belangrijkste functies van de Azure Table-service beschreven die direct invloed hebben op het ontwerpen van query's. Dit resulteert in de volgende algemene richtlijnen voor het ontwerpen van tabelservicequery's. Houd er rekening mee dat de filtersyntaxis die in de onderstaande voorbeelden wordt gebruikt afkomstig is van de Table-service REST API. Voor meer informatie, zie Query Entities.

  • Een puntquery is de meest efficiënte zoekactie die moet worden gebruikt en wordt aanbevolen te worden gebruikt voor zoekacties met een hoog volume of zoekacties waarvoor de laagste latentie is vereist. Een dergelijke query kan de indexen gebruiken om een afzonderlijke entiteit zeer efficiënt te vinden door zowel de PartitionKey - als RowKey-waarden op te geven. Bijvoorbeeld: $filter=(PartitionKey eq 'Sales') en (RowKey eq '2')
  • De op één na beste optie is een bereikquery die de PartitionKey gebruikt en filtert op een bereik van RowKey-waarden om meer dan één entiteit te retourneren. De partitionKey-waarde identificeert een specifieke partitie en de RowKey-waarden identificeren een subset van de entiteiten in die partitie. Bijvoorbeeld: $filter=PartitionKey eq 'Sales' en RowKey ge 'S' en RowKey lt 'T'
  • Het derde beste is een partitiescan die gebruikmaakt van de PartitionKey en filters op een andere niet-sleuteleigenschap en die meer dan één entiteit kan retourneren. De PartitionKey-waarde identificeert een specifieke partitie en de eigenschapswaarden selecteren voor een subset van de entiteiten in die partitie. Bijvoorbeeld: $filter=PartitionKey eq 'Sales' en LastName eq 'Smith'
  • Een tabelscan bevat niet de PartitionKey en is zeer inefficiënt omdat alle partities waaruit uw tabel bestaat, worden doorzocht voor eventuele overeenkomende entiteiten. Er wordt een tabelscan uitgevoerd, ongeacht of uw filter de RowKey gebruikt. Bijvoorbeeld: $filter=LastName eq 'Jones'
  • Query's die meerdere entiteiten retourneren, retourneren ze gesorteerd in de volgorde PartitionKey en RowKey . Als u wilt voorkomen dat de entiteiten in de client worden gebruikt, kiest u een RowKey die de meest voorkomende sorteervolgorde definieert.

Houd er rekening mee dat het gebruik van een 'of' om een filter op te geven op basis van RowKey-waarden resulteert in een partitiescan en niet wordt behandeld als een bereikquery. Daarom moet u query's vermijden die gebruikmaken van filters zoals: $filter=PartitionKey eq 'Sales' en (RowKey eq '121' of RowKey eq '322')

Zie voor voorbeelden van code aan de clientzijde die de Storage-clientbibliotheek gebruikt om efficiënte query's uit te voeren:

Zie voor voorbeelden van code aan de clientzijde die meerdere entiteitstypen kan verwerken die zijn opgeslagen in dezelfde tabel:

Een geschikte PartitionKey kiezen

Uw keuze voor PartitionKey moet in balans zijn met de noodzaak om het gebruik van entiteitsgroeptransacties (om consistentie te garanderen) ten opzichte van de vereiste om uw entiteiten over meerdere partities te distribueren (om een schaalbare oplossing te garanderen).

Aan de ene kant kunt u al uw entiteiten in één partitie opslaan, maar dit kan de schaalbaarheid van uw oplossing beperken en voorkomen dat de tabelservice verzoeken kan verdelen. In het andere extreme kunt u één entiteit per partitie opslaan, wat zeer schaalbaar zou zijn en waarmee de tabelservice aanvragen kan verdelen, maar waardoor u geen transacties van entiteitsgroepen kunt gebruiken.

Een ideale PartitionKey is een partitie waarmee u efficiënte query's kunt gebruiken en die voldoende partities heeft om ervoor te zorgen dat uw oplossing schaalbaar is. Normaal gesproken zult u merken dat uw entiteiten een geschikte eigenschap hebben die uw entiteiten over voldoende partities distribueert.

Opmerking

In een systeem waarin bijvoorbeeld informatie over gebruikers of werknemers wordt opgeslagen, kan UserID een goede PartitionKey zijn. Mogelijk hebt u verschillende entiteiten die een bepaalde gebruikers-id als partitiesleutel gebruiken. Elke entiteit waarin gegevens over een gebruiker worden opgeslagen, wordt gegroepeerd in één partitie, zodat deze entiteiten toegankelijk zijn via entiteitsgroeptransacties, terwijl ze nog steeds zeer schaalbaar zijn.

Er zijn aanvullende overwegingen in uw keuze voor PartitionKey die betrekking hebben op het invoegen, bijwerken en verwijderen van entiteiten. Zie Tabellen ontwerpen voor gegevenswijziging voor meer informatie.

Query's optimaliseren voor de Table-service

De Table-service indexeert uw entiteiten automatisch met behulp van de waarden PartitionKey en RowKey in één geclusterde index, vandaar de reden dat puntquery's het meest efficiënt zijn om te gebruiken. Er zijn echter geen andere indexen dan die op de geclusterde index op de PartitionKey en RowKey.

Veel ontwerpen moeten voldoen aan vereisten om opzoekacties van entiteiten mogelijk te maken op basis van meerdere criteria. Bijvoorbeeld het vinden van werknemersentiteiten op basis van e-mail, werknemer-id of achternaam. De patronen die worden beschreven in tabelontwerppatronen zijn van toepassing op deze typen vereisten en beschrijven manieren om te omzeilen dat de Tabelservice geen secundaire indexen biedt:

  • Secundair indexpatroon tussen partities : sla meerdere kopieën van elke entiteit op met behulp van verschillende RowKey-waarden (in dezelfde partitie) om snelle en efficiënte opzoekacties en alternatieve sorteervolgordes mogelijk te maken met behulp van verschillende RowKey-waarden .
  • Secundair indexpatroon tussen partities: sla meerdere kopieën van elke entiteit op met behulp van verschillende RowKey-waarden in afzonderlijke partities of in afzonderlijke tabellen om snelle en efficiënte opzoekacties en alternatieve sorteervolgordes mogelijk te maken met behulp van verschillende RowKey-waarden .
  • Patroon indexentiteiten : indexentiteiten onderhouden om efficiënte zoekopdrachten mogelijk te maken die lijsten met entiteiten retourneren.

Gegevens sorteren in de Tabelservice

De Table-service retourneert entiteiten die in oplopende volgorde zijn gesorteerd op basis van PartitionKey en vervolgens op RowKey. Deze sleutels zijn tekenreekswaarden en om ervoor te zorgen dat numerieke waarden correct worden gesorteerd, moet u ze converteren naar een vaste lengte en ze opvulen met nullen. Als de waarde van de werknemer-id die u als RowKey gebruikt bijvoorbeeld een geheel getal is, moet u werknemer-id 123 converteren naar 00000123.

Veel toepassingen hebben vereisten voor het gebruik van gegevens die in verschillende volgordes zijn gesorteerd: bijvoorbeeld het sorteren van werknemers op naam of op deelnamedatum. In de volgende patronen wordt uitgelegd hoe u alternatieve sorteervolgordes voor uw entiteiten kunt gebruiken:

  • Secundair indexpatroon tussen partities : sla meerdere kopieën van elke entiteit op met behulp van verschillende RowKey-waarden (in dezelfde partitie) om snelle en efficiënte opzoekacties en alternatieve sorteervolgordes mogelijk te maken met behulp van verschillende RowKey-waarden.
  • Secundair indexpatroon tussen partities: sla meerdere kopieën van elke entiteit op met behulp van verschillende RowKey-waarden in afzonderlijke partities in afzonderlijke tabellen om snelle en efficiënte zoekacties en alternatieve sorteervolgordes mogelijk te maken met behulp van verschillende RowKey-waarden.
  • Log tail-patroon : haal de n entiteiten op die het laatst aan een partitie zijn toegevoegd met behulp van een RowKey-waarde die in omgekeerde datum- en tijdvolgorde sorteert.

Volgende stappen