Sharding voor horizontale schaalbaarheid in Azure DocumentDB

Azure DocumentDB biedt ondersteuning voor 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 collectie met behulp van een specifieke shard-sleutel uit de documentstructuur van de collectie. Gegevens worden vervolgens in segmenten geplaatst met elk segment dat overeenkomt met een logische partitie. Documenten voor elke unieke waarde van de shard-sleuteleigenschap 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 verantwoordelijkheid voor het plaatsen van de logische shard en het distribueren van alle logische shards in het cluster wordt onttrokken aan de gebruiker en volledig beheerd door de service.

Logische fragmenten

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 koppeling van shard-sleutelwaarden aan logische partities.

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

• 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. Azure DocumentDB ondersteunt lees- en schrijftransacties die van toepassing zijn op meerdere logische shards en op meerdere fysieke shards in het cluster.

Fysieke fragmenten

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 koppelen aan fysieke shards

Wanneer er nieuwe logische shards worden toegevoegd, werkt het cluster naadloos de toewijzing van logische naar fysieke shards bij. 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 in kaart te brengen, is 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 eigenschap van de shard sleutel gehasht en bepaalt de hashwaarde de toewijzing van het document aan de onderliggende fysieke shard. Intern worden verschillende logische shards samengevoegd tot éé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.

Voortbouwend op het vorige voorbeeld van een cluster met twee fysieke shards, toont deze tabel een voorbeeldtoewijzing van documenten aan fysieke shards.

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 vervalt.

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 oneven 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. Met Azure DocumentDB worden replicasets automatisch beheerd.

Aanbevolen procedures voor het sharden van gegevens

• Sharding in Azure DocumentDB 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 dat meerdere fysieke shards heeft te particioneren. Shard-verzamelingen en ongesharde 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 toepassingen met veel leesverkeer moet de shard-sleutel worden geselecteerd op basis van de meest voorkomende querypatronen. Het meest gebruikte queryfilter voor een verzameling moet worden gekozen als de shardsleutel om het grootste deel van de databasetransacties te optimaliseren door de zoekopdracht te beperken tot éé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 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 in stukken delen

Bekijk het volgende document in de 'cosmicworks'-database en de 'employee'-collectie.

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

In het volgende voorbeeld wordt de werknemersverzameling in de cosmicworks-database geshard op de eigenschap "firstName".

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

De verzameling kan ook worden geshard 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 verzameling aanzienlijk in opslagvolume is gegroeid, kan de opdracht reshardCollection worden gebruikt 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 een Azure DocumentDB-cluster
• Best practices voor indexering bekijken