Planera Azure Database for PostgreSQL distributioner för driftprestanda

Molnbaserad databehandling har dramatiskt omformat databasens värdlandskap. Det ger teamen tillgång till skalbarhet, motståndskraft, global räckvidd och funktioner som tidigare var ouppnåeliga. I stället för att medföra betydande kostnader och omkostnader genom att planera för största möjliga arbetsbelastning (och bära den kostnaden från dag ett), kan teamen nu optimera runt den exakta skala de behöver, när de behöver det, och justera när deras krav ändras.

Introduction

Flexibiliteten att välja lämplig resursbalans är särskilt värdefull för PostgreSQL-databasdistributioner. PostgreSQL-databasarbetsbelastningar kan börja små, växa snabbt, öka säsongsvis, växla från läsintensiva till skrivintensiva eller utvecklas från transaktionsarbetsbelastningar till hybriddrifts- och analyssystem i realtid. Azure Database for PostgreSQL ser till att dina lösningar når dina mål genom att erbjuda ett brett utbud av alternativ för hantering av beräkning, lagring, tillgänglighet, replikering, säkerhet, säkerhetskopiering och drift.

Men med all den här kraften kommer ansvar, särskilt när du planerar dina distributioner. För att uppnå bästa möjliga prestanda måste dina distributionsbeslut matcha den övergripande arbetsbelastningens krav.

En lyckad Azure Database for PostgreSQL distribution är inte bara en fråga om att välja "de mest kärnor och minne vi behöver." I stället kommer maximal driftsprestanda från att förstå programmets beteenden, klientens beteenden, beräkning, lagring och databastillväxtegenskaper och hur alla dessa samverkar.

Den bästa arkitekturen är den där de här delarna är avsiktligt justerade.

Molnprestandaplanering är ett delat ansvar

En av de största fördelarna med att flytta till en betrodd molnplattform är modellen med delat ansvar. Microsoft tillhandahåller global infrastruktur, hanterade tjänster, maskinvaruinnovation, tillförlitlighet, säkerhet och driftteknik. Dina team tar med sig specifika kunskaper om programkontext: affärskritiskhet, arbetsbelastningsbeteende, design av datamodeller, nätverkstrafikprofil, tillväxtförväntningar, återställningsmål och krav för slutanvändarens upplevelse.

De starkaste resultaten uppstår när dessa två krafter är enade.

Azure tillhandahåller mycket skalbar Postgres-infrastruktur, men ditt team måste ge insikter till följande områden:

• Hur många samtidiga användare förväntas under normala perioder och perioder med hög belastning?
• Är de viktigaste åtgärderna läsintensiva, skrivintensiva eller blandade?
• Ökar efterfrågan under månadsslut, kvartalsslut, helgdagar, lanseringar eller rapporteringsfönster?
• Hur snabbt växer datamängden?
• Vilka åtgärder är svarstidskänsliga?
• Vilka frågor eller jobb kan tolerera längre körning?
• Är arbetsbelastningen främst OLTP, OLAP eller hybrid?
• Finns klienter nära databasregionen, globalt distribuerade eller koncentrerade i ett geografiskt område?

Samla in den här informationen före distributionen, inte efter en produktionsincident. Molndistributioner gör skalning enklare, men de mest högpresterande och mest kostnadseffektiva designerna börjar fortfarande med insamling av ljudkrav och korrekt planering. I de flesta fall kan dessa frågor destilleras ned till relationerna mellan samtidiga anslutningar, maximalt IOPS och nödvändigt dataflöde.

Prestanda har flera lager

Databasprestanda bestäms sällan av en enda inställning. Lyckade distributionsupplevelser beror på att flera lager fungerar tillsammans:

• Prestanda på programnivå.
  Det här lagret innehåller programkod, frågemönster, indextäckning, utlösaranvändning, datapartitionering, anslutningshantering, cachelagring, logik för återförsök, poolning, ORM-beteende, transaktionsdesign och bakgrundsjobbsbeteende.
• Prestanda för klient- och nätverksnivå.
  Det här lagret omfattar var klienter finns, hur de ansluter, om begäranden korsar regioner och tillgänglighetszoner, nätverksfördröjning, TLS-omkostnader, anslutningsfrekvens och om programmet effektivt använder anslutningspoolning.
• Prestanda för databasplattform.
  Det här lagret omfattar Postgres-distributionskonfiguration, beräkningsstorlek, minne, CPU, lagringstyp, lagringsstorlek, lagrings-IOPS, dataflöde för lagring, hög tillgänglighet, repliker och underhållsåtgärder.

Den här artikeln fokuserar främst på det tredje lagret: planera Azure Postgres-databasdistribution så att val av beräkning och lagring stöder den prestandaprofil som krävs.

Azure Database for PostgreSQL erbjuder flexibilitet, men planering är viktigt

Azure Database for PostgreSQL Flexibel server innehåller en mängd olika distributionsalternativ, bland annat:

Den här flexibiliteten är kraftfull eftersom olika arbetsbelastningar kräver olika funktioner. Ett skrivintensivt transaktionssystem behöver inte samma profil som ett rapporteringsintensivt system. Ett globalt SaaS-program behöver inte samma design som ett internt regionalt program. En databas som växer 5% per år behöver inte samma lagringsplan som en växande 200% månad över månad.

Planeringsmålet är att identifiera dina arbetsbelastningsprestandaprofilbehov och sedan implementera rätt alternativ för både beräkning och lagring för att leverera dina lösningar från slutpunkt till slutpunkt.

Börja med arbetsbelastningsprofilen

Definiera arbetsbelastningen innan du väljer beräkning eller lagring. Användbara planeringsdimensioner är:

Målet är inte att förutsäga framtiden perfekt. Målet är att undvika att designa utan eftertanke.

Förstå de tre grundläggande begreppen för lagringsprestanda

Azure planering av lagringsprestanda beror vanligtvis på tre relaterade men distinkta begrepp: IOPS, dataflöde och svarstid. Dessa faktorer är viktiga för programprestandaplanering.

IOPS

IOPS innebär in- och utdataåtgärder per sekund. Den mäter hur många läs- eller skrivåtgärder som databasen kan skicka till lagringen varje sekund.

IOPS är särskilt viktigt för OLTP-arbetsbelastningar. Dessa system utför ofta många små, slumpmässiga läsningar och skrivningar, till exempel infogningar, uppdateringar, indexsökningar, punktläsningar och korta transaktioner. En transaktionsarbetsbelastning med tusentals samtidiga användare kan behöva hög IOPS även om varje enskild åtgärd är liten.

Vanliga IOPS-känsliga scenarier är:

• Orderbearbetning med stora volymer
• Uppdateringar av användarprofil
• Inventeringssystem
• Händelseinmatning
• Betalnings- eller faktureringssystem
• Mycket samtidiga SaaS-program

Genomflöde

Dataflöde, som ibland kallas bandbredd, mäter hur mycket data som kan läsas från eller skrivas till lagring över tid. Det uttrycks i MB/s.

Dataflödet är viktigt när åtgärder flyttar stora mängder data. Analysfrågor, säkerhetskopieringar, återställningar, batchjobb, indexversioner, tabellgenomsökningar och ETL-arbetsflöden kan behöva högt dataflöde även om de inte kräver högsta IOPS.

Vanliga dataflödeskänsliga scenarier är:

• Rapportera frågor över stora tabeller
• Massimport eller exporter
• Genomsökningar i informationslagerformat
• Säkerhetskopierings- och återställningsåtgärder
• Stora åtgärder för att skapa eller återskapa index
• Batchbearbetning

Fördröjning

Svarstid är den tid det tar för en enskild I/O-begäran att slutföras. Låg svarstid är viktigt för användarriktade databasåtgärder, särskilt när många små åtgärder är sammanlänkade i en transaktion.

Ett system kan ha hög teoretisk IOPS men ändå kännas långsamt om svarstiden är hög. För Postgres-arbetsbelastningar kan lagringsfördröjning direkt påverka svarstider för frågor, beteende för transaktionsincheckning, kontrollpunktsbeteende och övergripande svarstider för program.

IOPS, dataflöde och svarstid måste beaktas tillsammans

IOPS och dataflöde är anslutna. En arbetslast som använder flera små 8-KiB-operationer kan resultera i hög IOPS utan högt dataflöde. En arbetslast som utfärdar stora multi-MB-operationer kan leda till högt dataflöde med lägre IOPS.

Ett enkelt sätt att tänka på det:

IOPS x I/O-storlek = Dataflöde

För Postgres är den praktiska innebörden att planeringen för lagring av arbetsbelastningar ska baseras på observerat eller uppskattat arbetsbelastningsbeteende, inte enbart databasstorlek. Som exempel:

• Ett OLTP-system med hög samtidighet kan behöva mer IOPS och kortare svarstid.
• Ett rapporteringsintensivt system kan behöva mer dataflöde.
• Ett hybridsystem kan behöva båda, särskilt under toppcykler.
• Ett OLTP-system med hög samtidighet kan behöva mer IOPS och kortare svarstid.
• Ett rapporteringsintensivt system kan behöva mer dataflöde.
• Ett hybridsystem kan behöva båda, särskilt under toppcykler.

Dina distributionsalternativ påverkar lagringsprestanda direkt

Ett vanligt misstag är att ange lagringen för ett målprestandanummer utan att helt överväga om den valda beräknings-SKU:n kan köra samma prestandanivåer.

Azure lagringsprestanda har flera överväganden. I den här informationen ingår bland annat följande:

• Beräkningskapacitetsuppsättningen (maximal beräknings-IOPS och dataflödesgränser).
• Lagringsgenereringen (SSD v1, SSD v2, Ultra Disk).
• Lagringsdiskstorleken (SSD v1-diskar under 4 096 GB inkluderar värdcache, vilket möjliggör IOPS-utbrott över standardbaslinjer).
• Lagrings-IOPS-kapaciteten.
• Lagringens genomströmningskapacitet.

Praktiskt sett: ditt effektiva prestandatak är din lägsta relevanta gräns i kedjan.

Om lagringskonfigurationen kan ge 80 000 IOPS, men beräknings-SKU:n bara kan köra 20 000 IOPS, levererar distributionen inte 80 000 IOPS. Om den virtuella datorgenerationen har stöd för hög IOPS men den valda lagringsnivån är lägre, blir lagringsnivån den begränsande faktorn.

Planering av beräkning och lagring bör ske tillsammans.

Premium SSD v1: stark baslinjeprestanda med viktigt cachelagringsbeteende

Premium SSD v1 är ett vanligt val för Azure Postgres-arbetsbelastningar som behöver förutsägbara, etablerade prestanda. Azure Postgres SSD v1-lagring stöder upp till 32 TB utrymme, 20 000 IOPS och 900 MB/s dataflöde.

Premium SSD v1 fungerar bra för arbetsbelastningar som drar nytta av värdcachning. Azure Postgres stöder värdcachelagring för SSD v1-diskstorlekar mindre än 4 096 GB. Alla diskar som har provisionerats upp till 4 095 GB kan dra nytta av värdcachelagring. När lagringen har etablerats på 4 096 GB eller mer stöds inte värdcache. Den gränsen är viktig. För Premium SSD v1-distributioner under 4 TB kan cachelagring förbättra läsprestanda och minska läsfördröjningen. Den här cachelagringen skapar utmärkt kostnads-till-prestanda-effektivitet för läsintensiva eller blandade arbetsbelastningar som passar under tröskelvärdet för cachelagring.

Varför gränsen på 4 TB är viktig

När en Premium SSD v1-distribution växer utanför intervallet cachelagring som stöds kan prestandaprofilen ändras:

• Läsningar drar inte längre nytta av värdcachen.
• Fler läsåtgärder kommer direkt från den underliggande disken.
• Läsningar räknas mot disk-IOPS och dataflödesgränser.
• Svarstidskänsliga läsarbelastningar kan uppvisa annorlunda beteende.
• En konfiguration som tidigare var effektiv kan behöva mer etablerad IOPS, mer dataflöde, beräkningsskalning, frågejustering eller ett annat lagringsalternativ.

Att överskrida 4 TB är inte dåligt, men du måste planera för det.

Om du förväntar dig att en databas ska växa över 4 TB bör du överväga det framtida tillståndet under arkitekturdesignen. En design som fungerar bra på 2 TB med cachelagring kan behöva en annan prestandaplan på 5 TB utan cachelagring.

Burst hjälper till med toppar, men ersätter inte varaktig kapacitet

Azure Postgres Premium SSD v1-lagringsallokeringar under 4 TB stöder bursts av värdcache, vilket kan vara till hjälp i följande scenarier:

• Startaktivitet
• Korta batchjobb
• Trafiktoppar
• Bearbetning i slutet av månaden
• Tillfälliga belastningstoppar

Även om bursting är användbart bör du använda det noggrant. Bursting kan absorbera tillfälliga toppar, men det bör inte vara grunden för en varaktig arbetsbelastningsefterfrågan. Om arbetsbelastningen ofta körs över baslinjen är det bättre att etablera en högre prestandanivå, justera inställningar för lagringsprestanda, skala beräkning eller ändra arbetsbelastningsmönstret.

En bra planeringsfråga är: Är detta en tillfällig topp, eller är detta det nya normala?

Tillfälliga toppar kan vara bra kandidater för bristning. Hantera en varaktig efterfrågan med avsiktlig kapacitetsplanering.

Premium SSD v2 frikopplar kapacitet, IOPS och dataflöde

Premium SSD v2 ändrar planeringsmodellen genom att avkoda diskstorlek, IOPS och dataflöde. Azure Database för PostgreSQL flexibel server stöder Premium SSD v2:

• Kapacitet från 32 GB till 64 TB.
• Upp till 80 000 IOPS.
• Upp till 1 200 MB/s genomströmning.
• Detaljerade kapacitetsjusteringar i steg om 1 GB.
• Flexibel IOPS- och dataflödeskonfiguration.
• Kortare svarstid än Premium SSD v1.
• Ingen cachelagring av värd.

Den här ändringen är ett stort skifte. Med Premium SSD v1 är prestandan mer nära kopplad till diskstorleken. Med Premium SSD v2 kan du konfigurera prestanda mer direkt kring arbetsbelastningsbehov.

En transaktionsintensiv databas kan till exempel behöva hög IOPS utan att behöva en stor mängd lagringsutrymme. Azure Postgres tillhandahåller baslinje-IOPS och dataflöde utan extra kostnad, med ytterligare IOPS och dataflöde tillgängligt för ytterligare avgifter. Premium SSD v2-erbjudanden:

• Diskar upp till 399 GB får en baslinje på 3 000 IOPS och 125 MB/s.
• Diskar som är 400 GB eller större får en baslinje på 12 000 IOPS och 500 MB/s.
• Diskar kan nå upp till 80 000 IOPS när de har minst 160 GB ledigt utrymme.
• Dataflödet kan skalas upp till 1 200 MB/s.

Premium SSD v2 är ofta attraktivt när du behöver mer exakt kontroll över kostnader och prestanda. I stället för att skala lagringskapaciteten bara för att låsa upp prestanda kan du etablera prestanda mer avsiktligt.

Ultra Disk (förhandsversion): den avancerade prestandaklassen för Azure-disk

Ultra Disk är det diskalternativ med högsta prestanda. Azure Ultra Disk erbjuder prestandanivåer upp till:

• 400 000 IOPS
• Dataflöde på 10 000 MB/s
• Kapacitet på 64 TB
• Designmål för undermillisekunders svarstid
• Oberoende konfigurerbar kapacitet, IOPS och dataflöde

Ultra Disk Storage är utformat för att driva I/O-intensiva arbetsbelastningar för toppnivådatabaser, SAP Hana och transaktionsintensiva system. Det här nya lagringserbjudandet ger förstklassiga prestanda för dina verksamhetskritiska arbetsbelastningar. Teamet måste dock överväga några viktiga distributionsfunktioner, regionala tillgänglighetsbegränsningar och konfigurationsalternativ när de planerar en distribution:

• Automatisk lagringsåterväxt stöds inte för servrar som använder Ultra Disk
• Datakryptering med kundhanterade nycklar stöds inte för servrar med Ultra Disk
• Ultra Diskar stöder inte diskcachelagring

Det är viktigt att förstå Ultra Disk-funktioner som en del av det bredare Azure lagringsprestandalandskapet. Du måste dock verifiera tjänstens tillgänglighet och support för din specifika Azure Postgres-arbetsbelastning. Kontakta din Microsoft representant om Ultra Disk Preview är tillgänglig för din Azure Postgres-distribution.

Den praktiska fördelen: Ultra Disk representerar det övre skiktet av Azure lagringsprestanda, men din Postgres-design från början till slut måste innehålla jämförbara stödkomponenter för den valda beräknings-SKU:n, regionen och versionsnivån.

VM-generering spelar roll: V5- och V6-tak för beräkningslagring skiljer sig

Beräkningsgenerering kan väsentligt påverka lagringsprestanda. När du utforskar den högsta änden av Azure lagringsprestanda bör du undvika missförståndet att "stor beräkning" automatiskt betyder "maximal lagring." Du måste verifiera den valda beräknings-SKU:n mot den avsedda lagringsnivån. Låt oss illustrera den här punkten genom att överväga två beräkningsgenerationer, Ddsv5 och Ddsv6, av liknande storlek:

Ddsv5-serien stöder Premium Storage (med cachelagring), Premium SSD v2 och Ultra Disk på vm-familjenivå. Den virtuella datorns aggregerade fjärrlagringsgränser definierar dock fortfarande taket för vad den virtuella datorn kan köra. Ddsv5-serien ger lagringsprestanda på upp till 80 000 IOPS och 2 600 MB/s.

- Ddsv6serien har ett högre lagringskuvert med upp till 400 000 IOPS och 12 000 MB/s. V6-seriens beräkning ger också högre skalbarhet än tidigare generationer, med upp till 192 vCPU och 768-GiB-minne.

Den generationsväxlingen är viktig för postgres-design med höga prestanda. Om målarkitekturen kräver höga lagringsprestanda kan valet av beräkningsgenerering med ett lägre aggregerat lagringstak hindra distributionen från att använda den fullständiga lagringsfunktionen.

Exempel: varför helhetsanpassning är viktig

Överväg en PostgreSQL-arbetsbelastning med ett ambitiöst lagringsmål på 400 000 IOPS.

På disklagret stöder Azure Ultra Disk upp till 400 000 IOPS per disk. Premium SSD v2 stöder upp till 80 000 IOPS per disk, och högre aggregeringsdesign kan kräva flera diskar eller abstraktion på plattformsnivå beroende på tjänstsupport.

Men enbart lagringskapacitet räcker inte.

En V5-seriekonfiguration kan ha ett lagringstak som är lägre än målet. Som tidigare nämnts stöder SKU:er i V5-serien upp till 260 000 IOPS för Premium SSD-fjärrdiskdataflöde. I det här fallet är valet av V5-seriens beräkningslager den begränsande faktorn innan ett IOPS-mål på 400 000 nås.

Dokumentationen i Ddsv6-serien erbjuder däremot upp till 400 000 IOPS och 12 000 MB/s. Det gör V6-serien och nyare generationer strategiskt viktiga för design som behöver justera beräkning och lagring kring de högsta lagringsprestandaklasserna.

Lektionen är enkel: maximal databasprestanda är en egenskap från slutpunkt till slutpunkt, inte en egenskap för endast lagring.

Planera för konjunkturcykler, inte bara stabilt tillstånd

Många system har inte en enda prestandaprofil. De har flera:

En databas som är dimensionerad för genomsnittlig användning kan kämpa under de momenten som spelar störst roll. Omvänt kan en databas som är permanent storleksanpassad för en topp en gång i månaden vara onödigt dyr.

Azure flexibilitet gör det möjligt för team att göra mer nyanserade val. Som exempel:

• Använd Premium SSD v2 för att justera IOPS och dataflöde när arbetsbelastningsbehoven utvecklas.
• Använd läsrepliker för att avlasta läsintensiva arbetsbelastningar där det är lämpligt.
• Skala beräkningarna under kända högbelastningsperioder.
• Justera frågor, index och anslutningspooler innan du skalar infrastrukturen.
• Använd observerbarhet för att identifiera om flaskhalsen är CPU, minne, IOPS, dataflöde, låskonkurrens, anslutningstryck eller frågedesign.

Den bästa distributionen är inte alltid den största distributionen. Det är designen som matchar arbetsbelastningen och kan utvecklas på ett säkert sätt.

Observerbarhet är en del av arkitekturen

Prestandaplaneringen bör inte stoppas vid distributionen. Postgres-arbetsbelastningar ändras över tid. Data växer, frågemönster skiftar, nya funktioner startas, kundtrafikändringar och driftjobb ackumuleras.

Azure Database for PostgreSQL-dokumentationen belyser övervakning av I/O-förbrukning via Azure Portal eller Azure CLI-mått, inklusive lagringsgräns, lagringsprocent, använd lagring och I/O-procent.

De här måtten hjälper dig att besvara den viktigaste driftfrågan: vilket lager begränsar faktiskt prestandan?

Utan observerbarhet kan team skala fel komponent. Ett problem med en frågeplan kan se ut som ett lagringsproblem. Anslutningsstormar kan se ut som CPU-belastning. Ett index som saknas kan se ut som otillräckligT IOPS. Ett regionalt problem med klientplacering kan se ut som databasfördröjning.

Övervakning hjälper team att göra riktade ändringar i stället för dyra gissningar.

Checklista för praktisk planering

Innan du väljer produktionskonfigurationen Azure Database for PostgreSQL samlar du in följande information.

Rekommenderade designprinciper

Använd följande principer när du planerar Azure Postgres-distributioner för driftprestanda.

• Storlek för arbetsbelastningsform, inte bara datastorlek.
  En 500 GB-databas kan behöva mer IOPS än en 5 TB-databas om den är mycket transaktions- och svarstidskänslig. Storlek spelar roll, men arbetsbelastningsbeteendet är viktigare.
• Verifiera beräkning och lagring tillsammans.
  Välj inte lagring baserat endast på diskgränser. Bekräfta att den valda beräknings-SKU:n kan driva nödvändig IOPS och dataflöde.
• Behandla 4 TB Premium SSD-cachelagringsgränsen som en designmilstolpe.
  Premium SSD-distributioner under 4 TB kan dra nytta av värdcachelagring. Vid 4 096 GB och senare stöds inte värdcachelagring. Om tillväxten överskrider det tröskelvärdet planerar du den framtida prestandamodellen tidigt.
• Överväg Premium SSD v2 för flexibel prestandajustering.
  Premium SSD v2 ger mer detaljerad kontroll över kapacitet, IOPS och dataflöde. Det kan passa bra när prestandabehoven inte mappas rent till fasta diskstorlekar.
• Använd utbrott för korta periodiska behov, inte långvarig efterfrågan.
  Bursting kan hjälpa till med kortvariga toppar, men frekvent eller ihållande bursting innebär vanligtvis att baslinjekonfigurationen bör ses över.
• Anpassa generationen efter ambitionen.
  För högpresterande prestandamål kan nyare beräkningsgenerationer, till exempel v6-serien, exponera högre aggregerade fjärrlagringsgränser än tidigare generell användning. Om målet är en arkitektur i 400 000 IOPS-klass väljer du beräkningsgenereringen därefter.
• Mät före och efter ändringar.
  Skalning är enklare i molnet, men mätning är det som gör skalningen effektiv. Samla in baslinje-, topp- och efterändringsmått så att prestandabeslut är evidensbaserade.

Praktiskt test: jämföra lagringskonfigurationer under belastning

Principerna som beskrivs i den här artikeln är inte teoretiska. För att visa hur beräkning, lagring och arbetsbelastning interagerar i praktiken sammanfattar pgbench det här avsnittet riktmärken som jämför lagringskonfigurationer och beräkningsnivåer under kontrollerade, uppmätta förhållanden.

Benchmark-konfiguration och metodik

Benchmarks använder pgbenchstandardverktyget PostgreSQL för att simulera en transaktionsarbetsbelastning i fem olika lagrings- och beräkningskonfigurationer. Testet börjar med 500 samtidiga anslutningar och rampar upp till 750 samtidiga anslutningar efter en inledande period, vilket behåller denna förhöjda anslutningsbelastning under resten av testfönstret. Det här ramp-up-mönstret simulerar hur många verkliga applikationer ökar belastningen över tid när trafiken växer och mäter hur databasen svarar på både den initiala toppen och ihållande hög samtidighet av användare.

Alla prestandamått körs på Azure Database for PostgreSQL flexibel server i samma region, inom samma tillgänglighetszon, med samma testdatabas och arbetsbelastningsprofil. Genom att isolera lagring och beräkning som variabler ser du till att prestandaskillnaderna återspeglar de faktiska plattformsfunktionerna snarare än nätverks-, program- eller arbetsbelastningsvarianter.

Konfigurationsdetaljer

Testa fem distinkta konfigurationer, som varierar både lagringsnivå och beräkningsstorlek för att illustrera viktiga planeringsbegrepp.

Viktiga observationer från konfigurationsdesignen:

• Konfiguration 1 jämfört med konfiguration 2: Dessa konfigurationer skiljer sig bara åt i lagringsstorlek, 4 095 GB jämfört med 4 096 GB. Den här jämförelsen testar gränsen för värdcachelagring för Premium SSD v1-diskar.
• Konfiguration 2 jämfört med konfiguration 3: Båda konfigurationerna använder SSD v1, men Config 3 skalar till 32 TB kapacitet för att låsa upp högre IOPS och dataflöde.
• Konfiguration 3 jämfört med konfiguration 4: Båda konfigurationerna använder samma beräkning, men Config 4 visar flexibel IOPS för Premium SSD v2 och dataflöde oberoende av kapacitet.
• Konfiguration 4 jämfört med Config 5: Config 5 fördubblar beräknings-SKU:n för att visa hur beräkning på högre nivå låser upp mer utrymme för lagringsprestanda.

Prestandaresultat

Konfiguration 1: 4 095 GB Premium SSD v1 med värdcache

Konfiguration 1 använder Premium SSD v1-storleken 4 095 GB, som drar nytta av värdcachelagring på Premium SSD v1. Under arbetsbelastningen fortsatte den här konfigurationen:

• Max IOPS: 24 773, begränsat till 7 500 etablerade IOPS på Premium SSD v1, med cachelagring som förstärker effektiva prestanda.
• Högsta läs-IOPS: 21 330, vilket drar nytta av värdcachen för läsintensiva åtgärder.
• Maximalt skriv-IOPS: 7 610.

Värdcachelagring ger läsförstärkning, så effektiv IOPS överskrider tillfälligt diskens 7 500 etablerade IOPS-gräns och når beräkningslagringsgränser.

Konfiguration 2: 4 096 GB Premium SSD v1 utan cachelagring på värd

Konfiguration 2 använder storleken 4 096 GB Premium SSD v1, vilket överskrider cachegränsen och förlorar cachefördelar för värden. Effekten är synlig:

• Maximalt antal IOPS: Lägre effektiv IOPS jämfört med Config 1 på grund av förlust av cachelagring.
• Högsta läs-IOPS: Avsevärt reducerad utan värdcachen.
• Maximalt skrivskyddat IOPS: 7 610, oförändrat.

Den här konfigurationen visar den praktiska betydelsen av cachelagringsgränsen på 4 TB. Om du går från 4 095 GB till 4 096 GB ändras prestandaprofilen genom att cachelagrade läsningar tas bort. Planera framåt för växande databaser som närmar sig det här tröskelvärdet.

Konfiguration 3: 32 TB Premium SSD v1 med högre IOPS

Konfiguration 3 adresserar övre IOPS- och dataflödesgränser för Premium SSD v1 genom att skala till 32 TB kapacitet. Den här konfigurationen gav följande resultat:

• Max IOPS: 20 000.
• Högsta läs-IOPS: Cirka 12 000.
• Maximalt antal skriv-IOPS: Cirka 5 000.

Om du ökar den underliggande Premium SSD v1-lagringskapaciteten ökar IOPS och dataflödet. Du kan fortfarande nå de övre gränserna för beräkningslagringsintervallet för intensiva arbetsbelastningar.

Konfiguration 4: Premium SSD v2 med 40 000 IOPS

Konfiguration 4 visar flexibel prestandakonfiguration för Premium SSD v2, etablering av 40 000 IOPS och 1 200 MB/s-dataflöde på 4 095 GB kapacitet:

• Maximalt antal IOPS: Högre effektiv användning på grund av Premium SSD v2-svarstid och dataflödeskapacitet.
• Högsta läs-IOPS: Bättre prestanda jämfört med Premium SSD v1-konfigurationer.
• Maximalt antal skriv-IOPS: Högre bibehållen skrivkapacitet.

Premium SSD v2 tillåter etablering av hög IOPS utan att kräva stor lagringskapacitet, vilket gör det effektivt för transaktionsintensiva arbetsbelastningar.

Konfiguration 5: Premium SSD v2 med 60 000 IOPS på D32ds_v5 beräkning

Konfiguration 5 skalar både lagringsprestanda vid 60 000 IOPS och beräkning, med Standard_D32ds_v5 och 32 virtuella kärnor. Den här konfigurationen visar principen för justering från slutpunkt till slutpunkt:

• Maximalt antal IOPS: Betydligt högre än alla tidigare konfigurationer.
• Högsta läs-IOPS: Stark förbättring med extra beräkningsutrymme.
• Maximalt antal skriv-IOPS: Bibehållen högre skrivkapacitet.

Genom att justera både beräkning och lagring till högre prestandanivåer uppnår den här konfigurationen det bästa dataflödet och det lägsta CPU-trycket. Det högre lagringstaket för D32ds_v5 gör att 60,000-IOPS Premium SSD v2-disken kan användas fullt ut.

Lärdomar från riktmärkena

Dessa fem konfigurationer illustrerar huvudprinciperna i den här artikeln:

• Gränsen för cachelagring på 4 TB är viktig.
  Config 1 jämfört med Config 2 visar att värdcachelagring ger mätbar läsprestandaförstärkning under 4 TB, medan övergången till 4 096 GB tar bort den fördelen.
• Kapacitet är inte prestanda.
  Config 3 konfigurerade 32 TB men levererade inte högsta IOPS. Enbart lagringskapacitet avgör inte transaktionsdataflödet.
• Premium SSD v2 ger flexibel prestandajustering.
  Config fyra visade hög IOPS på blygsam kapacitet, vilket validerade den frikopplade modellen som möjliggörs av Premium SSD v2.
• Beräkning och lagring måste justeras.
  Konfiguration fem visar att det krävs tillräckligt med beräkningsutrymme för att maximera lagringsprestandan. Det högre lagringstaket för D32ds_v5 var nödvändigt för att fullt ut utnyttja möjligheten till 60 000 IOPS.

Prestandatestresultatet validerar huvudprincipen: maximal prestanda är en egenskap från slutpunkt till slutpunkt. Inget enskilt lager, till exempel lagring, beräkning eller nätverk, avgör resultatet. För att lyckas krävs avsiktlig justering över alla lager, uppmätt validering och kontinuerlig observation alltefter som arbetsbelastningar utvecklas.

Slutsats

Azure Postgres är en kraftfull och flexibel plattform för att skapa moderna, molnbaserade databaslösningar. Tekniken för Azure Beräkning, lagring, nätverk, hög tillgänglighet, replikering, säkerhet och observerbarhet möjliggör några av de mest högpresterande och motståndskraftiga Postgres-arkitekturerna.

Maximal prestanda inträffar inte av misstag.

Maximal driftprestanda kräver att du förstår programmet, klienterna, arbetsbelastningen, datatillväxtprofilen, läs-/skrivmixen och de konjunkturcykler som formar efterfrågan. Det kräver också justering av både beräknings- och lagringsalternativ så att mål för IOPS, dataflöde och svarstid uppnås från slutpunkt till slutpunkt.

Premium SSD v1 kan ge stark förutsägbar prestanda, särskilt när värdcachelagring gäller för data under gränsen på 4 TB. Premium SSD v2 lägger till mer flexibel prestandakonfiguration genom avkoppling av kapacitet, IOPS och dataflöde. Ultra Disk representerar den högsta Azure prestandaklassen för hanterade diskar, medan nyare beräkningsgenerationer ger betydligt högre aggregerade fjärrlagringstak för avancerade arkitekturer.

De bästa Azure Postgres-distributionerna kombinerar plattformskapacitet med avsiktlig planering, kontinuerlig övervakning och tydligt driftägarskap. Med rätt krav och rätt arkitektur kan team leverera Postgres-upplevelser i världsklass som ger högsta prestanda.

Relaterat innehåll

• Azure Premium Storage: design för höga prestanda
• Azure disk bursting
• Storlekar på virtuella datorer i Ddv5- och Ddsv5-serien
• Storlekar på virtuella datorer i Ddsv6-serien
• Premium SSD-lagringsalternativ i Azure Database for PostgreSQL
• lagringsalternativet Premium SSD v2 i Azure Database for PostgreSQL
• Hanterade disktyper i Azure
• Övervaka mått i Azure Database for PostgreSQL