Sharding voor horizontale schaalbaarheid in Azure Cosmos DB voor MongoDB vCore

Azure Cosmos DB voor MongoDB vCore ondersteunt sharding om gegevens en verkeer horizontaal te distribueren. De documenten in een verzameling zijn onderverdeeld in segmenten die logische shards worden genoemd.

Sharding wordt afzonderlijk gedefinieerd voor elke verzameling met behulp van een toegewezen shardsleutel uit de documentstructuur van de verzameling. Gegevens worden vervolgens in segmenten geplaatst met elk segment dat overeenkomt met een logische partitie. Documenten voor elke unieke waarde van de eigenschap shardsleutel bevinden zich in dezelfde logische shard.

Voor elk document dat is ingevoegd in een shard-verzameling, wordt de waarde van de eigenschap shardsleutel gehasht om de toegewezen logische shard te berekenen. De onus van het plaatsen van de logische shard en het distribueren van alle logische shards in het cluster worden geabstraheerd van de gebruiker en volledig beheerd door de service.

Logische shards

Alle documenten met dezelfde waarde voor de shardsleutel behoren tot dezelfde logische shard.

Laten we bijvoorbeeld een verzameling met de naam Werknemers overwegen met de onderstaande documentstructuur.

In deze tabel ziet u een toewijzing van shardsleutelwaarden aan logische partities.

• Er gelden geen limieten voor het aantal logische shards voor een verzameling. Een verzameling kan zoveel logische shards hebben als er documenten zijn, waarbij elk document een unieke waarde heeft voor de eigenschap shard-sleutel.

• Er zijn ook geen limieten voor de grootte van één logische shard.

• Bovendien beperkt de service transacties niet tot het bereik van een logische shard. De vCore-service voor Azure Cosmos DB voor MongoDB ondersteunt lees- en schrijftransacties die van toepassing zijn op meerdere logische shards en op meerdere fysieke shards in het cluster.

Fysieke stukken

Fysieke shards zijn de onderliggende machines en schijven die verantwoordelijk zijn voor het persistent maken van de gegevens en het uitvoeren van databasetransacties. In tegenstelling tot logische shards beheert de service fysieke shards achter de schermen.

Het aantal fysieke shards wordt gedefinieerd wanneer een cluster wordt gemaakt en kan worden verhoogd als de database in de loop van de tijd toeneemt. Enkele shardclusters hebben één fysieke shard (knooppunt) die volledig verantwoordelijk is voor de opslag- en databasetransacties van het cluster. Multishardclusters verdelen de gegevens en het transactievolume over de fysieke shards in het cluster.

Logische shards toewijzen aan fysieke shards

Wanneer er nieuwe logische shards worden toegevoegd, zorgt het cluster ervoor dat de toewijzing van logische naar fysieke shards naadloos wordt bijgewerkt. Op dezelfde manier wordt de toewijzing van de adresruimte aan elke fysieke shard gewijzigd omdat nieuwe fysieke shards worden toegevoegd aan het cluster, waarna logische shards opnieuw worden verdeeld over het cluster.

Het hashbereik dat wordt gebruikt om logische en fysieke shards toe te wijzen, wordt gelijkmatig verdeeld over de fysieke shards in het cluster. Elke fysieke shard is eigenaar van een bucket met een gelijkmatig formaat van het hash-bereik. Voor elk document dat is geschreven, wordt de waarde van de shardsleuteleigenschap gehasht en de hashwaarde bepaalt hoe het document wordt toegewezen aan de onderliggende fysieke shard. Intern worden verschillende logische shards gekoppeld aan één fysieke shard. Bovendien worden logische shards nooit verdeeld over fysieke shards en alle documenten voor een logische shard worden alleen toegewezen aan één fysieke shard.

Gebaseerd op het vorige voorbeeld, waarin gebruik wordt gemaakt van een cluster met twee fysieke schijven, toont deze tabel een voorbeeld van hoe documenten aan fysieke schijven zijn toegewezen.

Capaciteit van fysieke shards

De clusterlaag die wordt geselecteerd wanneer het cluster wordt ingericht, bepaalt de CPU- en geheugencapaciteit van een fysieke shard. Op dezelfde manier bepaalt de opslag-SKU de opslag- en IOPS-capaciteit van een fysieke shard. Grotere clusterlagen bieden meer rekenkracht en groter geheugen, terwijl grotere opslagschijven meer opslag en IOPS bieden. Leesintensieve workloads profiteren van een grotere clusterlaag, terwijl schrijfintensieve workloads profiteren van een grotere opslag-SKU. De clusterlaag kan omhoog en omlaag worden geschaald nadat het cluster is gemaakt op basis van de veranderende behoeften van de toepassing.

In een multishardcluster is de capaciteit van elke fysieke shard hetzelfde. Het omhoog schalen van de clusterlaag of de opslag-SKU wijzigt de plaatsing van logische shards op de fysieke shards niet. Na een opschaalbewerking blijft het aantal fysieke shards hetzelfde, waardoor de noodzaak om de gegevens in het cluster opnieuw te verdelen wordt vermeden.

De reken-, geheugen-, opslag- en IOPS-capaciteit van de fysieke shard bepalen welke resources beschikbaar zijn voor de logische shards. Shardsleutels die geen gelijkmatige distributie van opslag- en aanvraagvolumes hebben, kunnen leiden tot ongelijk opslag- en doorvoerverbruik binnen het cluster. Hete partities kunnen ervoor zorgen dat fysieke shards ongelijkmatig worden gebruikt, wat leidt tot onvoorspelbare doorvoer en prestaties. Shard-clusters vereisen dus zorgvuldige planning vooraf om ervoor te zorgen dat de prestaties consistent blijven wanneer de vereisten van de toepassing na verloop van tijd veranderen.

Replicasets

Elke fysieke shard bestaat uit een set replica's, ook wel een replicaset genoemd. Elke replica fungeert als host voor een exemplaar van de database-engine. Een replicaset maakt het gegevensarchief in de fysieke shard duurzaam, maximaal beschikbaar en consistent. Elke replica waaruit de fysieke shard bestaat, neemt de opslag- en rekencapaciteit van de fysieke shard over. Azure Cosmos DB voor MongoDB vCore beheert automatisch replicasets.

Aanbevolen procedures voor het sharden van gegevens

• Sharding in Azure Cosmos DB voor MongoDB vCore is niet vereist, tenzij de opslag- en transactievolumes van de verzameling de capaciteit van één fysieke shard kunnen overschrijden. De service biedt bijvoorbeeld 32 TB schijven per shard. Als voor een verzameling meer dan 32 TB is vereist, moet deze worden geshard.

• Het is niet nodig om elke verzameling in een cluster met meerdere fysieke shards te sharden. Shard-verzamelingen en niet-geharde verzamelingen kunnen naast elkaar bestaan in hetzelfde cluster. De service distribueert de verzamelingen binnen het cluster optimaal om de reken- en opslagresources van het cluster zo gelijkmatig mogelijk te gebruiken.

• Voor leesintensieve toepassingen moet de shardsleutel worden geselecteerd op basis van de meest voorkomende querypatronen. Het meest gebruikte queryfilter voor een verzameling moet worden gekozen als de shardsleutel om het hoogste percentage databasetransacties te optimaliseren door de zoekopdracht te lokaliseren naar één fysieke shard.

• Voor schrijfintensieve toepassingen die de voorkeur geven aan schrijfprestaties ten opzichte van leesbewerkingen, moet een shardsleutel worden gekozen om gegevens gelijkmatig over de fysieke shards te verdelen. Shardsleutels met de hoogste kardinaliteit bieden de beste mogelijkheid om zo gelijkmatig mogelijk gelijkmatig te verdelen.

• Voor optimale prestaties moet de opslaggrootte van een logische shard kleiner zijn dan 4 TB.

• Voor optimale prestaties moeten logische shards gelijkmatig worden gedistribueerd in opslag en aanvraagvolume over de fysieke shards van het cluster.

Een verzameling sharden

Bekijk het volgende document in de database 'kosmische werken' en 'werknemer'-verzameling

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

In de volgende voorbeeldshards wordt de werknemersverzameling in de kosmische database op de eigenschap firstName weergegeven.

use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})

De verzameling kan ook worden sharded met behulp van een beheeropdracht:

use cosmicworks;
db.adminCommand({
  "shardCollection": "cosmicworks.employee",
  "key": {"firstName": "hashed"}
})

Hoewel het niet ideaal is om de shardsleutel te wijzigen nadat de collectie aanzienlijk in opslagvolume is gegroeid, kan je de opdracht reshardCollection gebruiken om de shardsleutel te wijzigen.

use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})

De verzameling kan ook opnieuw worden gehard met behulp van een beheeropdracht:

use cosmicworks;
db.adminCommand({
  "reshardCollection": "cosmicworks.employee",
  "key": {"lastName": "hashed"}
})

Als best practice moet er een index worden gemaakt op de eigenschap shardsleutel.

use cosmicworks;
db.runCommand({
  createIndexes: "employee",
  indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
  blocking: true
})

Volgende stappen

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