Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
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 Storage voor meer informatie over schaalbaarheidsdoelen voor Azure Storage.
Controlelijst
In dit artikel vindt u bewezen procedures voor prestaties in een controlelijst die u kunt volgen tijdens het ontwikkelen van uw Table Storage-toepassing.
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 maximum aantal opslagaccounts nadert dat is toegestaan voor een bepaalde combinatie van abonnementen/regio's, gebruikt u meerdere opslagaccounts voor shard om inkomend, uitgaand verkeer, I/O-bewerkingen per seconde (IOPS) of capaciteit te verhogen? 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 herhalingen, voorkomt u dat uw toepassing snel opnieuw probeert, waardoor de begrenzing erger kan 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. Verwacht dat er vertragingen en/of time-outs optreden tijdens de burst, omdat Azure Storage uw tabel automatisch in evenwicht brengt. Het langzaam opvoeren biedt over het algemeen betere resultaten, omdat het systeem tijd heeft om de taakverdeling op de juiste manier te verdelen.
Entiteiten per seconde (opslagaccount)
De schaalbaarheidslimiet voor het openen van tabellen is maximaal 20.000 entiteiten (elk 1 kB) per seconde voor een account. Over het algemeen telt elke entiteit die wordt ingevoegd, bijgewerkt, verwijderd of gescand, meegeteld voor dit doel. Een batch-insert 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 is het schaalbaarheidsdoel voor toegang tot tabellen 2000 entiteiten (elk 1 kB) per seconde, waarbij dezelfde telling wordt gebruikt 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. Echter, het same-originbeleid kan een beperking zijn bij het ontwikkelen 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 configureren voor elk van de Azure Storage-services om aan de webbrowser mee te delen dat aanvragen vanuit het brondomein door Azure Storage worden vertrouwd. 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.
Batch-transacties
De Table-service ondersteunt batchtransacties voor entiteiten die zich in dezelfde tabel bevinden en tot dezelfde partitiegroep behoren. Zie Entiteitsgroeptransacties 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
Opmerking
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.
Minimum aantal 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 opnieuw probeerbeleid met exponentieel uitstel wordt aanbevolen, en de cliëntbibliotheken zijn hier standaard op ingesteld. 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.
Connectiviteitsfouten 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.
Configuratie
In deze sectie vindt u verschillende snelle configuratie-instellingen die u kunt gebruiken om aanzienlijke prestatieverbeteringen in de Table-service aan te brengen:
JSON gebruiken
Vanaf opslagserviceversie 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 payloadgrootten verminderen met maximaal 75% 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 algoritme van Nagle wordt veel geïmplementeerd in TCP/IP-netwerken als een middel om de netwerkprestaties te verbeteren. Het is echter niet optimaal in alle omstandigheden (zoals zeer interactieve omgevingen). Het algoritme van Nagle heeft een negatieve invloed op de prestaties van aanvragen voor de Azure Table-service. Schakel dit indien mogelijk uit.
Schema
Hoe u uw gegevens vertegenwoordigt en opvraagt, is de grootste factor die van invloed is op de prestaties van de Table-service. Hoewel elke toepassing anders is, worden in deze sectie enkele algemene bewezen procedures beschreven die betrekking hebben op:
- Tabelontwerp
- Efficiënte queries
- Efficiënte gegevensupdates
Tabellen en partities
Tabellen zijn onderverdeeld in partities. Elke entiteit die in een partitie is opgeslagen, deelt dezelfde partitiesleutel en heeft een unieke rijsleutel om deze binnen die partitie te identificeren. Partities bieden voordelen, maar introduceren ook schaalbaarheidslimieten.
- Voordelen: U kunt entiteiten in dezelfde partitie bijwerken in één atomische batchtransactie met maximaal 100 afzonderlijke opslagbewerkingen (limiet van 4 MB totale grootte). Ervan uitgaande dat hetzelfde aantal entiteiten moet worden opgehaald, kunt u ook efficiënter query's uitvoeren op gegevens binnen één partitie dan gegevens die partities omvatten (maar lees verder voor verdere aanbevelingen voor het uitvoeren van query's op tabelgegevens).
- Schaalbaarheidslimiet: toegang tot entiteiten die zijn opgeslagen in één partitie, kan niet worden uitgebalanceerd 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 hanteren:
- Zoek gegevens die uw clienttoepassing regelmatig bijwerkt of query's uitvoert in dezelfde logische werkeenheid in dezelfde partitie. Zoek bijvoorbeeld gegevens in dezelfde partitie als uw toepassing schrijfbewerkingen samenvoegt of als u atomische batchbewerkingen uitvoert. Bovendien kunnen gegevens in één partitie efficiënter worden opgevraagd in één query dan gegevens in meerdere partities.
- Identificeer gegevens die uw clienttoepassing niet binnen dezelfde logische werkeenheid invoegt, bijwerkt of opvraagt (dat wil zeggen, in één query of batch-update) en plaats deze in afzonderlijke partities. 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.
Actieve partities
Een hete partitie is een partitie die een onevenredig percentage van het verkeer naar een account ontvangt en die niet kan worden gebalanceerd omdat het één enkele partitie is. Over het algemeen worden hete partities op een van twee manieren gemaakt:
Alleen toevoegen en alleen vooraan toevoegen-patronen
Het "Append-Only" patroon is een patroon waarbij al het (of bijna al het) verkeer op een bepaalde partitiesleutel toeneemt en afneemt afhankelijk van de huidige tijd. Stel dat uw toepassing de huidige datum gebruikt als een partitiesleutel 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. Wanneer het verkeersvolume naar die partitie groter is dan het schaalbaarheidsdoel op partitieniveau, leidt dit tot afknijpen. Het is beter om ervoor te zorgen dat verkeer naar meerdere partities wordt verzonden om een evenwichtige verdeling van de aanvragen over uw tabel te realiseren.
Gegevens met hoge verkeersintensiteit
Als uw partitioneringsschema resulteert in één partitie die gegevens bevat die veel vaker worden gebruikt dan andere partities, ziet u mogelijk ook limitering omdat die partitie de schaalbaarheidslimiet voor één partitie nadert. Het is beter om ervoor te zorgen dat uw partitieschema resulteert in geen enkele partitie die de schaalbaarheidsdoelen nadert.
Opvragen
In deze sectie worden bewezen procedures beschreven voor het uitvoeren van query's op de Tabelservice.
Querybereik
Er zijn verschillende manieren om het bereik van entiteiten op te geven waarop een query moet worden uitgevoerd. In de volgende lijst wordt elke optie voor het querybereik beschreven.
- Puntquery's:- Een puntquery haalt precies één entiteit op door zowel de partitiesleutel als de rijsleutel van de entiteit op te geven 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 geeft de query een bereik van rijsleutelwaarden of een reeks waarden voor een bepaalde entiteitseigenschap op, 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 delen. Deze query's zijn niet efficiënt en u moet deze indien mogelijk vermijden.
Vermijd in het algemeen scans (query's die groter zijn dan één entiteit), maar als u de gegevens moet scannen, probeert u uw gegevens te ordenen, zodat uw scans de gegevens ophalen die u nodig hebt zonder te scannen of aanzienlijke hoeveelheden entiteiten te retourneren die u niet nodig hebt.
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 datapunten gemeenschappelijk heeft, 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. Zie de sectie Denormalization (Denormalisatie) voor meer informatie over het voorkomen van drosseling.
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 throttling, zelfs als er weinig entiteiten worden geretourneerd. Zie de sectie querydichtheid voor meer informatie over het efficiënt maken van query's.
Als uw clienttoepassing slechts een beperkte set 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 filteren helpt projectie om de netwerkbelasting en clientverwerking te verminderen.
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 de Table Storage is het het beste om de entiteit (of een verwijzing ernaar) twee keer op te slaan: één keer met de tabelnaam, PK en RK om het vinden op basis van klant-id te vergemakkelijken, en één keer om het vinden op basis van de datum te vergemakkelijken.
Invoegen, bijwerken en verwijderen
In deze sectie worden bewezen procedures beschreven voor het wijzigen van entiteiten die zijn opgeslagen in de Tabelservice.
Batchverwerking
Batchtransacties worden entiteitsgroeptransacties genoemd in Azure Storage. Alle bewerkingen binnen een entiteitsgroeptransactie moeten zich op één partitie in één tabel bevinden. Gebruik waar mogelijk entiteitsgroeptransacties om invoegingen, updates en verwijderingen in batches uit te voeren. Als u entiteitsgroeptransacties gebruikt, vermindert u het aantal retouren van uw clienttoepassing naar de server, vermindert u het aantal factureerbare transacties (een entiteitsgroeptransactie telt als één transactie voor factureringsdoeleinden en kan maximaal 100 opslagbewerkingen bevatten) en worden atomische updates ingeschakeld (alle bewerkingen slagen of allemaal mislukken binnen een transactie van een entiteitsgroep). Omgevingen met hoge latenties, zoals mobiele apparaten, profiteren sterk van het gebruik van entiteitsgroeptransacties.
Upsert
Gebruik waar mogelijk tabel Upsert-bewerkingen . Er zijn twee typen Upsert, die beide efficiënter kunnen zijn dan traditionele invoeg - en updatebewerkingen :
- 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, omdat 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 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 vaak tegelijk moeten worden opgehaald: een toepassing kan bijvoorbeeld het CPU-gebruik in de loop van de tijd bijhouden om een rolling grafiek van de gegevens uit de afgelopen 24 uur te tekenen. Eén benadering is om één tabelentiteit per uur te hebben, waarbij elke entiteit een specifiek uur vertegenwoordigt en het CPU-gebruik voor dat uur opslaat. Om deze gegevens te plotten, moet de toepassing de entiteiten met de gegevens ophalen uit de afgelopen 24 uur.
Uw toepassing kan ook het CPU-gebruik voor elk uur opslaan als een afzonderlijke eigenschap van één entiteit: om elk uur bij te werken, kan uw toepassing één InsertOrMerge Upsert-aanroep gebruiken om de waarde voor het meest recente uur bij te werken. Als u de gegevens wilt uitzetten, hoeft de toepassing slechts één entiteit op te halen in plaats van 24, waardoor een efficiënte query wordt uitgevoerd. Zie de sectie met de titel Query scope voor meer informatie over de efficiëntie van query's.
Gestructureerde gegevens opslaan in blobs
Als u batchinvoegingen uitvoert en vervolgens reeksen van entiteiten terughaalt, kunt u overwegen om blobs te gebruiken in plaats van tabellen. Een goed voorbeeld is een logboekbestand. U kunt enkele minuten aan logboeken verzamelen en invoegen, en vervolgens enkele minuten aan logboeken tegelijkertijd terughalen. In dit geval zijn de prestaties beter als u blobs gebruikt in plaats van tabellen, omdat u het aantal objecten dat naar of naar de leesbewerking is geschreven aanzienlijk kunt verminderen en mogelijk ook het aantal aanvragen dat nodig is.