Checklista för prestanda och skalbarhet för table storage
Microsoft har utvecklat många beprövade metoder för att utveckla högpresterande program med Table Storage. Den här checklistan identifierar viktiga metoder som utvecklare kan följa för att optimera prestanda. Tänk på dessa metoder när du utformar ditt program och under hela processen.
Azure Storage har skalbarhets- och prestandamål för kapacitet, transaktionshastighet och bandbredd. Mer information om skalbarhetsmål för Azure Storage finns i Skalbarhets- och prestandamål för standardlagringskonton och skalbarhets- och prestandamål för Table Storage.
Checklista
Den här artikeln organiserar beprövade metoder för prestanda i en checklista som du kan följa när du utvecklar ditt Table Storage-program.
Skalbarhetsmål
Om ditt program närmar sig eller överskrider något av skalbarhetsmålen kan det uppstå ökade transaktionsfördröjningar eller begränsningar. När Azure Storage begränsar ditt program börjar tjänsten returnera felkoderna 503 (servern är upptagen) eller 500 (timeout för åtgärd). Att undvika dessa fel genom att hålla sig inom gränserna för skalbarhetsmålen är en viktig del av att förbättra programmets prestanda.
Mer information om skalbarhetsmål för tabelltjänsten finns i Skalbarhets- och prestandamål för Table Storage.
Maximalt antal lagringskonton
Om du närmar dig det maximala antalet lagringskonton som tillåts för en viss kombination av prenumerationer/regioner använder du flera lagringskonton för att fragmentera för att öka ingress-, utgående, I/O-åtgärder per sekund (IOPS) eller kapacitet? I det här scenariot rekommenderar Microsoft att du drar nytta av ökade gränser för lagringskonton för att minska antalet lagringskonton som krävs för din arbetsbelastning om möjligt. Kontakta Azure Support för att begära ökade gränser för ditt lagringskonto.
Kapacitets- och transaktionsmål
Om ditt program närmar sig skalbarhetsmålen för ett enda lagringskonto bör du överväga att använda någon av följande metoder:
- Ompröva arbetsbelastningen som gör att ditt program närmar sig eller överskrider skalbarhetsmålet. Kan du utforma den annorlunda för att använda mindre bandbredd eller kapacitet, eller färre transaktioner?
- Om ditt program måste överskrida något av skalbarhetsmålen skapar du flera lagringskonton och partitionera dina programdata mellan dessa flera lagringskonton. Om du använder det här mönstret måste du utforma programmet så att du kan lägga till fler lagringskonton i framtiden för belastningsutjämning. Själva lagringskontona har ingen annan kostnad än din användning när det gäller lagrade data, transaktioner som görs eller data som överförs.
- Om ditt program närmar sig bandbreddsmålen bör du överväga att komprimera data på klientsidan för att minska den bandbredd som krävs för att skicka data till Azure Storage. Även om komprimering av data kan spara bandbredd och förbättra nätverksprestanda, kan det också ha negativa effekter på prestanda. Utvärdera prestandapåverkan för de ytterligare bearbetningskraven för datakomprimering och dekomprimering på klientsidan. Tänk på att lagring av komprimerade data kan göra det svårare att felsöka eftersom det kan vara svårare att visa data med hjälp av standardverktyg.
- Om programmet närmar sig skalbarhetsmålen kontrollerar du att du använder en exponentiell backoff för återförsök. Det är bäst att försöka undvika att nå skalbarhetsmålen genom att implementera rekommendationerna som beskrivs i den här artikeln. Men om du använder en exponentiell backoff för återförsök kan programmet inte försöka igen snabbt, vilket kan göra begränsningen värre. Mer information finns i avsnittet timeout- och Server Busy-fel.
Mål för dataåtgärder
Azure Storage belastningsutjämnas när trafiken till ditt lagringskonto ökar, men om trafiken uppvisar plötsliga toppar kanske du inte kan få den här mängden dataflöde omedelbart. Förvänta dig att se begränsningar och/eller tidsgränser under burst-belastningen när Azure Storage automatiskt belastningsutjäxlar tabellen. Att öka långsamt ger vanligtvis bättre resultat, eftersom systemet har tid att belastningsutjämning på lämpligt sätt.
Entiteter per sekund (lagringskonto)
Skalbarhetsgränsen för åtkomst till tabeller är upp till 20 000 entiteter (1 KB vardera) per sekund för ett konto. I allmänhet räknas varje entitet som infogas, uppdateras, tas bort eller genomsöks mot det här målet. En batchinfogning som innehåller 100 entiteter räknas därför som 100 entiteter. En fråga som söker igenom 1 000 entiteter och returnerar 5 räknas som 1 000 entiteter.
Entiteter per sekund (partition)
Inom en enskild partition är skalbarhetsmålet för åtkomst till tabeller 2 000 entiteter (1 KB vardera) per sekund, med samma räkning som beskrivs i föregående avsnitt.
Nätverk
Programmets fysiska nätverksbegränsningar kan ha en betydande inverkan på prestandan. I följande avsnitt beskrivs några av de begränsningar som användare kan stöta på.
Klientnätverksfunktion
Bandbredd och kvaliteten på nätverkslänken spelar viktiga roller i programmets prestanda, enligt beskrivningen i följande avsnitt.
Dataflöde
För bandbredd är problemet ofta klientens funktioner. Större Azure-instanser har nätverkskort med större kapacitet, så du bör överväga att använda en större instans eller fler virtuella datorer om du behöver högre nätverksgränser från en enda dator. Om du kommer åt Azure Storage från ett lokalt program gäller samma regel: förstå nätverksfunktionerna på klientenheten och nätverksanslutningen till Azure Storage-platsen och förbättra dem efter behov eller utforma programmet så att det fungerar inom deras funktioner.
Länkkvalitet
Som med all nätverksanvändning bör du tänka på att nätverksförhållanden som resulterar i fel och paketförlust saktar ned effektivt dataflöde. Att använda WireShark eller NetMon kan hjälpa dig att diagnostisera det här problemet.
Plats
I alla distribuerade miljöer ger det bästa prestanda att placera klienten nära servern. För åtkomst till Azure Storage med lägst svarstid är den bästa platsen för klienten inom samma Azure-region. Om du till exempel har en Azure-webbapp som använder Azure Storage letar du upp dem båda i en enda region, till exempel USA, västra eller Asien, sydöstra. Genom att samlokalisera resurser minskar svarstiden och kostnaden, eftersom bandbreddsanvändningen i en enda region är kostnadsfri.
Om klientprogram kommer åt Azure Storage men inte finns i Azure, till exempel mobilappar eller lokala företagstjänster, kan det minska svarstiden att hitta lagringskontot i en region nära dessa klienter. Om dina klienter är brett fördelade (till exempel vissa i Nordamerika och vissa i Europa) kan du överväga att använda ett lagringskonto per region. Den här metoden är enklare att implementera om de data som programmet lagrar är specifika för enskilda användare och inte kräver replikering av data mellan lagringskonton.
SAS och CORS
Anta att du behöver auktorisera kod som JavaScript som körs i en användares webbläsare eller i en mobilapp för att få åtkomst till data i Azure Storage. En metod är att skapa ett tjänstprogram som fungerar som proxy. Användarens enhet autentiserar med tjänsten, vilket i sin tur ger åtkomst till Azure Storage-resurser. På så sätt kan du undvika att exponera dina lagringskontonycklar på osäkra enheter. Den här metoden medför dock betydande kostnader för tjänstprogrammet, eftersom alla data som överförs mellan användarens enhet och Azure Storage måste passera genom tjänstprogrammet.
Du kan undvika att använda ett tjänstprogram som proxy för Azure Storage med hjälp av signaturer för delad åtkomst (SAS). Med HJÄLP av SAS kan du aktivera användarens enhet för att göra begäranden direkt till Azure Storage med hjälp av en begränsad åtkomsttoken. Om en användare till exempel vill ladda upp ett foto till ditt program kan tjänstprogrammet generera en SAS och skicka den till användarens enhet. SAS-token kan ge behörighet att skriva till en Azure Storage-resurs under ett angivet tidsintervall, varefter SAS-token upphör att gälla. Mer information om SAS finns i Bevilja begränsad åtkomst till Azure Storage-resurser med hjälp av signaturer för delad åtkomst (SAS).
Normalt tillåter inte en webbläsare JavaScript på en sida som finns på en webbplats i en domän för att utföra vissa åtgärder, till exempel skrivåtgärder, till en annan domän. Den här principen kallas för principen för samma ursprung och förhindrar att ett skadligt skript på en sida får åtkomst till data på en annan webbsida. Principen för samma ursprung kan dock vara en begränsning när du skapar en lösning i molnet. Resursdelning mellan ursprung (CORS) är en webbläsarfunktion som gör att måldomänen kan kommunicera med webbläsaren som den litar på begäranden som kommer från källdomänen.
Anta till exempel att ett webbprogram som körs i Azure gör en begäran om en resurs till ett Azure Storage-konto. Webbprogrammet är källdomänen och lagringskontot är måldomänen. Du kan konfigurera CORS för någon av Azure Storage-tjänsterna för att kommunicera med webbläsaren om att begäranden från källdomänen är betrodda av Azure Storage. Mer information om CORS finns i Stöd för resursdelning mellan ursprung (CORS) för Azure Storage.
Både SAS och CORS kan hjälpa dig att undvika onödig belastning på webbappen.
Batch-transaktioner
Tabelltjänsten stöder batchtransaktioner på entiteter som finns i samma tabell och tillhör samma partitionsgrupp. Mer information finns i Utföra entitetsgrupptransaktioner.
.NET-konfiguration
För projekt som använder .NET Framework innehåller det här avsnittet några snabbkonfigurationsinställningar som du kan använda för att göra betydande prestandaförbättringar. Om du använder ett annat språk än .NET kontrollerar du om liknande begrepp gäller på det valda språket.
Öka standardgränsen för anslutning
Kommentar
Det här avsnittet gäller för projekt som använder .NET Framework, eftersom anslutningspooler styrs av klassen ServicePointManager. .NET Core introducerade en betydande ändring av hantering av anslutningspooler, där anslutningspooler sker på HttpClient-nivå och poolstorleken inte är begränsad som standard. Det innebär att HTTP-anslutningar skalas automatiskt för att uppfylla din arbetsbelastning. Om det är möjligt rekommenderar vi att du använder den senaste versionen av .NET för att dra nytta av prestandaförbättringar.
För projekt som använder .NET Framework kan du använda följande kod för att öka standardanslutningsgränsen (som vanligtvis är 2 i en klientmiljö eller 10 i en servermiljö) till 100. Vanligtvis bör du ange värdet till ungefär det antal trådar som används av ditt program. Ange anslutningsgränsen innan du öppnar några anslutningar.
ServicePointManager.DefaultConnectionLimit = 100; //(Or More)
Mer information om gränser för anslutningspooler i .NET Framework finns i .NET Framework Anslut ionspoolgränser och det nya Azure SDK för .NET.
Andra programmeringsspråk finns i dokumentationen för att fastställa hur anslutningsgränsen ska anges.
Öka det minsta antalet trådar
Om du använder synkrona anrop tillsammans med asynkrona uppgifter kanske du vill öka antalet trådar i trådpoolen:
ThreadPool.SetMinThreads(100,100); //(Determine the right number for your application)
Mer information finns i metoden ThreadPool.SetMinThreads .
Obundna parallelliteter
Parallellitet kan vara bra för prestanda, men var försiktig med att använda obundna parallelliteter, vilket innebär att det inte finns någon gräns för antalet trådar eller parallella begäranden. Se till att begränsa parallella begäranden om att ladda upp eller ladda ned data, att komma åt flera partitioner i samma lagringskonto eller att komma åt flera objekt i samma partition. Om parallelliteten är obundna kan programmet överskrida klientenhetens funktioner eller lagringskontots skalbarhetsmål, vilket resulterar i längre svarstider och begränsningar.
Klientbibliotek och -verktyg
Använd alltid de senaste klientbiblioteken och verktygen från Microsoft för bästa prestanda. Azure Storage-klientbibliotek är tillgängliga för olika språk. Azure Storage har även stöd för PowerShell och Azure CLI. Microsoft utvecklar aktivt dessa klientbibliotek och verktyg med prestanda i åtanke, håller dem uppdaterade med de senaste tjänstversionerna och ser till att de hanterar många av de beprövade prestandametoderna internt.
Hantera tjänstfel
Azure Storage returnerar ett fel när tjänsten inte kan bearbeta en begäran. Att förstå de fel som returneras av Azure Storage i ett visst scenario är användbart för att optimera prestanda.
Timeout- och Server Busy-fel
Azure Storage kan begränsa ditt program om det närmar sig skalbarhetsgränserna. I vissa fall kanske Azure Storage inte kan hantera en begäran på grund av ett tillfälligt villkor. I båda fallen kan tjänsten returnera felet 503 (Servern är upptagen) eller 500 (timeout). Dessa fel kan också inträffa om tjänsten balanserar om datapartitioner för att möjliggöra högre dataflöde. Klientprogrammet bör vanligtvis försöka utföra åtgärden igen som orsakar något av dessa fel. Men om Azure Storage begränsar ditt program eftersom det överskrider skalbarhetsmålen, eller om tjänsten inte kunde hantera begäran av någon annan anledning, kan aggressiva återförsök göra problemet värre. Vi rekommenderar att du använder en exponentiell princip för återförsök och att klientbiblioteken använder det här beteendet som standard. Ditt program kan till exempel försöka igen efter 2 sekunder, sedan 4 sekunder, sedan 10 sekunder, sedan 30 sekunder och sedan ge upp helt. På så sätt minskar programmet avsevärt belastningen på tjänsten i stället för att förvärra beteendet som kan leda till begränsning.
Anslut ivity errors can betrieds immediately, because they are't the result of throttling and are expected to be transient.
Fel som inte kan försökas igen
Klientbiblioteken hanterar återförsök med en medvetenhet om vilka fel som kan försökas igen och vilka som inte kan göra det. Men om du anropar Azure Storage REST API direkt finns det några fel som du inte bör försöka igen. Ett 400-fel (felaktig begäran) anger till exempel att klientprogrammet skickade en begäran som inte kunde bearbetas eftersom den inte var i det förväntade formuläret. Om du skickar den här begäran igen får du samma svar varje gång, så det är ingen idé att försöka igen. Om du anropar Azure Storage REST API direkt bör du vara medveten om potentiella fel och om de ska göras om.
Mer information om Azure Storage-felkoder finns i Status- och felkoder.
Konfiguration
Det här avsnittet innehåller flera snabbkonfigurationsinställningar som du kan använda för att göra betydande prestandaförbättringar i tabelltjänsten:
Använd JSON
Från och med lagringstjänsten version 2013-08-15 stöder table-tjänsten JSON i stället för DET XML-baserade AtomPub-formatet för överföring av tabelldata. Med JSON kan du minska nyttolaststorlekarna med så mycket som 75 % och avsevärt förbättra programmets prestanda.
Mer information finns i inlägget Microsoft Azure Tables: Introducing JSON and Payload Format for Table Service Operations (Introduktion till JSON - och Payload-format för Table Service-åtgärder).
Inaktivera Nagle
Nagles algoritm implementeras i stor utsträckning i TCP/IP-nätverk som ett sätt att förbättra nätverksprestanda. Det är dock inte optimalt under alla omständigheter (till exempel mycket interaktiva miljöer). Nagles algoritm har en negativ inverkan på prestanda för begäranden till Azure Table-tjänsten, och du bör inaktivera den om möjligt.
Schema
Hur du representerar och frågar efter dina data är den största enskilda faktorn som påverkar prestanda för tabelltjänsten. Även om varje program skiljer sig åt beskriver det här avsnittet några allmänna beprövade metoder som rör:
- Tabelldesign
- Effektiva frågor
- Effektiva datauppdateringar
Tabeller och partitioner
Tabeller är indelade i partitioner. Varje entitet som lagras i en partition delar samma partitionsnyckel och har en unik radnyckel för att identifiera den i partitionen. Partitioner ger fördelar men introducerar även skalbarhetsgränser.
- Fördelar: Du kan uppdatera entiteter i samma partition i en enda atomisk batchtransaktion som innehåller upp till 100 separata lagringsåtgärder (en gräns på 4 MB total storlek). Om du antar att samma antal entiteter som ska hämtas kan du också köra frågor mot data i en enda partition effektivare än data som sträcker sig över partitioner (läs vidare för ytterligare rekommendationer om att fråga tabelldata).
- Skalbarhetsgräns: Åtkomst till entiteter som lagras i en enskild partition kan inte belastningsutjämning eftersom partitioner stöder atomiska batchtransaktioner. Därför är skalbarhetsmålet för en enskild tabellpartition lägre än för tabelltjänsten som helhet.
På grund av dessa egenskaper för tabeller och partitioner bör du använda följande designprinciper:
- Leta upp data som klientprogrammet ofta uppdaterar eller frågar i samma logiska arbetsenhet i samma partition. Du kan till exempel leta upp data i samma partition om ditt program aggregerar skrivningar eller om du utför atomiska batchåtgärder. Dessutom kan data i en enda partition efterfrågas mer effektivt i en enda fråga än data mellan partitioner.
- Leta upp data som klientprogrammet inte infogar, uppdaterar eller frågar i samma logiska arbetsenhet (dvs. i en enskild fråga eller batchuppdatering) i separata partitioner. Tänk på att det inte finns någon gräns för antalet partitionsnycklar i en enda tabell, så att ha miljontals partitionsnycklar är inte ett problem och påverkar inte prestanda. Om ditt program till exempel är en populär webbplats med användarinloggning kan det vara ett bra val att använda användar-ID:t som partitionsnyckel.
Frekventa partitioner
En frekvent partition är en partition som tar emot en oproportionerlig procentandel av trafiken till ett konto och som inte kan lastbalanseras eftersom det är en enda partition. I allmänhet skapas frekventa partitioner på ett av två sätt:
Tilläggsmönster och Endast prepend-mönster
Mönstret "Endast tillägg" är ett mönster där all (eller nästan all) trafik till en viss partitionsnyckel ökar och minskar beroende på aktuell tid. Anta till exempel att ditt program använder det aktuella datumet som en partitionsnyckel för loggdata. Den här designen resulterar i att alla infogningar går till den sista partitionen i tabellen och att systemet inte kan lastbalansera korrekt. Om mängden trafik till partitionen överskrider skalbarhetsmålet på partitionsnivå resulterar det i begränsning. Det är bättre att se till att trafiken skickas till flera partitioner för att aktivera belastningsutjämning av begäranden i tabellen.
Data med hög trafik
Om partitioneringsschemat resulterar i en enda partition som bara har data som används mycket mer än andra partitioner kan du också se begränsningar när partitionen närmar sig skalbarhetsmålet för en enskild partition. Det är bättre att se till att partitionsschemat resulterar i att ingen enskild partition närmar sig skalbarhetsmålen.
Fråga
I det här avsnittet beskrivs beprövade metoder för att fråga tabelltjänsten.
Frågeomfång
Det finns flera sätt att ange intervallet för entiteter att fråga efter. I följande lista beskrivs varje alternativ för frågeomfång.
- Punktfrågor:– En punktfråga hämtar exakt en entitet genom att ange både partitionsnyckeln och radnyckeln för entiteten som ska hämtas. Dessa frågor är effektiva och du bör använda dem där det är möjligt.
- Partitionsfrågor: En partitionsfråga är en fråga som hämtar en uppsättning data som delar en gemensam partitionsnyckel. Vanligtvis anger frågan ett intervall med radnyckelvärden eller ett värdeintervall för någon entitetsegenskap utöver en partitionsnyckel. Dessa frågor är mindre effektiva än punktfrågor och bör användas sparsamt.
- Tabellfrågor: En tabellfråga är en fråga som hämtar en uppsättning entiteter som inte delar en gemensam partitionsnyckel. Dessa frågor är inte effektiva och du bör undvika dem om möjligt.
I allmänhet bör du undvika genomsökningar (frågor som är större än en enda entitet), men om du måste skanna kan du försöka ordna dina data så att genomsökningarna hämtar de data du behöver utan att skanna eller returnera betydande mängder entiteter som du inte behöver.
Frågedensitet
En annan viktig faktor i frågeeffektiviteten är antalet entiteter som returneras jämfört med antalet entiteter som genomsöks för att hitta den returnerade uppsättningen. Om ditt program utför en tabellfråga med ett filter för ett egenskapsvärde som endast 1 % av dataresurserna, söker frågan igenom 100 entiteter för varje entitet som returneras. De mål för tabellskalbarhet som diskuterats tidigare gäller antalet genomsökta entiteter och inte antalet entiteter som returneras: en låg frågedensitet kan enkelt göra att Tabelltjänsten begränsar ditt program eftersom det måste genomsöka så många entiteter för att hämta den entitet som du letar efter. Mer information om hur du undviker begränsning finns i avsnittet Avnormalisering.
Begränsa mängden data som returneras
När du vet att en fråga returnerar entiteter som du inte behöver i klientprogrammet kan du överväga att använda ett filter för att minska storleken på den returnerade uppsättningen. Även om entiteterna som inte returneras till klienten fortfarande räknas mot skalbarhetsgränserna förbättras programmets prestanda på grund av den minskade nätverksnyttolaststorleken och det minskade antalet entiteter som klientprogrammet måste bearbeta. Tänk på att skalbarhetsmålen är relaterade till antalet genomsökta entiteter, så en fråga som filtrerar bort många entiteter kan fortfarande leda till begränsning, även om få entiteter returneras. Mer information om hur du gör frågor effektiva finns i avsnittet Frågedensitet.
Om klientprogrammet bara behöver en begränsad uppsättning egenskaper från entiteterna i tabellen kan du använda projektion för att begränsa storleken på den returnerade datauppsättningen. Precis som med filtrering bidrar projektion till att minska nätverksbelastningen och klientbearbetningen.
Avormalisering
Till skillnad från att arbeta med relationsdatabaser leder beprövade metoder för att effektivt fråga tabelldata till att avnormalisera dina data. D.v.s. duplicera samma data i flera entiteter (en för varje nyckel som du kan använda för att hitta data) för att minimera antalet entiteter som en fråga måste skanna för att hitta de data som klienten behöver, i stället för att behöva söka igenom ett stort antal entiteter för att hitta de data som programmet behöver. På en e-handelswebbplats kanske du till exempel vill hitta en beställning både efter kund-ID :t (ge mig kundens beställningar) och efter datumet (ge mig beställningar på ett datum). I Table Storage är det bäst att lagra entiteten (eller en referens till den) två gånger – en gång med tabellnamn, PK och RK för att underlätta sökning efter kund-ID, en gång för att underlätta sökningen efter datumet.
Infoga, uppdatera och ta bort
I det här avsnittet beskrivs beprövade metoder för att ändra entiteter som lagras i tabelltjänsten.
Batchbearbetning
Batch-transaktioner kallas entitetsgrupptransaktioner i Azure Storage. Alla åtgärder inom en entitetsgrupptransaktion måste finnas på en enda partition i en enda tabell. Använd där det är möjligt entitetsgrupptransaktioner för att utföra infogningar, uppdateringar och borttagningar i batchar. Om du använder entitetsgruppstransaktioner minskar antalet tur- och returresor från klientprogrammet till servern, minskar antalet fakturerbara transaktioner (en entitetsgrupptransaktion räknas som en enskild transaktion i faktureringssyfte och kan innehålla upp till 100 lagringsåtgärder) och aktiverar atomiska uppdateringar (alla åtgärder lyckas eller alla misslyckas inom en entitetsgrupptransaktion). Miljöer med höga svarstider, till exempel mobila enheter, har stor nytta av att använda entitetsgrupptransaktioner.
Upsert
Använd table Upsert-åtgärder där det är möjligt. Det finns två typer av Upsert, som båda kan vara mer effektiva än en traditionell insert - och uppdateringsåtgärd :
- InsertOrMerge: Använd den här åtgärden när du vill ladda upp en delmängd av entitetens egenskaper, men är inte säker på om entiteten redan finns. Om entiteten finns uppdaterar det här anropet egenskaperna som ingår i Upsert-åtgärden och lämnar alla befintliga egenskaper som de är, om entiteten inte finns infogar den nya entiteten . Detta liknar att använda projektion i en fråga, eftersom du bara behöver ladda upp de egenskaper som ändras.
- InsertOrReplace: Använd den här åtgärden när du vill ladda upp en helt ny entitet, men du är inte säker på om den redan finns. Använd den här åtgärden när du vet att den nyligen uppladdade entiteten är helt korrekt eftersom den helt skriver över den gamla entiteten. Du vill till exempel uppdatera entiteten som lagrar en användares aktuella plats oavsett om programmet tidigare har lagrat platsdata för användaren eller inte. den nya platsentiteten är klar och du behöver ingen information från någon tidigare entitet.
Lagra dataserier i en enda entitet
Ibland lagrar ett program en serie data som ofta behöver hämtas samtidigt: till exempel kan ett program spåra CPU-användning över tid för att rita ett rullande diagram över data från de senaste 24 timmarna. En metod är att ha en tabellentitet per timme, där varje entitet representerar en viss timme och lagrar CPU-användningen för den timmen. För att kunna rita dessa data måste programmet hämta entiteterna som innehåller data från de 24 senaste timmarna.
Alternativt kan ditt program lagra CPU-användningen för varje timme som en separat egenskap för en enskild entitet: om du vill uppdatera varje timme kan ditt program använda ett enda InsertOrMerge Upsert-anrop för att uppdatera värdet för den senaste timmen. För att rita data behöver programmet bara hämta en enda entitet i stället för 24, vilket ger en effektiv fråga. Mer information om frågeeffektivitet finns i avsnittet Frågeomfång.
Lagra strukturerade data i blobar
Om du utför batchinfogningar och sedan hämtar intervall med entiteter tillsammans bör du överväga att använda blobar i stället för tabeller. Ett bra exempel är en loggfil. Du kan batcha flera minuters loggar och infoga dem och sedan hämta flera minuters loggar i taget. I det här fallet är prestanda bättre om du använder blobar i stället för tabeller, eftersom du avsevärt kan minska antalet objekt som skrivits till eller lästs, och eventuellt även antalet begäranden som behöver göras.