Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure DocumentDB prend en charge le partitionnement pour distribuer horizontalement les données et le trafic. Les documents d’une collection sont divisés en blocs appelés partitions logiques.
Le partitionnement est défini individuellement pour chaque collection à l’aide d’une clé de partition désignée de la structure de documents de la collection. Les données sont ensuite compartimentées en blocs avec chaque bloc correspondant à une partition logique. Les documents pour chaque valeur unique de la clé de fragment se trouvent dans le même fragment logique.
Pour chaque document inséré dans une collection partitionnée, la valeur de la propriété de clé de partition est hachée pour calculer la partition logique désignée. Le placement des fragments logiques et leur distribution au sein du cluster sont extraits de l'utilisateur et entièrement gérés par le service.
Partitions logiques
Tous les documents contenant la même valeur pour la clé de partition appartiennent à la même partition logique.
Prenons par exemple une collection appelée Employees avec la structure de document ci-dessous.
Ce tableau montre un mappage des valeurs de clé de partition à des partitions logiques.
| ID du document | Valeur de clé de partition | Fragment logique |
|---|---|---|
| "12345" | « Steve Smith » | Shard 1 |
| "23456" | « Jane Doe » | Partition 2 |
| "34567" | « Steve Smith » | Partition 1 |
| "45678" | « Michael Smith » | Shard 3 |
| "56789" | « Jane Doe » | Shard 2 |
Il n’y a aucune limite au nombre de shards logiques d’une collection. Une collection peut avoir autant de fragments logiques que de documents avec une valeur unique pour la clé de fragment dans chaque document.
Il n’existe également aucune limite à la taille d’une partition logique unique.
En outre, le service ne limite pas les transactions à l’étendue d’une partition logique. Azure DocumentDB prend en charge les transactions de lecture et d’écriture applicables sur plusieurs partitions logiques et sur plusieurs partitions physiques dans le cluster.
Partitions physiques
Les partitions physiques sont les machines et disques sous-jacents responsables de la persistance des données et de la réalisation des transactions de base de données. Contrairement aux partitions logiques, le service gère les partitions physiques en arrière-plan.
Le nombre de partitions physiques est défini lorsqu’un cluster est créé et peut être augmenté si la taille de la base de données augmente au fil du temps. Les clusters de partitions uniques ont une partition physique (nœud) entièrement responsable des transactions de stockage et de base de données du cluster. Les clusters à plusieurs partitions distribuent les données et le volume de transactions entre les partitions physiques du cluster.
Mappage de partitions logiques à des partitions physiques
Lorsque de nouvelles partitions logiques sont ajoutées, le cluster met à jour en toute transparence le mappage des partitions logiques aux partitions physiques. De même, l’affectation de l’espace d’adressage à chaque partition physique est modifiée, car de nouvelles partitions physiques sont ajoutées au cluster après quoi, les partitions logiques sont rééquilibrées sur le cluster.
La plage de hachage utilisée pour mapper des partitions logiques et physiques est répartie uniformément entre les partitions physiques du cluster. Chaque partition physique possède un compartiment de taille égale de la plage de hachage. Pour chaque document écrit, la valeur de la propriété de clé de partition est hachée et la valeur de hachage détermine le mappage du document à la partition physique sous-jacente. En interne, plusieurs partitions logiques sont mappées à une seule partition physique. De plus, les partitions logiques ne sont jamais fractionnées entre les partitions physiques, et tous les documents d’une partition logique sont mappés uniquement à une seule partition physique.
En se basant sur l’exemple précédent utilisant un cluster avec deux partitions physiques, ce tableau montre un exemple de mappage de documents à des partitions physiques.
| ID du document | Valeur de clé de partition | Partition logique | Partition physique |
|---|---|---|---|
| "12345" | « Steve Smith » | Partition 1 | Partition physique 1 |
| "23456" | « Jane Doe » | Shard 2 | Partition physique 2 |
| "34567" | « Steve Smith » | Partition 1 | Partition physique 1 |
| "45678" | « Michael Smith » | Shard 3 | Partition physique 1 |
| "56789" | « Jane Doe » | Shard 2 | Partition physique 2 |
Capacité des partitions physiques
Le niveau de cluster sélectionné lorsque le cluster est approvisionné détermine la capacité processeur et mémoire d’une partition physique. De même, la référence SKU de stockage détermine la capacité de stockage et d’IOPS d’une partition physique. Les niveaux de cluster plus volumineux fournissent davantage de puissance de calcul et de mémoire plus grande, tandis que les disques de stockage plus volumineux fournissent davantage de stockage et d’E/S par seconde. Les charges de travail lourdes en lecture bénéficient d'un niveau de cluster plus grand, tandis que les charges de travail lourdes en écriture bénéficient d'un SKU de stockage plus important. Le niveau de cluster peut évoluer après la création du cluster, selon l'évolution des besoins de l'application.
Dans un cluster multishard, la capacité de chaque partition physique est la même. Augmenter le niveau du cluster ou le SKU du stockage n'affecte pas le positionnement des partitions logiques sur les partitions physiques. Après une opération de montée en puissance, le nombre de partitions physiques reste le même, ce qui évite de devoir rééquilibrer les données dans le cluster.
La capacité de calcul, de mémoire, de stockage et d’E/S par seconde de la partition physique détermine les ressources disponibles pour les partitions logiques. Les clés de fragmentation qui n'ont pas une distribution uniforme des volumes de stockage et de requêtes peuvent entraîner une consommation inégale de stockage et de débit au sein du cluster. Les partitions à chaud peuvent conduire à une utilisation inégale des fragments physiques, entraînant ainsi des débits et des performances imprévisibles. Par conséquent, les clusters partitionnés nécessitent une planification minutieuse pour garantir que les performances restent cohérentes à mesure que les exigences de l’application changent au fil du temps.
Ensembles de répliques
Chaque partition physique se compose d’un ensemble de réplicas, également appelé jeu de réplicas. Chaque réplica héberge une instance du moteur de base de données. Avec un jeu de réplicas, le stockage des données dans la partition physique est durable, hautement disponible et constant. Chaque réplica qui compose la partition physique hérite du stockage et de la capacité de calcul de la partition physique. Azure DocumentDB gère automatiquement les ensembles de réplicas.
Meilleures pratiques pour le partitionnement des données
Le partitionnement dans Azure DocumentDB n’est pas nécessaire, sauf si le stockage et les volumes de transactions de la collection peuvent dépasser la capacité d’une partition physique unique. Par exemple, le service fournit 32 To de disques par partition. Si une collection nécessite plus de 32 To, elle doit être shardée.
Il n’est pas nécessaire de fragmenter chaque collection d’un cluster en plusieurs fragments physiques. Les collections partitionnées et non partitionnées peuvent coexister dans le même cluster. Le service distribue de façon optimale les regroupements au sein du cluster pour utiliser uniformément les ressources de calcul et de stockage du cluster aussi uniformément que possible.
Pour les applications lourdes en lecture, la clé de partition doit être sélectionnée en fonction des modèles de requête les plus fréquents. Le filtre de requête le plus couramment utilisé pour une collection doit être choisi comme clé de partition pour optimiser le pourcentage le plus élevé de transactions de base de données en localisant la recherche sur une seule partition physique.
Pour les applications lourdes d’écriture qui favorisent les performances d’écriture par rapport aux lectures, une clé de shard doit être choisie pour répartir uniformément les données entre les shards physiques. Les clés de partition avec la cardinalité la plus élevée constituent la meilleure option pour distribuer aussi uniformément que possible.
Pour des performances optimales, la taille de stockage d’une partition logique doit être inférieure à 4 To.
Pour des performances optimales, les partitions logiques doivent être distribuées uniformément dans le stockage et le volume de requêtes sur les partitions physiques du cluster.
Comment partitionner une collection
Considérez le document suivant dans la base de données « cosmosworks » et la collection « employee »
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
L’exemple suivant partitionne la collection Employees dans la base de données cosmicworks sur la propriété firstName.
use cosmicworks;
sh.shardCollection("cosmicworks.employee", {"firstName": "hashed"})
La collection peut également être partitionnée à l’aide d’une commande d’administrateur :
use cosmicworks;
db.adminCommand({
"shardCollection": "cosmicworks.employee",
"key": {"firstName": "hashed"}
})
Bien qu’il n’est pas idéal de modifier la clé de partition après que la collection a augmenté considérablement dans le volume de stockage, la commande reshardCollection peut être utilisée pour modifier la clé de partition.
use cosmicworks;
sh.reshardCollection("cosmicworks.employee", {"lastName": "hashed"})
La collection peut également être partitionnée à l’aide d’une commande d’administrateur :
use cosmicworks;
db.adminCommand({
"reshardCollection": "cosmicworks.employee",
"key": {"lastName": "hashed"}
})
En guise de bonne pratique, un index doit être créé sur la propriété de clé de partition.
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"firstName":1}, "name":"firstName_1", "enableLargeIndexKeys": true}],
blocking: true
})