Dela via


Kapacitet som kan utökas i fabric-datalager

Gäller för:✅ SQL-analysslutpunkt och lager i Microsoft Fabric

En infrastrukturkapacitet är en distinkt pool med resurser som är storlek (eller SKU) som avgör hur mycket beräkningskraft som är tillgänglig. Slutpunkten för lager- och SQL-analys ger bra kapacitet som gör att arbetsbelastningar kan använda fler resurser för att uppnå bättre prestanda.

Burstbar kapacitet

Burstbar kapacitet har en direkt korrelation till den SKU som har tilldelats till arbetsytans infrastrukturkapacitet. Det är också en funktion i arbetsbelastningen. En icke-krävande arbetsbelastning kanske aldrig använder burstbara kapacitetsenheter. Arbetsbelastningen kan uppnå optimala prestanda inom baslinjekapaciteten som har köpts.

För att avgöra om din arbetsbelastning använder burstbar kapacitet kan följande formel användas för att beräkna skalningsfaktorn för din arbetsbelastning: Capacity Units (CU) / duration / Baseline CU = Scale factor

Som en illustration av den här formeln, om din kapacitet är en F8 och din arbetsbelastning tar 100 sekunder att slutföra, och den använder 1500 CU, beräknas skalningsfaktorn på följande sätt: 1500 / 100 / 8 = 1.875

CU kan fastställas med hjälp av appen Kapacitetsmått för Microsoft Fabric.

När en skalningsfaktor är över 1 innebär det att burstbar kapacitet används för att uppfylla arbetsbelastningens krav. Det innebär också att din arbetsbelastning lånar kapacitetsenheter från ett framtida tidsintervall. Detta är ett grundläggande begrepp i Microsoft Fabric som kallas utjämning.

Utjämning ger lättnad för kunder som skapar plötsliga toppar under sina rusningstider, medan de har mycket inaktiv kapacitet som inte används. Utjämning förenklar kapacitetshanteringen genom att sprida utvärderingen av beräkning för att säkerställa att kundjobben fungerar smidigt och effektivt.

SKU-skyddsräcken

Burstbar kapacitet är begränsad. Det finns en gräns som tillämpas på serverdelsberäkningsresurserna för att avsevärt minska risken för att arbetsbelastningar för lager- och SQL-analysslutpunkter orsakar begränsning.

Gränsen (eller skyddsräcket) är en skalningsfaktor som är direkt korrelerad till den SKU-storlek för infrastrukturresurser som har tilldelats arbetsytan.

Infrastruktur-SKU Motsvarande Premium-SKU Originalkapacitetsenheter (CU) Burstbar skalningsfaktor
F2 2 1x - 32x
F4 4 1x - 16x
F8 8 1x - 12x
F16 16 1x - 12x
F32 32 1x - 12x
F64 P1 64 1x - 12x
F128 P2 128 1x - 12x
F256 P3 256 1x - 12x
F512 P4 512 1x - 12x
F1024 P5 1024 1x - 12x
F2048 2048 1x - 12x

Mindre SKU-storlekar används ofta för Dev/Test-scenarier eller ad hoc-arbetsbelastningar. Den större skalningsfaktor som visas i tabellen ger mer bearbetningskraft som överensstämmer med lägre övergripande användning som vanligtvis finns i dessa miljöer.

Större SKU-storlekar har åtkomst till fler totala kapacitetsenheter, vilket gör att mer komplexa arbetsbelastningar kan köras optimalt och med mer samtidighet. Om önskad prestanda för en arbetsbelastning inte uppnås kan det därför vara fördelaktigt att öka kapacitetens SKU-storlek .

Kommentar

Den maximala burstable Scale Factor kan bara observeras för extremt små tidsintervall, ofta inom en enda fråga i sekunder eller till och med millisekunder. När du använder appen Kapacitetsmått för Microsoft Fabric för att observera kapacitet som kan ökas blir skalningsfaktorn under längre tidsperioder lägre.

Isoleringsgränser

Informationslagret isolerar helt inmatning från frågebearbetning, enligt beskrivningen i Arbetsbelastningshantering.

Den burstable skalningsfaktorn kan uppnås oberoende för inmatning samtidigt som den burstable skalningsfaktorn uppnås för frågebearbetning. Dessa skalningsfaktorer kapslar in alla processer i en enda arbetsyta. Kapaciteten kan dock tilldelas till flera arbetsytor. Därför skulle den sammanlagda maxskalningsfaktorn för en kapacitet representeras i följande formel: ([Query burstable scale factor] + [Ingestion burstable scale factor]) * [number of Fabric workspaces] = [aggregate burstable scale factor]

Att tänka på

  • Vanligtvis ska en komplex fråga som körs på en arbetsyta som är tilldelad en SKU-storlek för liten kapacitet köras till slutförande. Men om datahämtningen eller mellanliggande databehandling fysiskt inte kan köras inom den burstbara skalningsfaktorn resulterar det i följande felmeddelande: This query was rejected due to current capacity constraints. Granska prestandariktlinjerna för att säkerställa data- och frågeoptimering innan du ökar SKU-storleken. Kontakta kapacitetsadministratören om du vill öka SKU-storleken.

  • När kapaciteten har storleksändrats tillämpas nya skyddsräcken när nästa fråga körs. Prestanda bör stabiliseras till den nya kapacitetens SKU-storlek inom några sekunder efter den första frågeöverföringen.

  • En arbetsbelastning som körs på en icke-optimal kapacitetsstorlek kan vara föremål för resurskonkurrering (till exempel spill) som kan öka CU-användningen av arbetsbelastningen.