Controlelijst voor prestaties en schaalbaarheid van Table-opslag
Microsoft heeft veel bewezen procedures ontwikkeld voor het ontwikkelen van hoogwaardige toepassingen met Table Storage. Deze controlelijst vermeldt de belangrijkste procedures die ontwikkelaars kunnen volgen om de prestaties te optimaliseren. Houd rekening met deze procedures tijdens het ontwerpen van uw toepassing en tijdens het hele proces.
Azure Storage bevat schaalbaarheids- en prestatiedoelen voor capaciteit, transactiesnelheid en bandbreedte. Zie Schaalbaarheids- en prestatiedoelen voor standaardopslagaccounts en Schaalbaarheids- en prestatiedoelen voor Table-opslag voor meer informatie over schaalbaarheidsdoelen van Azure Storage.
Checklijst
In dit artikel worden bewezen procedures voor prestaties georganiseerd in een controlelijst die u kunt volgen tijdens het ontwikkelen van uw Table-opslagtoepassing.
Schaalbaarheidsdoelen
Als uw toepassing een van de schaalbaarheidsdoelen nadert of overschrijdt, kunnen er meer latenties of beperkingen optreden voor transacties. Wanneer Azure Storage uw toepassing beperkt, begint de service met het retourneren van de foutcodes 503 (server bezet) of 500 (time-out voor bewerking). Het vermijden van deze fouten door binnen de grenzen van de schaalbaarheidsdoelen te blijven vormt een belangrijk onderdeel van het verbeteren van de prestaties van uw toepassing.
Zie Schaalbaarheids- en prestatiedoelen voor de Table service voor meer informatie over de schaalbaarheidsdoelen voor Table-opslag.
Maximum aantal opslagaccounts
Als u het maximumaantal opslagaccounts nadert dat is toegestaan voor een bepaalde combinatie van abonnement/regio, maakt u dan gebruik van meerdere opslagaccounts om in een shard op te slaan, waarmee de hoeveelheid inkomend/uitgaand verkeer, het aantal I/O-bewerkingen per seconde (IOPS) of de capaciteit wordt verhoogd? In dit scenario raadt Microsoft u aan gebruik te maken van verhoogde limieten voor opslagaccounts om zo mogelijk het aantal opslagaccounts te beperken dat is vereist voor uw workload. Neem contact op met Ondersteuning voor Azure om verhoogde limieten voor uw opslagaccount aan te vragen.
Capaciteits- en transactiedoelen
Als uw toepassing de schaalbaarheidsdoelen voor één opslagaccount nadert, kunt u een van de volgende benaderingen overwegen:
- Bekijk de workload die ervoor zorgt dat uw toepassing het schaalbaarheidsdoel benadert of overschrijdt. Kunt u het op een andere manier ontwerpen waardoor u minder bandbreedte of capaciteit of minder transacties gebruikt?
- Als uw toepassing een van de schaalbaarheidsdoelen moet overschrijden, maakt u meerdere opslagaccounts en partitioneert u uw toepassingsgegevens over deze meerdere opslagaccounts. Als u dit patroon gebruikt, moet u ervoor zorgen dat u uw toepassing zo ontwerpt, dat u in de toekomst meer opslagaccounts kunt toevoegen voor de taakverdeling. Opslagaccounts zelf hebben geen andere kosten dan uw gebruik in termen van opgeslagen gegevens, gemaakte transacties of overgedragen gegevens.
- Als uw toepassing de bandbreedtedoelen nadert, kunt u de gegevens aan de clientzijde comprimeren om de bandbreedte te verminderen die nodig is om de gegevens naar Azure Storage te verzenden. Hoewel het comprimeren van gegevens bandbreedte kan besparen en de netwerkprestaties kan verbeteren, kan dit ook negatieve gevolgen hebben voor de prestaties. Evalueer de invloed op de prestaties van de extra verwerkingsvereisten voor de compressie en decompressie van gegevens aan de clientzijde. Houd er rekening mee dat het door het opslaan van gecomprimeerde gegevens lastiger wordt om problemen op te lossen, aangezien het lastiger kan zijn om de gegevens te bekijken met behulp van standaardhulpprogramma's.
- Als uw toepassing de schaalbaarheidsdoelen nadert, moet u ervoor zorgen dat u een exponentieel uitstel gebruikt voor nieuwe pogingen. U kunt het beste voorkomen dat u de schaalbaarheidsdoelen bereikt door de aanbevelingen te implementeren die in dit artikel worden beschreven. Als u echter een exponentieel uitstel gebruikt voor nieuwe pogingen, voorkomt u dat uw toepassing snel opnieuw pogingen onderneemt, waarmee de beperkingen ernstiger kunnen worden. Zie de sectie met de titel Time-out- en server-bezetfouten voor meer informatie.
Doelen voor gegevensbewerkingen
Azure Storage-taakverdelingen naarmate het verkeer naar uw opslagaccount toeneemt, maar als het verkeer plotselinge bursts vertoont, kunt u dit volume mogelijk niet onmiddellijk ophalen. U zult tijdens de piek naar verwachting met beperkingen en/of time-outs te maken krijgen, aangezien Azure Storage automatisch voor een taakverdeling voor uw tabel zorgt. Langzaam verhogen biedt doorgaans betere resultaten, omdat het systeem dan de tijd heeft om op de juiste manier de taken te verdelen.
Entiteiten per seconde (opslagaccount)
De schaalbaarheidslimiet voor het openen van tabellen is maximaal 20.000 entiteiten (1 KB elk) per seconde voor een account. In het algemeen geldt dat elke entiteit die wordt ingevoegd, bijgewerkt, verwijderd of gescand wordt meegeteld voor dit doel. Een batch invoegen die 100 entiteiten bevat, telt dus als 100 entiteiten. Een query die 1000 entiteiten scant en 5 retourneert, telt als 1000 entiteiten.
Entiteiten per seconde (partitie)
Binnen één partitie zijn de schaalbaarheidsdoelen voor het openen van tabellen 2000 entiteiten (1 KB elk) per seconde, met dezelfde telling als beschreven in de vorige sectie.
Netwerken
De beperkingen van het fysieke netwerk van de toepassing kunnen een aanzienlijke invloed hebben op de prestaties. In de volgende secties worden enkele beperkingen beschreven die gebruikers kunnen tegenkomen.
Netwerkmogelijkheden van de client
De bandbreedte en de kwaliteit van de netwerkkoppeling spelen een belangrijke rol in prestaties van toepassingen, zoals beschreven in de volgende secties.
Doorvoer
Voor bandbreedte is het probleem vaak de mogelijkheden van de client. Grotere Azure-exemplaren hebben NIC's met een grotere capaciteit. U moet dus overwegen een grotere exemplaar of meer VM's te gebruiken als u hogere netwerklimieten voor één computer nodig hebt. Als u toegang hebt tot Azure Storage vanuit een on-premises toepassing, is dezelfde regel van toepassing: inzicht in de netwerkmogelijkheden van het clientapparaat en de netwerkverbinding met de Azure Storage-locatie en verbeter deze indien nodig of ontwerp uw toepassing om binnen hun mogelijkheden te werken.
Kwaliteit van de koppeling
Houd er net als bij elk netwerkgebruik rekening mee dat netwerkomstandigheden die resulteren in fouten en pakketverlies de effectieve doorvoer vertraagt. Het gebruik van WireShark of NetMon kan helpen bij het vaststellen van dit probleem.
Locatie
Wanneer u de client dicht bij de server plaatst, levert dit in een gedistribueerde omgeving de beste prestaties op. Als u toegang wilt tot Azure Storage met de laagste latentie, bevindt de beste locatie voor uw client zich in dezelfde Azure-regio. Als u bijvoorbeeld een Azure-web-app hebt die gebruikmaakt van Azure Storage, plaatst u deze beide binnen één regio, zoals US - west of Azië - zuidoost. Wanneer u resources bij elkaar plaatst, vermindert u de latentie en de kosten, omdat het bandbreedtegebruik binnen één regio gratis is.
Als clienttoepassingen toegang krijgen tot Azure Storage, maar niet worden gehost in Azure, zoals apps voor mobiele apparaten of on-premises bedrijfsservices, kan het zoeken van het opslagaccount in een regio in de buurt van die clients de latentie verminderen. Als uw clients breed worden gedistribueerd (bijvoorbeeld sommige in Noord-Amerika en sommige in Europa), kunt u een opslagaccount per regio gebruiken. Deze aanpak is eenvoudiger te implementeren als de gegevens die in de toepassingsarchieven worden opgeslagen specifiek zijn voor afzonderlijke gebruikers en geen gegevens hoeven te worden gerepliceerd tussen opslagaccounts.
SAS en CORS
Stel dat u code moet machtigen zoals JavaScript dat wordt uitgevoerd in de webbrowser van een gebruiker of in een app op een mobiele telefoon om toegang te krijgen tot gegevens in Azure Storage. Een aanpak is om een servicetoepassing te compileren die als een proxy fungeert. Het apparaat van de gebruiker wordt geverifieerd bij de service, die op zijn beurt toegang tot Azure Storage-resources verleent. Op deze manier kunt u voorkomen dat de sleutels van uw opslagaccount op onveilige apparaten worden weergegeven. Met deze benadering wordt echter een aanzienlijke overhead op de servicetoepassing geplaatst, omdat alle gegevens die worden overgedragen tussen het apparaat van de gebruiker en Azure Storage via de servicetoepassing moeten worden doorgegeven.
U kunt voorkomen dat een servicetoepassing wordt gebruikt als een proxy voor Azure Storage met behulp van Shared Access Signatures (SAS). Met SAS kunt u het apparaat van uw gebruiker in staat stellen om aanvragen rechtstreeks bij Azure Storage in te dienen met behulp van een beperkt toegangstoken. Als een gebruiker bijvoorbeeld een foto wil uploaden naar uw toepassing, kan uw servicetoepassing een SAS genereren en deze verzenden naar het apparaat van de gebruiker. Het SAS-token kan toestemming geven om naar een Azure Storage-resource te schrijven gedurende een opgegeven tijdsinterval, waarna het SAS-token verloopt. Zie Beperkte toegang verlenen tot Azure Storage-resources via SAS (Shared Access Signatures) voor meer informatie over SAS.
Normaal gesproken staat een webbrowser JavaScript niet toe op een pagina die wordt gehost door een website op het ene domein om bepaalde bewerkingen, zoals schrijfbewerkingen, uit te voeren naar een ander domein. Op basis van dit beleid, dat bekend staat als 'beleid voor zelfde oorsprong', wordt voorkomen dat een schadelijk script op één pagina de toegang tot gegevens op een andere webpagina kan verkrijgen. Hetzelfde 'beleid voor zelfde oorsprong' kan echter een beperking zijn bij het compileren van een oplossing in de cloud. Cross-Origin Resource Sharing (CORS) is een browserfunctie waarmee het doeldomein van het brondomein afkomstige aanvragen kan doorgeven aan een vertrouwde browser.
Stel bijvoorbeeld dat een webtoepassing die in Azure wordt uitgevoerd een aanvraag voor een resource indient bij een Azure Storage-account. De webtoepassing is het brondomein en het opslagaccount is het doeldomein. U kunt CORS voor elk van de Azure Storage-services configureren om met de webbrowser aanvragen door te geven vanuit het brondomein dat worden vertrouwd door Azure Storage. Zie CORS-ondersteuning (cross-origin resource sharing) voor Azure Storage voor meer informatie over CORS.
Met SAS en CORS kunt u voorkomen dat uw webtoepassing onnodig wordt belast.
Batchtransacties
De Table service ondersteunt batchtransacties op entiteiten die zich in dezelfde tabel bevinden en deel uitmaken van dezelfde partitiegroep. Zie Entiteitsgroepstransacties uitvoeren voor meer informatie.
.NET-configuratie
Voor projecten die .NET Framework gebruiken, worden in deze sectie enkele snelle configuratie-instellingen vermeld die u kunt gebruiken om aanzienlijke prestatieverbeteringen aan te brengen. Als u een andere taal dan .NET gebruikt, controleert u of vergelijkbare concepten van toepassing zijn in de gekozen taal.
De standaardverbindingslimiet verhogen
Notitie
Deze sectie is van toepassing op projecten die gebruikmaken van .NET Framework, omdat groepsgewijze verbindingen worden beheerd door de ServicePointManager-klasse. .NET Core heeft een aanzienlijke wijziging in het beheer van verbindingsgroepen geïntroduceerd, waarbij verbindingspooling plaatsvindt op httpClient-niveau en de poolgrootte niet standaard wordt beperkt. Dit betekent dat HTTP-verbindingen automatisch worden geschaald om te voldoen aan uw workload. Het gebruik van de nieuwste versie van .NET wordt, indien mogelijk, aanbevolen om te profiteren van prestatieverbeteringen.
Voor projecten die .NET Framework gebruiken, kunt u de volgende code gebruiken om de standaardverbindingslimiet (meestal 2 in een clientomgeving of 10 in een serveromgeving) te verhogen tot 100. Normaal gesproken moet u de waarde instellen op ongeveer het aantal threads dat door uw toepassing wordt gebruikt. Stel de verbindingslimiet in voordat u verbindingen opent.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Zie de documentatie voor andere programmeertalen om te bepalen hoe de verbindingslimiet moet worden ingesteld.
Minimumaantal threads verhogen
Als u synchrone aanroepen samen met asynchrone taken gebruikt, kunt u het aantal threads in de threadgroep verhogen:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Zie de methode ThreadPool.SetMinThreads voor meer informatie.
Niet-gebonden parallelle uitvoering
Hoewel parallelle uitvoering handig kan zijn voor prestaties, moet u voorzichtig zijn met het gebruik van niet-afhankelijke parallelle uitvoering, wat betekent dat er geen limiet is afgedwongen voor het aantal threads of parallelle aanvragen. Zorg ervoor dat u parallelle aanvragen beperkt tot het uploaden of downloaden van gegevens, om toegang te krijgen tot meerdere partities in hetzelfde opslagaccount of om toegang te krijgen tot meerdere items in dezelfde partitie. Als parallelle uitvoering niet is gebonden, kan uw toepassing de mogelijkheden van het clientapparaat of de schaalbaarheidsdoelen van het opslagaccount overschrijden, wat resulteert in langere latenties en bandbreedtebeperking.
Clientbibliotheken en hulpprogramma's
Gebruik altijd de nieuwste clientbibliotheken en hulpprogramma's van Microsoft voor de beste prestaties. Azure Storage-clientbibliotheken zijn beschikbaar voor verschillende talen. Azure Storage biedt ook ondersteuning voor PowerShell en Azure CLI. Microsoft ontwikkelt deze clientbibliotheken en hulpprogramma's actief met het oog op de prestaties, houdt ze up-to-date met de nieuwste serviceversies en zorgt ervoor dat ze een groot aantal van de bewezen uitvoeringspraktijken intern verwerken.
Servicefouten afhandelen
Azure Storage retourneert een fout wanneer de service een aanvraag niet kan verwerken. Inzicht in de fouten die door Azure Storage in een bepaald scenario worden geretourneerd, is handig voor het optimaliseren van de prestaties.
Time-out- en server-bezetfouten
Azure Storage kan uw toepassing beperken als deze de schaalbaarheidslimieten nadert. In sommige gevallen kan Azure Storage een aanvraag mogelijk niet verwerken vanwege een tijdelijke voorwaarde. In beide gevallen kan de service een fout 503 (server bezet) of 500 (time-out) retourneren. Deze fouten kunnen zich ook voordoen als de service gegevenspartities opnieuw moet verdelen voor een hogere doorvoer. De clienttoepassing moet meestal de bewerking opnieuw uitvoeren die een van deze fouten heeft veroorzaakt. Als Azure Storage uw toepassing echter beperkt omdat deze de schaalbaarheidsdoelen overschrijdt, of zelfs als de service de aanvraag om een andere reden niet kon verwerken, kunnen agressieve nieuwe pogingen het probleem verergeren. Het gebruik van een beleid voor opnieuw proberen met exponentieel uitstel wordt aanbevolen. De clientbibliotheken zijn standaard ingesteld op dit gedrag. Uw toepassing kan het bijvoorbeeld na 2 seconden opnieuw proberen, dan 4 seconden, vervolgens 10 seconden, dan 30 seconden en vervolgens volledig opgeven. Op deze manier vermindert uw toepassing de belasting van de service aanzienlijk, in plaats van verergerend gedrag te vertonen dat kan leiden tot aanvraagbeperking.
Verbinding maken iviteitsfouten kunnen onmiddellijk opnieuw worden geprobeerd, omdat ze niet het gevolg zijn van beperking en naar verwachting tijdelijk zijn.
Fouten waarbij geen nieuwe pogingen mogelijk zijn
De clientbibliotheken verwerken nieuwe pogingen met een inzicht in welke fouten opnieuw kunnen worden geprobeerd en wat niet mogelijk is. Als u de Azure Storage REST API echter rechtstreeks aanroept, zijn er enkele fouten die u niet opnieuw moet proberen. Een 400-fout (ongeldige aanvraag) geeft bijvoorbeeld aan dat de clienttoepassing een aanvraag heeft verzonden die niet kan worden verwerkt omdat deze niet in het verwachte formulier stond. Het opnieuw verzenden van deze aanvraag resulteert elke keer in hetzelfde antwoord, dus er is geen punt om het opnieuw te proberen. Als u de Azure Storage REST API rechtstreeks aanroept, moet u op de hoogte zijn van mogelijke fouten en of ze opnieuw moeten worden geprobeerd.
Zie Status en foutcodes voor meer informatie over Azure Storage-foutcodes.
Configuration
In deze sectie worden verschillende snelle configuratie-instellingen weergegeven die u kunt gebruiken om belangrijke verbeteringen in de prestaties van de Table service aan te brengen:
JSON gebruiken
Vanaf Storage-serviceversie 2013-08-15 ondersteunt de Table service het gebruik van JSON in plaats van de op XML gebaseerde AtomPub-indeling voor het overdragen van tabelgegevens. Het gebruik van JSON kan de payloadgrootte tot wel 75% verminderen en kan de prestaties van uw toepassing aanzienlijk verbeteren.
Zie voor meer informatie het bericht Microsoft Azure Tables: Introducing JSON and Payload Format for Table Service Operations.
Nagle uitschakelen
Het Nagle-algoritme is breed geïmplementeerd in TCP/IP-netwerken om de netwerkprestaties te verbeteren. Het is echter niet optimaal in alle omstandigheden (zoals zeer interactieve omgevingen). Het Nagle-algoritme heeft een negatieve invloed op de prestaties van aanvragen voor de Azure Table service, en moet zo mogelijk worden uitgeschakeld.
Schema
Hoe u uw gegevens weergeeft en opvraagt, is de belangrijkste factor die van invloed is op de prestaties van de Table service. Hoewel elke toepassing verschilt, wordt in deze sectie een overzicht van enkele algemene bewezen procedures besproken die betrekking hebben op:
- Tabelontwerp
- Efficiënte query's
- Efficiënte updates van gegevens
Tabellen en partities
Tabellen worden onderverdeeld in partities. Elke entiteit die is opgeslagen in een partitie deelt dezelfde partitiesleutel en heeft een unieke rijsleutel om deze te identificeren binnen die partitie. Partities bieden voordelen, maar kunnen ook voor schaalbaarheidslimieten zorgen.
- Voordelen: U kunt entiteiten in dezelfde partitie bijwerken in één atomische batchtransactie met maximaal 100 afzonderlijke opslagbewerkingen (limiet van 4 MB totale grootte). Uitgaande van het aantal entiteiten dat moet worden opgehaald, kunt u ook de gegevens binnen één partitie efficiënter opvragen dan gegevens die over meerdere partities zijn verdeeld (lees echter verder voor nog meer aanbevelingen voor het opvragen van tabel gegevens).
- Schaalbaarheidslimiet: toegang tot entiteiten die zijn opgeslagen in één partitie, kan niet worden verdeeld omdat partities atomische batchtransacties ondersteunen. Daarom is het schaalbaarheidsdoel voor een afzonderlijke tabelpartitie lager dan voor de Table service als geheel.
Vanwege deze kenmerken van tabellen en partities moet u de volgende ontwerpprincipes aanhouden:
- Zoek gegevens die regelmatig in dezelfde logische werkeenheid in dezelfde partitie door uw clienttoepassing worden bijgewerkt en opgevraagd. Zoek bijvoorbeeld gegevens in dezelfde partitie als uw toepassing schrijfbewerkingen samenvoegt of als u atomische batchbewerkingen uitvoert. Ook kunnen gegevens in één partitie efficiënter worden opgevraagd in één query dan gegevens binnen verschillende partities.
- Zoek gegevens die uw clienttoepassing niet in dezelfde logische werkeenheid (in één query of batch-update) in afzonderlijke partities invoegt, bijwerkt of opvraagt. Houd er rekening mee dat er geen limiet is voor het aantal partitiesleutels in één tabel, dus het hebben van miljoenen partitiesleutels is geen probleem en heeft geen invloed op de prestaties. Als uw toepassing bijvoorbeeld een populaire website is met gebruikersaanmelding, kan het gebruik van de gebruikers-id als partitiesleutel een goede keuze zijn.
Dynamische partities
Een dynamische partitie is een partitie die een onevenredig percentage van het verkeer naar een account ontvangt en die niet kan worden verdeeld omdat het één partitie is. In het algemeen worden op een van de volgende twee manieren dynamische partities gemaakt:
De patronen 'alleen toevoegen' en 'alleen laten voorafgaan'
Het patroon ' alleen toevoegen ' is een patroon waarbij alle (of bijna alle) verkeer naar een bepaalde partitiesleutel toeneemt en afneemt op basis van de actuele tijd. Stel bijvoorbeeld dat uw toepassing de huidige datum als partitiesleutel gebruikt voor logboekgegevens. Dit ontwerp resulteert in alle invoegingen die naar de laatste partitie in uw tabel gaan en het systeem kan de taakverdeling niet goed verdelen. Als het volume van verkeer naar die partitie groter is dan het schaalbaarheidsdoel op partitieniveau, leidt dit tot beperking. Het is beter om ervoor te zorgen dat verkeer naar meerdere partities wordt verzonden om een taakverdeling mogelijk te maken voor de aanvragen in uw tabel.
Gegevens met intensief verkeer
Als uw partitioneringsschema resulteert in één partitie die alleen gegevens bevat die veel meer worden gebruikt dan andere partities, ziet u mogelijk ook beperking omdat die partitie het schaalbaarheidsdoel voor één partitie nadert. Het is beter om ervoor te zorgen dat geen enkele partitie de schaalbaarheidsdoelen nadert als gevolg van uw partitieschema.
Uitvoeren van query's
In deze sectie worden bewezen procedures beschreven voor het uitvoeren van query's op de Table service.
Querybereik
Er zijn verschillende manieren om het bereik van de op te vragen entiteiten op te geven. In de volgende lijst worden alle opties voor het querybereik beschreven.
- Puntquery's:: een puntquery haalt precies één entiteit op door zowel de partitiesleutel als de rijsleutel op te geven van de entiteit die moet worden opgehaald. Deze query's zijn efficiënt en u moet ze waar mogelijk gebruiken.
- Partitiequery's: een partitiequery is een query waarmee een set gegevens wordt opgehaald die een gemeenschappelijke partitiesleutel deelt. Normaal gesproken specificeert de query een reeks rijsleutelwaarden of een reeks waarden voor een bepaalde entiteitseigenschap naast een partitiesleutel. Deze query's zijn minder efficiënt dan puntquery's en moeten spaarzaam worden gebruikt.
- Tabelquery's: Een tabelquery is een query waarmee een set entiteiten wordt opgehaald die geen gemeenschappelijke partitiesleutel deelt. Deze query's zijn niet efficiënt en u moet deze indien mogelijk vermijden.
U kunt in het algemeen het beste scans vermijden (query's die groter zijn dan één entiteit), maar als u moet scannen, kunt u het beste uw gegevens zo indelen dat uw scans de gegevens ophalen die u nodig hebt zonder dat grote hoeveelheden onnodige entiteiten hoeven te worden gescand of geretourneerd.
Querydichtheid
Een andere belangrijke factor in queryefficiëntie is het aantal entiteiten dat wordt geretourneerd in vergelijking met het aantal gescande entiteiten om de geretourneerde set te vinden. Als uw toepassing een tabelquery uitvoert met een filter voor een eigenschapswaarde die slechts 1% van de gegevensshares bevat, scant de query 100 entiteiten voor elke entiteit die wordt geretourneerd. De schaalbaarheidsdoelen voor tabellen die eerder zijn besproken, hebben betrekking op het aantal gescande entiteiten en niet op het aantal geretourneerde entiteiten: een lage querydichtheid kan ervoor zorgen dat de Table-service uw toepassing beperkt omdat er zoveel entiteiten moeten worden gescand om de entiteit op te halen die u zoekt. Raadpleeg de sectie met de titel Denormalisatie voor meer informatie over hoe u beperkingen kunt voorkomen.
De hoeveelheid geretourneerde gegevens beperken
Wanneer u weet dat een query entiteiten retourneert die u niet nodig hebt in de clienttoepassing, kunt u een filter gebruiken om de grootte van de geretourneerde set te verkleinen. Hoewel de entiteiten die niet naar de client worden geretourneerd nog steeds meegeteld bij de schaalbaarheidslimieten, worden de prestaties van uw toepassing verbeterd vanwege de verminderde nettoladingsgrootte van het netwerk en het verminderde aantal entiteiten dat uw clienttoepassing moet verwerken. Houd er rekening mee dat de schaalbaarheidsdoelen betrekking hebben op het aantal gescande entiteiten, dus een query die veel entiteiten filtert, kan nog steeds leiden tot beperking, zelfs als er weinig entiteiten worden geretourneerd. Zie de sectie met de titel Querydichtheid voor meer informatie over het efficiënt maken van query's.
Als uw clienttoepassing slechts een beperkt aantal eigenschappen van de entiteiten in uw tabel nodig heeft, kunt u projectie gebruiken om de grootte van de geretourneerde gegevensset te beperken. Net als bij het filteren wordt met projectie de belasting van het netwerk en de clientverwerking verminderd.
Denormalisatie
In tegenstelling tot het werken met relationele databases leiden de bewezen procedures voor het efficiënt opvragen van tabelgegevens ertoe dat uw gegevens worden gedenormaliseerd. Dat wil gezegd: het dupliceren van dezelfde gegevens in meerdere entiteiten (één voor elke sleutel die u kunt gebruiken om de gegevens te vinden) om het aantal entiteiten te minimaliseren dat een query moet scannen om de gegevens te vinden die de client nodig heeft, in plaats van grote aantallen entiteiten te scannen om de gegevens te vinden die uw toepassing nodig heeft. In een e-commercewebsite wilt u bijvoorbeeld een bestelling vinden op basis van de klant-id (geef mij de orders van deze klant) en op de datum (geef mij orders op een datum). In Table Storage kunt u de entiteit (of een verwijzing ernaar) twee keer opslaan, één keer met tabelnaam, PK en RK om het vinden van de klant-id te vergemakkelijken, eenmaal om het vinden ervan op de datum te vergemakkelijken.
Invoegen, bijwerken en verwijderen
In deze sectie worden bewezen procedures beschreven voor het wijzigen van query's die zijn opgeslagen in de Table service.
Batching
Batchtransacties worden ook wel entiteitsgroepstransacties genoemd in Azure Storage. Alle bewerkingen binnen een entiteitsgroepstransactie moeten op één partitie in één tabel staan. Gebruik waar mogelijk entiteitsgroepstransacties om invoeg-, bijwerk- en verwijderbewerkingen in batches uit te voeren. Het gebruik van entiteitsgroepstransacties vermindert het aantal retouren van uw clienttoepassing naar de server, vermindert het aantal factureerbare transacties (een entiteitsgroepstransactie telt als één transactie voor factureringsdoeleinden en kan maximaal 100 opslagbewerkingen bevatten), en schakelt atomische updates in (alle bewerkingen zijn geslaagd of zijn allemaal mislukt binnen een entiteitsgroepstransactie). Omgevingen met hoge latenties, zoals mobiele apparaten, profiteren sterk van het gebruik van entiteitsgroeptransacties.
Upsert
Gebruik waar mogelijk de tabelbewerkingen voor Upsert. Er zijn twee soorten Upsert, die beide efficiënter kunnen zijn dan traditionele bewerkingen voor invoegen en bijwerken:
- InsertOrMerge: Gebruik deze bewerking als u een subset van de eigenschappen van de entiteit wilt uploaden, maar niet zeker weet of de entiteit al bestaat. Als de entiteit bestaat, worden met deze aanroep de eigenschappen bijgewerkt die zijn opgenomen in de Upsert-bewerking en blijven alle bestaande eigenschappen zoals ze zijn, als de entiteit niet bestaat, de nieuwe entiteit ingevoegd. Dit is vergelijkbaar met het gebruik van projectie in een query, in zoverre dat u alleen de eigenschappen hoeft te uploaden die worden gewijzigd.
- InsertOrReplace: Gebruik deze bewerking als u een geheel nieuwe entiteit wilt uploaden, maar u weet niet zeker of deze al bestaat. Gebruik deze bewerking wanneer u weet dat de zojuist geüploade entiteit volledig juist is, omdat hiermee de oude entiteit volledig wordt overschreven. U wilt bijvoorbeeld de entiteit bijwerken waarin de huidige locatie van een gebruiker wordt opgeslagen, ongeacht of de toepassing eerder locatiegegevens voor de gebruiker heeft opgeslagen; de nieuwe locatie-entiteit is voltooid en u hebt geen informatie van een vorige entiteit nodig.
Gegevensreeksen opslaan in één entiteit
Soms slaat een toepassing een reeks gegevens op die regelmatig allemaal tegelijk moet worden opgehaald: een toepassing kan bijvoorbeeld het CPU-gebruik in de loop van de tijd volgen om een doorlopende grafiek van de gegevens in de afgelopen 24 uur te tekenen. Een manier is om één tabelentiteit per uur te hebben, waarbij elke entiteit een specifiek uur vertegenwoordigt waarin het CPU-gebruik voor dat uur wordt opgeslagen. Voor het uitzetten van deze gegevens moet de toepassing de entiteiten ophalen die de gegevens van de 24 meest recente uren bevatten.
Het is ook mogelijk dat uw toepassing het CPU-gebruik voor elk uur opslaat als afzonderlijke eigenschap van één entiteit: uw toepassing kan elk uur bijwerken door via één InsertOrMerge Upsert-aanroep de waarde voor het meest recente uur bij te werken. Voor het uitzetten van de gegevens hoeft de toepassing slechts één entiteit op te halen in plaats van 24, waardoor u een efficiënte query krijgt. Zie de sectie querybereik met de titel Query voor meer informatie over de efficiëntie van query's.
Gestructureerde gegevens opslaan in blobs
Als u batchinvoegingen uitvoert en vervolgens bereiken van entiteiten samen opzoekt, kunt u overwegen om blobs te gebruiken in plaats van tabellen. Een goed voorbeeld hiervan is een logboekbestand. U kunt meerdere minuten aan logboeken in batches vastleggen, deze invoegen en vervolgens meerdere minuten aan logboeken tegelijk ophalen. In dit geval zijn de prestaties beter als u blobs gebruikt in plaats van tabellen, omdat u het aantal objecten waarnaar is geschreven of die zijn gelezen aanzienlijk kunt verminderen, en mogelijk ook het aantal aanvragen dat moet worden gedaan.