Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Azure DocumentDB-beräkningsresurser tillhandahålls som virtuella kärnor, som representerar den underliggande maskinvarans logiska PROCESSOR. Lagringsstorleken för etablering refererar till den kapacitet som är tillgänglig för fragmenten i klustret.
Lagringen används för databasfiler, temporära filer, transaktionsloggar och databasserverloggarna. Du kan välja inställningarna för beräkning och lagring oberoende av varandra. De valda beräknings- och lagringsvärdena gäller för varje shard i klustret.
Beräkning i Azure DocumentDB
Den totala mängden RAM-minne i en enda shard baseras på det valda antalet virtuella kärnor.
| Klusternivå | vCores | En fragment, GiB RAM |
|---|---|---|
| M10 | 1 (sprickbar) | 2 |
| M20 | 2 (burstkapacitet) | 4 |
| M25 | 2 (burstable) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Lagring i Azure DocumentDB
Den totala mängden lagringsutrymme som du tilldelar definierar också den I/O-kapacitet som är tillgänglig för varje shard i klustret.
| Lagringsstorlek, GiB | Maximalt antal IOPS |
|---|---|
| 32 | 3,500† |
| 64 | 3,500† |
| 128 | 3,500† |
| 256 | 3,500† |
| 512 | 3,500† |
| 1,024 | 5,000 |
| 2,048 | 7,500 |
| 4,095 | 7,500 |
| 8,192 | 16,000 |
| 16,384 | 18,000 |
| 32,767 | 20,000 |
† Max IOPS (indata-/utdataåtgärder per sekund) med fri disksprängning. Lagring upp till och med 512 GiB kommer med fri disk bursting aktiverat.
Maximera IOPS för din beräknings- och lagringskonfiguration
Varje beräkningskonfiguration har en IOPS-gräns som beror på antalet virtuella kärnor. Se till att du väljer beräkningskonfiguration för klustret för att fullt ut använda IOPS i den valda lagringen.
| Lagringsstorlek | Lagrings-IOPS, upp till | Lägsta beräkningsnivå | Min vCores |
|---|---|---|---|
| Upp till 0,5 TiB | 3,500† | M30 | 2 virtuella kärnor |
| 1 TiB | 5,000 | M40 | 4 virtuella kärnor |
| 2 TiB | 7,500 | M50 | 8 virtuella kärnor |
| 4 TiB | 7,500 | M50 | 8 virtuella kärnor |
| 8 TiB | 16,000 | M60 | 16 virtuella kärnor |
| 16 TiB | 18,000 | M60 | 16 virtuella kärnor |
| 32 TiB | 20,000 | M60 | 16 virtuella kärnor |
† Max IOPS med fri disksprängning. Lagring upp till och med 512 GiB kommer med fri disk bursting aktiverat.
Om du till exempel behöver 8 TiB lagringsutrymme per shard eller mer kontrollerar du att du väljer 16 virtuella kärnor eller mer för nodens beräkningskonfiguration. Med det valet kan du maximera IOPS-användningen som tillhandahålls av den valda lagringen.
Överväganden för beräkning och lagring
När du konfigurerar ditt Azure DocumentDB-kluster är det viktigt att förstå hur val av beräkning och lagring påverkar prestanda, kostnad och skalbarhet för din specifika arbetsbelastning.
Överväganden för arbetsuppsättning och minne
I Azure DocumentDB refererar arbetsuppsättningen till den del av dina data som används ofta av dina program. Den innehåller både data och index som regelbundet läses eller skrivs till under programmets vanliga åtgärder. Konceptet med en arbetsuppsättning är viktigt för prestandaoptimering eftersom MongoDB, liksom många databaser, presterar bäst när arbetsuppsättningen passar i RAM-minnet.
Tänk på följande komponenter för att definiera och förstå mongoDB-databasens arbetsuppsättning:
- Data som används ofta: Dessa data innehåller dokument som programmet läser eller uppdaterar regelbundet.
- Index: Index som används i frågeåtgärder ingår också i arbetsuppsättningen eftersom de måste läsas in i minnet för att säkerställa snabb åtkomst.
- Användningsmönster för program: Genom att analysera användningsmönstren i ditt program kan du identifiera vilka delar av dina data som används oftast.
Genom att behålla arbetsuppsättningen i RAM-minnet kan du minimera långsammare disk-I/O-åtgärder, vilket förbättrar prestandan för din MongoDB-databas. Om din arbetsuppsättning överskrider det tillgängliga RAM-minnet bör du överväga att optimera datamodellen, lägga till mer RAM-minne i klustret eller använda horisontell partitionering för att distribuera data över flera noder.
Välj optimal konfiguration för en arbetsbelastning
Att fastställa rätt beräknings- och lagringskonfiguration för din Azure DocumentDB-arbetsbelastning innebär att utvärdera flera faktorer som är relaterade till programmets krav och användningsmönster. De viktigaste stegen och övervägandena för att fastställa den optimala konfigurationen är:
Förstå din arbetsbelastning
- Datavolym: Beräkna den totala storleken på dina data, inklusive index.
- Läs-/skrivförhållande: Fastställa förhållandet mellan läsåtgärder och skrivåtgärder.
- Frågemönster: Analysera de typer av frågor som programmet utför. Till exempel enkla läsningar, komplexa aggregeringar.
- Samtidighet: Utvärdera antalet samtidiga åtgärder som databasen behöver hantera.
Övervaka aktuella prestanda
- Resursanvändning: Använd övervakningsverktyg för att spåra processor-, minnes-, disk-I/O- och nätverksanvändning innan du migrerar din arbetsbelastning till Azure. När du har distribuerat Din MongoDB-arbetsbelastning i ett Azure DocumentDB-kluster fortsätter du att övervaka med hjälp av Azure-övervakningsmått.
- Prestandamått: Övervaka viktiga prestandamått som svarstid, dataflöde och cacheträffar.
- Flaskhalsar: Identifiera eventuella befintliga flaskhalsar för prestanda, till exempel hög CPU-användning, minnestryck eller långsam disk-I/O.
Beräkna resurskrav
- Minne: Se till att din arbetsuppsättning (data och index som används ofta) passar in i RAM-minnet. Om storleken på din arbetsuppsättning överskrider det tillgängliga minnet kan du överväga att lägga till mer RAM-minne eller optimera datamodellen.
- CPU: Välj en CPU-konfiguration som kan hantera frågebelastnings- och samtidighetskraven. CPU-intensiva arbetsbelastningar kan kräva fler kärnor. Använd måttet "CPU-procent" med "Max"-aggregering i ditt Azure DocumentDB-kluster för att se historiska användningsmönster för beräkning.
- Lagrings-IOPS: Välj lagring med tillräckligt med IOPS för att hantera läs- och skrivåtgärder. Använd måttet "IOPS" med "Max"-sammansättning i klustret för att se historisk IOPS-användning för lagring.
- Nätverk: Se till att nätverksbandbredden är tillräcklig för att hantera dataöverföring mellan ditt program och databasen, särskilt för distribuerade installationer. Se till att du har konfigurerat värden för din MongoDB-applikation att stödja accelererad nätverksteknik som till exempel SR-IOV.
Skala på rätt sätt
-
Lodrät skalning: Skalar upp och ned beräkning/RAM-minne och skala upp lagringen.
- Beräkning: Öka vCore / RAM i ett kluster om din arbetsbelastning kräver en tillfällig ökning eller ofta överskrider 70% CPU-användning under längre tidsperioder.
- Kontrollera att du har rätt datakvarhållning i Azure DocumentDB-databasen. Med kvarhållning kan du undvika onödig lagringsanvändning. Övervaka lagringsanvändningen genom att ange aviseringar för måtten "Lagringsprocent" och/eller "Lagring som används" med "Max"-aggregering. Överväg att öka lagringen när din arbetsbelastningsstorlek överskrider 70% användning.
- Horisontell skalning: Överväg att använda flera shards för klustret för att distribuera dina data över flera Azure DocumentDB-noder för prestandavinster och bättre kapacitetshantering när arbetsbelastningen växer. Den här skalningen är särskilt användbar för stora datamängder (över 2–4 TiB) och program med högt dataflöde.
-
Lodrät skalning: Skalar upp och ned beräkning/RAM-minne och skala upp lagringen.
Testa och iterera
- Benchmarking: Utför mätning för de vanligaste frågorna med olika konfigurationer för att fastställa effekten på prestanda. Använd CPU/RAM- och IOPS-mått och benchmarking på programnivå.
- Belastningstestning: Utför belastningstestning för att simulera produktionsarbetsbelastningar och verifiera prestanda för den valda konfigurationen.
- Kontinuerlig övervakning: Övervaka din Azure DocumentDB-distribution kontinuerligt och justera resurser efter behov baserat på ändrade arbetsbelastningar och användningsmönster.
Genom att systematiskt utvärdera dessa faktorer och kontinuerligt övervaka och justera konfigurationen kan du se till att MongoDB-distributionen är väl optimerad för din specifika arbetsbelastning.
Överväganden för lagring
Att bestämma lämplig lagringsstorlek för din arbetsbelastning innebär flera överväganden för att säkerställa optimal prestanda och skalbarhet. Här följer några överväganden för lagringsstorleken i Azure DocumentDB:
Beräkna datastorlek:
- Beräkna den förväntade storleken på dina Azure DocumentDB-data. Överväga:
- Aktuell datastorlek: Om du migrerar från en befintlig databas.
- Tillväxttakt: Uppskatta hur mycket data som ska läggas till över tid.
- Dokumentstorlek och struktur: Förstå dataschemat och dokumentstorlekarna eftersom de påverkar lagringseffektiviteten.
- Beräkna den förväntade storleken på dina Azure DocumentDB-data. Överväga:
Inkludera i index:
- Azure DocumentDB använder index för effektiv frågekörning. Index förbrukar extra diskutrymme.
- Beräkna storleken på index baserat på:
- Antal index.
- Storleken på indexerade fält.
Prestandaöverväganden:
- Diskprestanda påverkar databasåtgärder, särskilt för arbetsbelastningar som inte kan passa sin arbetsmängd i RAM-minnet. Överväga:
- I/O-dataflöde: IOPS eller indata-/utdataåtgärder per sekund är antalet begäranden som skickas till lagringsdiskar på en sekund. Den större lagringsstorleken levereras med mer IOPS. Se till att dataflödet är tillräckligt för läs-/skrivåtgärder. Använd metrik "IOPS" med aggregeringen "Max" för att övervaka användningen av IOPS i ditt kluster.
- Latens: Svarstiden är den tid det tar för ett program att ta emot en enda begäran, skicka den till lagringsdiskar och skicka svaret till klienten. Svarstid är ett kritiskt mått på ett programs prestanda utöver IOPS och dataflöde. Typen av lagring som används och lagringskonfigurationen definierar till stor del svarstiden. I en hanterad tjänst som Azure DocumentDB används det snabba lagringsutrymmet, till exempel Premium SSD-diskar, med inställningar som är optimerade för att minska svarstiden.
- Diskprestanda påverkar databasåtgärder, särskilt för arbetsbelastningar som inte kan passa sin arbetsmängd i RAM-minnet. Överväga:
Framtida tillväxt och skalbarhet:
- Planera för framtida datatillväxt och skalbarhetsbehov.
- Allokera mer diskutrymme utöver dagens behov för att hantera tillväxt utan frekventa lagringsexpansioner.
Exempelberäkning:
- Anta att din ursprungliga datastorlek är 500 GiB.
- Med index kan den växa till 700 GiB.
- Om du förväntar dig en fördubbling av data om två år planerar du för 1,4 TiB (700 GiB * 2).
- Lägg till en buffert för omkostnader, tillväxt och driftbehov.
- Du kanske vill börja med 1 TiB-lagring idag och skala upp den till 2 TiB när dess storlek växer över 800 GiB.
Att bestämma lagringsstorlek innebär en kombination av att uppskatta aktuella och framtida databehov, överväga indexering och komprimering och säkerställa tillräcklig prestanda och skalbarhet. Regelbunden övervakning och justering baserat på faktiska användnings- och tillväxttrender är också avgörande för att upprätthålla optimala MongoDB-prestanda.
Vad är burstbar beräkning?
Burstable-nivån erbjuder en intelligent lösning som är skräddarsydd för små databasarbetsbelastningar. Genom att ge minimal CPU-prestanda under inaktiva perioder optimerar dessa kluster resursanvändningen. Den verkliga briljansen ligger dock i deras förmåga att sömlöst skala upp till full CPU-ström som svar på ökade trafik- eller arbetsbelastningskrav. Den här anpassningsbarheten ger högsta prestanda exakt när det behövs, samtidigt som du ger betydande kostnadsbesparingar.
Genom att minska den initiala prispunkten för tjänsten syftar Azure DocumentDB:s Burstable Cluster Tier till att underlätta användarnas registrering och utforskning av Azure DocumentDB till lägre priser. Den här demokratiseringen av åtkomsten gör det möjligt för företag av alla storlekar att utnyttja kraften i Azure DocumentDB utan att det kostar skjortan. Oavsett om du är en startup, ett litet företag eller ett företag öppnar den här nivån nya möjligheter för kostnadseffektiv skalbarhet.
Det är lika enkelt att etablera en burstbar nivå som att etablera vanliga nivåer. du behöver bara välja "M10", "M20" eller "M25" i klusternivåalternativet. Här är en snabbstartsguide som innehåller stegvisa instruktioner om hur du konfigurerar ett Azure DocumentDB-kluster .