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.
Azure DocumentDB-rekenresources worden geleverd als vCores, die de logische CPU van de onderliggende hardware vertegenwoordigen. De opslaggrootte voor het inrichten verwijst naar de capaciteit die beschikbaar is voor de shards in uw cluster.
De opslag wordt gebruikt voor databasebestanden, tijdelijke bestanden, transactielogboeken en de databaseserverlogboeken. U kunt de reken- en opslaginstellingen onafhankelijk selecteren. De geselecteerde reken- en opslagwaarden zijn van toepassing op elke shard in het cluster.
Compute in Azure DocumentDB
De totale hoeveelheid RAM in één shard is gebaseerd op het geselecteerde aantal vCores.
| Clusterlaag | virtuele cores | Een shard, GiB RAM |
|---|---|---|
| M10 | 1 (uitbreidbaar) | 2 |
| M20 | 2 (bustbaar) | 4 |
| M25 | 2 (burstable) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Opslag in Azure DocumentDB
De totale hoeveelheid opslagruimte die u toewijst, definieert ook de I/O-capaciteit die beschikbaar is voor elke shard in het cluster.
| Opslaggrootte, GiB | Maximale 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 (invoer-/uitvoerbewerkingen per seconde) met vrije schijf bursting. Opslag tot 512 GiB inclusief wordt geleverd met gratis schijf-bursting ingeschakeld.
IOPS maximaliseren voor uw reken- en opslagconfiguratie
Elke rekenconfiguratie heeft een IOPS-limiet die afhankelijk is van het aantal vCores. Zorg ervoor dat u de rekenconfiguratie voor uw cluster selecteert om volledig gebruik te maken van IOPS in de geselecteerde opslag.
| Opslaggrootte | Opslag-IOPS, tot | Minimale rekenlaag | Minimale vCores |
|---|---|---|---|
| Maximaal 0,5 TiB | 3,500† | M30 | 2 vCores |
| 1 TiB | 5.000 | M40 | 4 vCores |
| 2 TiB (tebibyte) | 7,500 | M50 | 8 vCores |
| 4 TiB | 7,500 | M50 | 8 vCores |
| 8 TiB | 16.000 | M60 | 16 vCores |
| 16 TiB | 18,000 | M60 | 16 vCores |
| 32 Tebibyte (TiB) | 20,000 | M60 | 16 vCores |
† Maximale IOPS met vrije schijf-bursting. Opslag tot 512 GiB inclusief wordt geleverd met gratis schijf-bursting ingeschakeld.
Als u bijvoorbeeld 8 TiB opslagruimte per shard of meer nodig hebt, moet u 16 vCores of meer selecteren voor de rekenconfiguratie van het knooppunt. Met deze selectie kunt u het IOPS-gebruik dat wordt geleverd door de geselecteerde opslag maximaliseren.
Overwegingen voor berekening en opslag
Bij het configureren van uw Azure DocumentDB-cluster is het belangrijk om te begrijpen hoe reken- en opslagkeuzen van invloed zijn op prestaties, kosten en schaalbaarheid voor uw specifieke workload.
Aandachtspunten voor werkset en geheugen
In Azure DocumentDB verwijst de werkset naar het gedeelte van uw gegevens dat vaak wordt geopend en gebruikt door uw toepassingen. Het bevat zowel de gegevens als de indexen waarnaar regelmatig wordt gelezen of geschreven tijdens de typische bewerkingen van de toepassing. Het concept van een werkset is belangrijk voor prestatieoptimalisatie omdat MongoDB, net als veel databases, het beste presteert wanneer de werkset in ram-geheugen past.
Als u uw MongoDB-databasewerkset wilt definiëren en begrijpen, moet u rekening houden met de volgende onderdelen:
- Veelgebruikte gegevens: deze gegevens bevatten documenten die uw toepassing regelmatig leest of bijwerken.
- Indexen: indexen die worden gebruikt in querybewerkingen maken ook deel uit van de werkset, omdat ze in het geheugen moeten worden geladen om snelle toegang te garanderen.
- Gebruikspatronen van toepassingen: door de gebruikspatronen van uw toepassing te analyseren, kunt u bepalen welke delen van uw gegevens het vaakst worden geopend.
Door de werkset in ram-geheugen te behouden, kunt u tragere I/O-bewerkingen van de schijf minimaliseren, waardoor de prestaties van uw MongoDB-database worden verbeterd. Als uw werkset het beschikbare RAM-geheugen overschrijdt, kunt u overwegen uw gegevensmodel te optimaliseren, meer RAM aan uw cluster toe te voegen of sharding te gebruiken om gegevens over meerdere knooppunten te distribueren.
De optimale configuratie voor een workload kiezen
Het bepalen van de juiste reken- en opslagconfiguratie voor uw Azure DocumentDB-workload omvat het evalueren van verschillende factoren met betrekking tot de vereisten en gebruikspatronen van uw toepassing. De belangrijkste stappen en overwegingen voor het bepalen van de optimale configuratie zijn:
Inzicht in uw workload
- Gegevensvolume: Schat de totale grootte van uw gegevens, inclusief indexen.
- Lees-/schrijfverhouding: Bepaal de verhouding tussen leesbewerkingen en schrijfbewerkingen.
- Querypatronen: Analyseer de typen query's die uw toepassing uitvoert. Eenvoudige leesbewerkingen, complexe aggregaties.
- Gelijktijdigheid: beoordeel het aantal gelijktijdige bewerkingen dat uw database moet verwerken.
Huidige prestaties bewaken
- Resourcegebruik: gebruik bewakingshulpprogramma's om CPU, geheugen, schijf-I/O en netwerkgebruik bij te houden voordat u uw workload naar Azure migreert. Nadat u uw MongoDB-workload op een Azure DocumentDB-cluster hebt geïmplementeerd, kunt u doorgaan met bewaken met metrische gegevens van Azure.
- Metrische gegevens over prestaties: bewaak belangrijke prestatiegegevens, zoals latentie, doorvoer en verhoudingen voor cachetreffers.
- Knelpunten: identificeer eventuele bestaande knelpunten in de prestaties, zoals hoog CPU-gebruik, geheugendruk of trage schijf-I/O.
Middelenbehoeften inschatten
- Geheugen: Zorg ervoor dat uw werkset (vaak gebruikte gegevens en indexen) in het RAM-geheugen past. Als de grootte van uw werkset groter is dan het beschikbare geheugen, kunt u meer RAM toevoegen of uw gegevensmodel optimaliseren.
- CPU: Kies een CPU-configuratie die uw querybelasting en gelijktijdigheidsvereisten kan verwerken. CPU-intensieve werkbelastingen kunnen meer kernen vereisen. Gebruik de metriek 'CPU-percentage' met de 'Max'-aggregatie in uw Azure DocumentDB-cluster om historische patronen van rekengebruik te bekijken.
- Opslag-IOPS: selecteer opslag met voldoende IOPS om uw lees- en schrijfbewerkingen af te handelen. Gebruik de metrische waarde 'IOPS' met max-aggregatie in uw cluster om het IOPS-gebruik van historische opslag te bekijken.
- Netwerk: zorg voor voldoende netwerkbandbreedte voor het afhandelen van gegevensoverdracht tussen uw toepassing en de database, met name voor gedistribueerde instellingen. Zorg ervoor dat u de host voor uw MongoDB-toepassing hebt geconfigureerd ter ondersteuning van versnelde netwerktechnologieën zoals SR-IOV.
Schaal op de juiste manier
-
Verticaal schalen: schaalt rekenkracht/RAM omhoog en omlaag en schaal de opslag omhoog.
- Compute: Verhoog de vCore/RAM op een cluster als voor uw workload een tijdelijke toename is vereist of vaak meer dan 70% CPU-gebruik gedurende langere perioden is overschreden.
- Zorg ervoor dat u over de juiste gegevensretentie beschikt in uw Azure DocumentDB-database. Met retentie kunt u onnodig opslaggebruik voorkomen. Bewaak het opslaggebruik door waarschuwingen in te stellen voor de metrische gegevens 'Opslagpercentage' en/of 'Gebruikte opslag' met de aggregatie Max. Overweeg om de opslag te vergroten naarmate uw workloadgrootte 70% gebruik overschrijdt.
- Horizontaal schalen: Overweeg om meerdere shards voor uw cluster te gebruiken om uw gegevens over meerdere Azure DocumentDB-knooppunten te verdelen voor betere prestaties en beter capaciteitsbeheer naarmate uw workload groeit. Deze schaalaanpassing is vooral handig voor grote gegevenssets (meer dan 2-4 TiB) en toepassingen met hoge doorvoer.
-
Verticaal schalen: schaalt rekenkracht/RAM omhoog en omlaag en schaal de opslag omhoog.
Testen en herhalen
- Benchmarking: Voer metingen uit voor de meest gebruikte query's met verschillende configuraties om het effect op prestaties te bepalen. Cpu/RAM en IOPS-metrische gegevens en benchmarking op toepassingsniveau gebruiken.
- Belastingstests: voer belastingtests uit om productieworkloads te simuleren en de prestaties van uw gekozen configuratie te valideren.
- Continue bewaking: bewaak uw Azure DocumentDB-implementatie continu en pas de resources indien nodig aan op basis van veranderende workloads en gebruikspatronen.
Door deze factoren systematisch te evalueren en uw configuratie continu te bewaken en aan te passen, kunt u ervoor zorgen dat uw MongoDB-implementatie goed is geoptimaliseerd voor uw specifieke workload.
Overwegingen voor opslag
Het bepalen van de juiste opslaggrootte voor uw workload omvat verschillende overwegingen om optimale prestaties en schaalbaarheid te garanderen. Hier volgen overwegingen voor de opslaggrootte in Azure DocumentDB:
Gegevensgrootte schatten:
- Bereken de verwachte grootte van uw Azure DocumentDB-gegevens. Overwegen:
- Huidige gegevensgrootte: Als u migreert vanuit een bestaande database.
- Groei: Schat hoeveel gegevens er in de loop van de tijd worden toegevoegd.
- Documentgrootte en -structuur: Inzicht in uw gegevensschema en documentgrootten, omdat deze van invloed zijn op de opslagefficiëntie.
- Bereken de verwachte grootte van uw Azure DocumentDB-gegevens. Overwegen:
Factor in indexen:
- Azure DocumentDB maakt gebruik van indexen voor efficiënte query's. Indexen verbruiken extra schijfruimte.
- Maak een schatting van de grootte van indexen op basis van:
- Aantal indexen.
- Grootte van geïndexeerde velden.
Prestatieoverwegingen:
- Schijfprestaties zijn van invloed op databasebewerkingen, met name voor werkbelastingen die niet in het RAM-geheugen passen. Overwegen:
- I/O-doorvoer: IOPS, of invoer-/uitvoerbewerkingen per seconde, is het aantal aanvragen dat in één seconde naar opslagschijven wordt verzonden. De grotere opslagruimte wordt geleverd met meer IOPS. Zorg voor voldoende doorvoer voor lees-/schrijfbewerkingen. Gebruik de metrische waarde 'IOPS' met 'Max' aggregatie om de ingezette IOPS in uw cluster te monitoren.
- Wachttijd: Latentie is de tijd die een toepassing nodig heeft om één aanvraag te ontvangen, naar opslagschijven te verzenden en het antwoord naar de client te verzenden. Latentie is een kritieke meting van de prestaties van een toepassing, naast IOPS en doorvoer. Het type opslag dat wordt gebruikt en de opslagconfiguratie definieert grotendeels latentie. In een beheerde service, zoals Azure DocumentDB, wordt de snelle opslag, zoals Premium SSD-schijven, gebruikt met instellingen die zijn geoptimaliseerd om de latentie te verminderen.
- Schijfprestaties zijn van invloed op databasebewerkingen, met name voor werkbelastingen die niet in het RAM-geheugen passen. Overwegen:
Toekomstige groei en schaalbaarheid:
- Plannen voor toekomstige behoeften voor gegevensgroei en schaalbaarheid.
- Wijs meer schijfruimte toe dan de huidige behoeften om groei mogelijk te maken zonder frequente opslaguitbreidingen.
Voorbeeldberekening:
- Stel dat de initiële gegevensgrootte 500 GiB is.
- Met indexen kan het groeien tot 700 GiB.
- Als u verwacht dat de gegevens in twee jaar worden verdubbeld, plan dan 1,4 TiB (700 GiB * 2).
- Voeg een buffer toe voor overhead-, groei- en operationele behoeften.
- Misschien wilt u vandaag beginnen met 1 TiB-opslag en deze opschalen naar 2 TiB zodra de grootte groter is dan 800 GiB.
Het bepalen van de opslaggrootte omvat een combinatie van het schatten van de huidige en toekomstige gegevensbehoeften, het overwegen van indexering en compressie en het waarborgen van adequate prestaties en schaalbaarheid. Regelmatige bewaking en aanpassing op basis van werkelijke gebruiks- en groeitrends zijn ook van cruciaal belang voor het handhaven van optimale MongoDB-prestaties.
Wat is burstbare rekencapaciteit?
De **Burstable tier** biedt een intelligente oplossing die is afgestemd op kleine databaseworkloads. Door minimale CPU-prestaties te bieden tijdens niet-actieve perioden, optimaliseren deze clusters het resourcegebruik. De echte briljantheid ligt echter in hun vermogen om naadloos op te schalen naar volledig beschikbare CPU-vermogen als reactie op toegenomen verkeers- of werklastbehoeften. Deze aanpassingsvermogen biedt piekprestaties precies wanneer dat nodig is, en levert aanzienlijke kostenbesparingen op.
Door het eerste prijspunt van de service te verminderen, is de Burstable Cluster-laag van Azure DocumentDB gericht op het faciliteren van onboarding en verkenning van Azure DocumentDB tegen lagere prijzen. Dankzij deze democratisering van toegang kunnen bedrijven van alle grootten de kracht van Azure DocumentDB benutten zonder grote kosten te maken. Of u nu een startup, een klein bedrijf of een onderneming bent, deze laag biedt nieuwe mogelijkheden voor rendabele schaalbaarheid.
Het inrichten van een burstable laag is net zo eenvoudig als het inrichten van reguliere lagen; U hoeft alleen 'M10', 'M20' of 'M25' te kiezen in de clusterlaagoptie. Hier volgt een beknopte handleiding met stapsgewijze instructies voor het instellen van een Azure DocumentDB-cluster .