Schaalbaarheid in Azure Cosmos DB voor MongoDB (vCore)

De vCore-service voor Azure Cosmos DB voor MongoDB biedt de mogelijkheid om clusters zowel verticaal als horizontaal te schalen. Hoewel de rekenclusterlaag en opslagschijf functioneel afhankelijk zijn van elkaar, worden de schaalbaarheid en kosten van rekenkracht en opslag losgekoppeld.

Verticale schaalaanpassing

Verticale schaalaanpassing biedt de volgende voordelen:

• Toepassingsteams hebben mogelijk niet altijd een duidelijk pad om hun gegevens logisch te sharden. Bovendien wordt logische sharding per verzameling gedefinieerd. In een gegevensset met verschillende niet-geharde verzamelingen kan gegevensmodellering om de gegevens te partitioneren snel tijdrovend worden. Door het cluster op te schalen kan de noodzaak van logische sharding worden omzeild terwijl u voldoet aan de groeiende opslag- en rekenbehoeften van de toepassing.
• Verticaal schalen vereist geen herverdeling van gegevens. Het aantal fysieke shards blijft hetzelfde en alleen de capaciteit van het cluster wordt verhoogd zonder dat dit van invloed is op de toepassing.
• Omhoog en omlaag schalen zijn geen downtime-bewerkingen zonder onderbrekingen van de service. Er zijn geen toepassingswijzigingen nodig en bewerkingen met een stabiele status kunnen ongestoord worden voortgezet.
• Rekenresources kunnen ook omlaag worden geschaald tijdens bekende tijdvensters met lage activiteit. Als u weer omlaag schaalt, hoeft u geen gegevens opnieuw te verdelen over minder fysieke shards en is dit een nultijdbewerking zonder onderbreking van de service. Ook hier zijn er geen toepassingswijzigingen nodig na het omlaag schalen van het cluster.
• Het belangrijkste is dat rekenkracht en opslag onafhankelijk van elkaar kunnen worden geschaald. Als er meer kernen en geheugen nodig zijn, kan de schijfgrootte ongewijzigd blijven en kan de clusterlaag omhoog worden geschaald. Als er meer opslag en IOPS nodig zijn, kan de clusterlaag ongewijzigd blijven en kan de opslaggrootte onafhankelijk worden opgeschaald. Indien nodig kunnen zowel berekeningen als opslag onafhankelijk worden geschaald om te optimaliseren voor de vereisten van elk onderdeel afzonderlijk, zonder dat de elasticiteitsvereisten van beide onderdelen van invloed zijn op de andere.

Horizontale schaalaanpassing

Uiteindelijk groeit de toepassing tot een punt waar verticaal schalen niet voldoende is. Workloadvereisten kunnen groter worden dan de capaciteit van de grootste clusterlaag en uiteindelijk zijn er meer shards nodig. Horizontaal schalen in de vCore-aanbieding voor Azure Cosmos DB voor MongoDB biedt de volgende voordelen:

• Logisch verdeelde datasets vereisen geen tussenkomst van de gebruiker om de gegevens te verdelen over de onderliggende fysieke shards. De service wijst logische shards automatisch toe aan fysieke shards. Wanneer knooppunten worden toegevoegd of verwijderd, worden gegevens automatisch opnieuw in balans gebracht in de database onder de dekkingen.
• Aanvragen worden automatisch doorgestuurd naar de relevante fysieke shard die eigenaar is van het hash-bereik voor de gegevens die worden opgevraagd.
• Geografisch gedistribueerde clusters hebben een homogene configuratie met meerdere knooppunten. Logische naar fysieke shardtoewijzingen zijn dus consistent in de primaire en replicaregio's van een cluster.

Schalen van rekenkracht en opslag

Reken- en geheugenresources beïnvloeden leesbewerkingen in de vCore-service voor Azure Cosmos DB voor MongoDB meer dan schijf-IOPS.

• Leesbewerkingen raadplegen eerst de cache in de rekenlaag en vallen terug op de schijf wanneer gegevens niet uit de cache kunnen worden opgehaald. Voor workloads met een hogere leessnelheid per seconde leidt het omhoog schalen van de clusterlaag om meer CPU- en geheugenresources te krijgen, tot hogere doorvoer.
• Naast leesdoorvoer profiteren workloads met een groot aantal gegevens per leesbewerking ook van het schalen van de rekenresources van het cluster. Clusterlagen met meer geheugen maken bijvoorbeeld grotere nettoladingen per document en een groter aantal kleinere documenten per antwoord mogelijk.

Schijf-IOPS beïnvloedt schrijfbewerkingen in de vCore-service voor Azure Cosmos DB voor MongoDB meer dan de CPU- en geheugencapaciteit van de rekenresources.

• Schrijfbewerkingen behouden altijd gegevens op schijf (naast persistente gegevens in het geheugen om leesbewerkingen te optimaliseren). Grotere schijven met meer IOPS bieden een hogere schrijfdoorvoer, met name wanneer ze op schaal worden uitgevoerd.
• De service ondersteunt maximaal 32 TB-schijven per shard, met meer IOPS per shard om schrijfintensieve werkbelastingen te ondersteunen, met name wanneer deze op grote schaal wordt uitgevoerd.

Zware werkbelastingen en grote schijven opslaan

Geen minimale opslagvereisten per clusterlaag

Zoals eerder vermeld, worden opslag- en computing-resources losgekoppeld voor facturering en inrichting. Hoewel ze functioneren als een samenhangende eenheid, kunnen ze onafhankelijk worden geschaald. De M30-clusterlaag kan 32 TB-schijven geconfigureerd hebben. Op dezelfde manier kan de M200-clusterlaag 32 GB-schijven hebben ingesteld om te optimaliseren voor zowel opslag- als computekosten.

Lagere TCO met grote schijven (32 TB en hoger)

NoSQL-databases met een vCore-model beperken doorgaans de opslag per fysieke shard tot 4 TB. De vCore-service voor Azure Cosmos DB voor MongoDB biedt maximaal 8x die capaciteit met 32 TB-schijven. Voor zware workloads voor opslag vereist een opslagcapaciteit van 4 TB per fysieke shard een enorme vloot rekenresources om de opslagvereisten van de workload te ondersteunen. Rekenkracht is duurder dan opslag en overprovisionering van rekenkracht vanwege capaciteitslimieten in een service kan de kosten snel doen oplazen.

Laten we eens kijken naar een zware werkbelasting voor opslag met 200 TB aan gegevens.

De vermindering van de rekenvereisten vermindert sterk met grotere schijven. Hoewel er meer dan het minimale aantal fysieke shards nodig is om aan de doorvoervereisten van de werkbelasting te voldoen, is zelfs het verdubbelen of verdrievoudigen van het aantal shards kostenefficiënter dan een cluster van 50 shards met kleinere schijven.

Grote schijven gebruiken om opslaglagen over te slaan

Een onmiddellijke reactie op de rekenkosten in zware scenario's voor opslag is het 'tieren' van de gegevens. Gegevens in de transactionele database zijn beperkt tot de meest gebruikte 'dynamische' gegevens, terwijl het grotere volume 'koude' gegevens wordt losgekoppeld van een koude opslag. Dit veroorzaakt operationele complexiteit. Prestaties zijn ook onvoorspelbaar en afhankelijk van de gegevenslaag die wordt geopend. Bovendien is de beschikbaarheid van het hele systeem afhankelijk van de tolerantie van zowel de dynamische als koude gegevensarchieven gecombineerd. Bij grote schijven in de vCore-service is er geen behoefte aan gelaagde opslag, omdat de kosten van zware werkbelastingen voor opslag worden geminimaliseerd.

Volgende stappen

• Meer informatie over het schalen van Azure Cosmos DB voor MongoDB vCore-cluster
• Best practices voor indexering bekijken