Recommandations pour le partitionnement des données

Article
11/15/2023

S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :

RE :06	Implémentez une stratégie de mise à l’échelle rapide et fiable au niveau de l’application, des données et de l’infrastructure.

Guide connexe : Mise à l’échelle

Ce guide décrit les recommandations relatives à la conception d’une stratégie de partitionnement des données pour la technologie de stockage de données et de base de données que vous déployez. Cette stratégie vous aide à améliorer la fiabilité de votre patrimoine de données.

Stratégies de conception

Dans de nombreuses solutions à grande échelle, les partitions sont utilisées pour diviser les données afin qu’elles puissent être gérées et accessibles séparément. Le partitionnement des données améliore l’extensibilité, réduit la contention et optimise les performances. Implémentez le partitionnement des données pour diviser les données par modèle d’utilisation. Par exemple, vous pouvez archiver des données plus anciennes dans un stockage de données peu coûteux. Choisissez soigneusement votre stratégie de partitionnement pour optimiser les avantages et réduire les effets indésirables.

Remarque

Dans cet article, le terme partitionnement désigne le processus de division physique des données sous forme de magasins de données distincts. Il diffère du partitionnement de tables SQL Server.

Vous pouvez partitionner des données pour :

Améliorer l’évolutivité. Lorsque vous effectuez un scale-up d’un système de base de données unique, la base de données atteint finalement une limite matérielle physique. Si vous divisez les données entre plusieurs partitions, avec chaque partition hébergée sur un serveur distinct, vous pouvez effectuer un scale-out du système presque indéfiniment.
Améliorez les performances. Dans chaque partition, les opérations d’accès aux données sont effectuées sur un plus petit volume de données par rapport aux données qui ne sont pas partitionnés. Partitionnez les données pour rendre votre système plus efficace. Les opérations qui affectent plusieurs partitions peuvent s’exécuter en parallèle.
Améliorer la sécurité. Dans certains cas, vous pouvez séparer les données sensibles et non sensibles dans différentes partitions et appliquer différents contrôles de sécurité aux données sensibles.
Procurer une flexibilité opérationnelle. Vous pouvez partitionner des données pour affiner les opérations, optimiser l’efficacité administrative et réduire les coûts. Par exemple, vous pouvez définir des stratégies de gestion, de surveillance, de sauvegarde et de restauration, et d’autres tâches administratives en fonction de l’importance des données dans chaque partition.
Faire correspondre le magasin de données au modèle d’utilisation. Vous pouvez déployer chaque partition sur un autre type de magasin de données en fonction du coût et des fonctionnalités intégrées proposées par le magasin de données. Par exemple, vous pouvez stocker des données binaires volumineuses dans le stockage d’objets blob et stocker des données structurées dans une base de données de documents. Pour plus d’informations, consultez Comprendre les modèles de magasin de données.
Améliorer la disponibilité. Pour éviter un point de défaillance unique, vous pouvez séparer les données entre plusieurs serveurs. Lorsqu’une instance échoue, seules les données de cette partition sont indisponibles. Les opérations continuent dans d’autres partitions. Cette considération est moins pertinente pour les magasins de données PaaS (Managed Platform as a Service), car ils ont une redondance intégrée.

Sélectionner la stratégie de partitionnement appropriée

Il existe trois stratégies fréquentes de partitionnement des données :

Partitionnement horizontal (souvent appelé sharding). Dans cette stratégie, chaque partition est un magasin de données distinct, mais toutes les partitions ont le même schéma. Chaque partition est appelée partition et contient un sous-ensemble des données, comme un ensemble de commandes client.
Partitionnement vertical. Dans cette stratégie, chaque partition comporte une partie des champs des éléments présents dans le magasin de données. Les champs sont divisés selon leur modèle d’utilisation. Par exemple, les champs fréquemment utilisés peuvent être placés dans une partition verticale et les champs moins fréquemment utilisés dans une autre.
Partitionnement fonctionnel. Dans cette stratégie, les données sont agrégées en fonction de la façon dont chaque contexte délimité dans le système utilise les données. Par exemple, un système d’e-commerce pourrait stocker les données de facturation dans une partition et les données relatives à l’inventaire des produits dans une autre.

Envisagez de combiner ces stratégies lorsque vous concevez un schéma de partitionnement. Vous pouvez, par exemple, diviser les données en partitions, puis utiliser le partitionnement vertical pour ensuite sous-diviser les données au sein de chaque partition.

Partitionnement horizontal (sharding)

L’image suivante montre un exemple de partitionnement horizontal ou de partitionnement. Cet exemple divise les données d’inventaire des produits en partitions basées sur la clé de produit. Chaque partition comporte les données relatives à une plage contiguë de clés de partition (A à G et H à Z), classées par ordre alphabétique. Lorsque vous effectuez un partitionnement, il répartit la charge sur plus d’ordinateurs, ce qui réduit la contention et améliore les performances.

Le facteur le plus important est la clé de partitionnement que vous choisissez. Il peut s’avérer difficile de modifier la clé une fois le système est en fonctionnement. La clé doit garantir un partitionnement des données afin de répartir la charge de travail aussi uniformément que possible au sein des partitions.

Les partitions ne doivent pas forcément avoir la même taille. Ce qui compte le plus, c’est d’équilibrer le nombre de requête. Certaines partitions peuvent être volumineuses, mais chaque élément de la partition a un faible nombre d’opérations d’accès. D’autres partitions peuvent être plus petites, mais chaque élément de la partition est plus fréquemment accessible. Il est également important de s’assurer qu’une seule partition ne dépasse pas les limites d’échelle, en termes de capacité et de traitement des ressources, du magasin de données.

Évitez de créer des partitions chaudes qui peuvent affecter les performances et la disponibilité. Par exemple, si vous utilisez la première lettre du nom d’un client, elle peut créer une distribution déséquilibré, car certaines lettres sont plus courantes que d’autres. Utilisez plutôt un hachage d’identificateur client pour distribuer uniformément les données entre les partitions.

Choisissez une clé de partitionnement qui réduit le besoin futur de fractionner de grandes partitions, de combiner de petites partitions en partitions plus grandes ou de modifier le schéma. Ces opérations sont fastidieuses et peuvent nécessiter la mise hors connexion d’une ou de plusieurs partitions.

Si des partitions sont répliquées, vous pouvez conserver certains réplicas en ligne tandis que d’autres sont fractionnés, fusionnés ou reconfigurés. Toutefois, le système peut limiter les opérations qui peuvent être effectuées pendant la reconfiguration. Par exemple, les données des réplicas peuvent être marquées en lecture seule afin d’éviter des incohérences de données.

Pour plus d’informations, consultez Modèle de partitionnement.

Partitionnement vertical

L’utilisation la plus courante pour le partitionnement vertical consiste à réduire les coûts d’E/S et de performances associés à l’extraction d’éléments fréquemment consultés. L’image suivante montre un exemple de partitionnement vertical. Dans cet exemple, les différentes propriétés d’un élément sont stockées dans des partitions différentes. Une partition contient des données accessibles plus fréquemment, notamment le nom du produit, la description et le prix. Une autre partition contient les données d’inventaire, y compris le nombre d’actions et la date de la dernière commande.

Dans cet exemple, l’application interroge régulièrement le nom, la description et le prix du produit lorsqu’elle affiche les détails du produit aux clients. Le nombre d’actions et la date de la dernière commande se trouvent dans une partition distincte, car ces deux éléments sont couramment utilisés ensemble.

Consultez les avantages suivants du partitionnement vertical :

Vous pouvez séparer les données relativement lentes (nom du produit, description et prix) à partir de données plus dynamiques (niveau boursier et date de la dernière commande). Les données à déplacement lent sont un bon candidat pour qu’une application soit mise en cache en mémoire.
Vous pouvez stocker des données sensibles dans une partition distincte avec des contrôles de sécurité ajoutés.
Le partitionnement vertical peut limiter le nombre d’accès simultanés qui est nécessaire.

Le partitionnement vertical fonctionne au niveau de l’entité au sein d’un magasin de données, en normalisant partiellement une entité pour organiser un large élément en un jeu d’éléments restreints. Il convient parfaitement aux magasins de données orientés colonnes, tels que HBase et Cassandra. Si les données d’une collection de colonnes sont peu susceptibles de changer, envisagez d’utiliser des magasins de colonnes dans SQL Server.

Partitionnement fonctionnel

Lorsqu’un contexte limité peut être identifié pour chaque zone métier distincte d’une application, le partitionnement fonctionnel peut améliorer les performances d’isolation et d’accès aux données. Une autre utilisation fréquente du partitionnement fonctionnel consiste à séparer les données en lecture-écriture des données en lecture seule. L’image suivante montre une vue d’ensemble du partitionnement fonctionnel avec des données d’inventaire séparées des données client.

Cette stratégie de partitionnement peut contribuer à réduire la contention d’accès aux données entre les différentes parties d’un système.

Concevoir des partitions pour l’extensibilité

Il est essentiel de prendre en compte la taille et la charge de travail de chaque partition. Équilibrez-les afin que les données soient distribuées pour obtenir une scalabilité maximale. Toutefois, vous devez également partitionner les données afin qu’elles ne dépassent pas les limites de mise à l’échelle d’un magasin de partitions unique.

Suivez ces étapes lorsque vous concevez des partitions pour l’extensibilité :

Analysez l’application pour comprendre les modèles d’accès aux données, tels que la taille du jeu de résultats retourné par chaque requête, la fréquence d’accès, la latence inhérente et les exigences de traitement du calcul côté serveur. Dans de nombreux cas, quelques entités majeures demandent la plupart des ressources de traitement.
Utilisez cette analyse pour déterminer les cibles actuelles et futures de scalabilité, telles que la taille et la charge de travail des données. Répartissez ensuite les données entre les partitions pour satisfaire aux objectifs d’extensibilité. Pour le partitionnement horizontal, choisissez la clé de partition appropriée pour garantir même la distribution. Pour plus d’informations, consultez Modèle de partitionnement.
Assurez-vous que chaque partition dispose de suffisamment de ressources pour gérer les exigences de scalabilité en termes de taille et de débit des données. Selon le magasin de données, il peut y avoir une limite pour chaque partition sur la quantité d’espace de stockage, de puissance de traitement ou de bande passante réseau. Si les exigences sont susceptibles de dépasser ces limites, vous devrez peut-être affiner votre stratégie de partitionnement ou fractionner davantage les données. Vous devrez peut-être combiner deux stratégies ou plus.
Surveillez le système pour vérifier que les données sont réparties comme prévu et que les partitions peuvent gérer la charge. L’utilisation réelle ne correspond pas toujours à ce qu’une analyse prédite. Vous devrez peut-être rééquilibrer les partitions ou redéfinir certaines parties du système pour obtenir l’équilibre requis.

Certains environnements cloud allouent des ressources en fonction des limites de l’infrastructure. Assurez-vous que les limites de votre limite sélectionnée offrent suffisamment de place pour la croissance prévue du volume de données, du stockage des données, de la puissance de traitement et de la bande passante.

Par exemple, si vous utilisez Stockage Table Azure, il existe une limite au volume de requêtes qu’une partition unique peut gérer pendant une période particulière. Pour plus d’informations, consultez Cibles de scalabilité et de performances pour les comptes de stockage standard. Une partition occupée peut demander plus de ressources que celles qui peuvent être gérées par une partition unique. Vous devrez peut-être repartitionner la partition pour répartir la charge. Si la taille ou le débit total de ces tables dépasse la capacité d’un compte de stockage, vous devrez peut-être créer davantage de comptes de stockage et répartir les tables entre ces comptes.

Concevoir des partitions pour les performances des requêtes

Vous pouvez améliorer les performances des requêtes à l’aide de petits jeux de données et exécuter des requêtes parallèles. Chaque partition doit contenir une petite proportion de l’ensemble du jeu de données. Cette réduction de volume peut améliorer la performance des requêtes. Toutefois, le partitionnement n’est pas une alternative à la conception et à la configuration de base de données appropriées. Vérifiez que vous implémentez les index nécessaires.

Suivez ces étapes lorsque vous concevez des partitions pour les performances des requêtes :

Examinez les exigences et les performances de l’application.
- En fonction des exigences opérationnelles, identifiez les requêtes importantes qui doivent toujours être exécutées avec rapidité.
- Surveillez le système pour identifier les requêtes qui s’exécutent lentement.
- Déterminez les requêtes qui s’exécutent le plus fréquemment. Même si une requête unique a un coût minimal, la consommation de ressources cumulatives peut être significative.
Partitionnez les données qui provoquent des performances lentes.
- Limitez la taille de chaque partition afin que le temps de réponse aux requêtes corresponde à l’objectif.
- Si vous utilisez le partitionnement horizontal, concevez la clé de partition afin que l’application puisse facilement sélectionner la partition appropriée. Cette spécification empêche la requête d’analyser chaque partition.
- Tenez compte de l’emplacement d’une partition. Essayez de conserver des données dans des partitions qui sont géographiquement proches des applications et des utilisateurs qui y accèdent.
Si une entité a des exigences en matière de débit et de performances de requête, utilisez le partitionnement fonctionnel basé sur cette entité. Si cette allocation ne répond toujours pas aux exigences, vous pouvez ajouter un partitionnement horizontal. Une stratégie de partitionnement unique est généralement adéquate, mais dans certains cas, il est plus efficace de combiner les deux stratégies.
Exécutez des requêtes en parallèle entre les partitions pour améliorer les performances.

Concevoir des partitions pour la disponibilité

Partitionner des données pour améliorer la disponibilité des applications. Le partitionnement garantit que l’ensemble du jeu de données n’a pas de point de défaillance unique et que vous pouvez gérer indépendamment des sous-ensembles individuels du jeu de données.

Prenez en compte les facteurs affectant la disponibilité suivants :

Déterminez la criticité des données. Identifiez les données métier critiques, telles que les transactions, et les données opérationnelles les moins critiques, telles que les fichiers journaux.

Stockez les données critiques dans des partitions hautement disponibles et créez un plan de sauvegarde approprié.
Établissez des procédures de gestion et de surveillance distinctes pour différents jeux de données.
Placez les données qui ont le même niveau de criticité dans la même partition afin qu’elles puissent être sauvegardées à la même fréquence. Par exemple, vous devrez peut-être sauvegarder des partitions qui contiennent des données de transaction plus souvent que des partitions qui contiennent des informations de journalisation ou de trace.

Gérer des partitions individuelles. Concevoir des partitions pour prendre en charge la gestion et la maintenance indépendantes. Cette pratique offre plusieurs avantages, par exemple :

En cas de défaillance d’une partition, elle peut être récupérée de manière indépendante, sans application accédant aux données présentes dans d’autres partitions.
Le partitionnement des données par zone géographique permet aux tâches de maintenance planifiées de se produire à des heures creuses pour chaque emplacement. Assurez-vous que les partitions ne sont pas si volumineuses qu’elles empêchent la fin de la maintenance planifiée pendant cette période.

Répliquez les données critiques entre les partitions. Cette stratégie améliore la disponibilité et les performances, mais peut également introduire des problèmes de cohérence. La synchronisation des modifications avec chaque réplica prend un certain temps. Pendant la synchronisation, différentes partitions contiennent des valeurs de données différentes.

Optimiser le code d’application pour utiliser des partitions

Le partitionnement complique la conception et le développement du système. Partitionner les données dans le cadre fondamental de la conception de votre système même si le système ne contient initialement qu’une seule partition. Si vous traitez le partitionnement en tant qu’après-temps, il est difficile, car vous disposez déjà d’un système actif à gérer. Vous pouvez :

Vous devez modifier la logique d’accès aux données.
Vous devez migrer de grandes quantités de données existantes pour la distribuer entre les partitions.
Rencontrez des difficultés, car les utilisateurs s’attendent à continuer à utiliser le système pendant la migration.

Dans certains cas, le partitionnement n’est pas important, car le jeu de données initial est petit et un seul serveur peut facilement le gérer. Certaines charges de travail peuvent aller sans partitions, mais de nombreux systèmes commerciaux doivent s’étendre à mesure que le nombre d’utilisateurs augmente.

Certains petits magasins de données bénéficient également du partitionnement. Par exemple, des centaines de clients simultanés peuvent accéder à un petit magasin de données. Si vous partitionnez les données dans cette situation, cela peut aider à réduire la contention et à améliorer le débit.

Au moment de concevoir un schéma de partitionnement de données, tenez compte des points suivants :

Réduisez les opérations d’accès aux données entre partitions. Essayez de conserver des données pour les opérations de base de données les plus courantes dans une partition afin de réduire les opérations d’accès aux données entre partitions. Il peut s’avérer plus fastidieux d’interroger plusieurs partitions plutôt que d’interroger au sein d’une seule partition. Toutefois, l’optimisation des partitions pour un ensemble de requêtes peut affecter négativement d’autres ensembles de requêtes. Si vous avez besoin d’interroger plusieurs partitions, limitez la durée des requêtes en exécutant des requêtes parallèles et en agrégeant les résultats dans l’application. Dans certains cas, vous ne pouvez pas utiliser cette approche, par exemple si le résultat d’une requête est utilisé dans la requête suivante.

Répliquez les données de référence statiques. Si les requêtes utilisent des données de référence relativement statiques, telles que des tables de code postal ou des listes de produits, envisagez de répliquer ces données dans toutes les partitions pour réduire les opérations de recherche distinctes dans différentes partitions. Cette approche peut également réduire la probabilité que les données de référence deviennent un jeu de données chaud avec un trafic lourd entre l’ensemble du système. Il existe des coûts supplémentaires associés à la synchronisation des modifications apportées aux données de référence.

Réduisez les jointures de partitions croisées. Dans la mesure du possible, réduisez les exigences en matière d’intégrité référentielle dans les partitions verticales et fonctionnelles. Dans ces schémas, l’application est en charge du maintien de l’intégrité référentielle dans les partitions. Les requêtes qui joignent des données sur plusieurs partitions sont inefficaces, car l’application effectue généralement des requêtes consécutives basées sur une clé, puis une clé étrangère. Envisagez plutôt de répliquer ou de dénormaliser les données pertinentes. Si vous devez joindre des partitions croisées, exécutez des requêtes parallèles sur les partitions et joignez les données dans l’application.

Adoptez la cohérence éventuelle : Évaluez si une cohérence forte est requise. Une approche courante dans les systèmes distribués consiste à mettre en place une cohérence finale. Les données de chaque partition sont mises à jour séparément et la logique de l’application garantit que les mises à jour se terminent correctement. La logique de l’application gère également les incohérences qui proviennent de l’interrogation des données pendant qu’une opération éventuellement cohérente s’exécute.

Tenez compte de la façon dont les requêtes localisent la partition appropriée. Si une requête doit analyser toutes les partitions pour localiser les données requises, elle affecte considérablement les performances, même quand plusieurs requêtes parallèles s’exécutent. Avec le partitionnement vertical et fonctionnel, les requêtes peuvent spécifier la partition. En revanche, le partitionnement horizontal peut rendre difficile la localisation d’un élément, car chaque partition a le même schéma. Une solution classique consiste à conserver une carte utilisée pour rechercher l’emplacement des partitions des éléments. Implémentez cette carte dans la logique de partitionnement de l’application. Elle peut également être conservée par le magasin de données si le magasin de données prend en charge le partitionnement transparent.

Rééquilibrez régulièrement les partitions. Avec le partitionnement horizontal, le rééquilibrage des partitions peut aider à distribuer uniformément les données par taille et charge de travail. Rééquilibrez les partitions pour réduire les points d’accès, optimiser les performances des requêtes et contourner les limitations de stockage physique. Cette tâche est complexe et nécessite souvent un outil ou un processus personnalisé.

Répliquez les partitions. Répliquez chaque partition pour fournir une protection ajoutée contre les défaillances. En cas d’échec d’un seul réplica, les requêtes sont dirigées vers une copie de travail.

Étendez l’extensibilité à un autre niveau. Si vous atteignez les limites physiques d’une stratégie de partitionnement, vous devrez peut-être développer l’extensibilité à un autre niveau. Par exemple, si le partitionnement se situe au niveau de la base de données, vous devrez peut-être localiser ou répliquer les partitions dans plusieurs bases de données. Si le partitionnement est déjà au niveau de la base de données et qu’il existe des limitations physiques, vous devrez peut-être localiser ou répliquer des partitions dans plusieurs comptes d’hébergement.

Évitez les transactions qui accèdent à des données présentes dans plusieurs partitions. Certains magasins de données implémentent la cohérence transactionnelle et l’intégrité des opérations qui modifient les données, mais uniquement lorsque les données se trouvent dans une seule partition. Si vous avez besoin d’une prise en charge transactionnelle sur plusieurs partitions, implémentez-la dans le cadre de votre logique d’application, car la plupart des systèmes de partitionnement ne fournissent pas de prise en charge native.

Tous les magasins de données nécessitent une certaine gestion opérationnelle et une certaine surveillance. Ces tâches incluent le chargement des données, la sauvegarde et la restauration des données, la réorganisation des données et la garantie que le système fonctionne correctement et efficacement.

Tenez compte des facteurs suivants qui affectent la gestion des opérations :

Implémentez les tâches de gestion et opérationnelles appropriées lorsque les données sont partitionnée. Ces tâches peuvent inclure la sauvegarde et la restauration, l’archivage de données, la surveillance du système et d’autres tâches d’administration. Par exemple, il peut être difficile de maintenir la cohérence logique pendant les opérations de sauvegarde et de restauration.
Chargez des données dans plusieurs partitions et ajoutez de nouvelles données provenant d’autres sources. Certains outils et utilitaires peuvent ne pas prendre en charge les opérations de données partitionnées, telles que le chargement de données dans la partition correcte.
Archivez et supprimez régulièrement des données. Pour empêcher la croissance excessive des partitions, archiver et supprimer des données chaque mois. Vous devrez peut-être transformer les données pour qu’elles correspondent à un autre schéma d’archivage.
Recherchez les problèmes d’intégrité des données. Envisagez d’exécuter un processus périodique pour localiser les problèmes d’intégrité des données, tels que les données d’une partition qui font référence à des informations manquantes dans une autre. Le processus peut tenter automatiquement de résoudre ces problèmes ou générer un rapport pour une révision manuelle.

Rééquilibrer les partitions

Étant donné que le système évolue, vous devrez peut-être ajuster le schéma de partitionnement. Par exemple, des partitions individuelles peuvent commencer à recevoir un volume disproportionné de trafic et devenir chaudes, ce qui entraîne une contention excessive. Vous avez peut-être sous-estimé le volume de données dans certaines partitions, ce qui entraîne l’approche des limites de capacité des partitions.

Certains magasins de données tels qu’Azure Cosmos DB peuvent rééquilibrer automatiquement les partitions. Dans d’autres cas, vous pouvez rééquilibrer les partitions en deux étapes :

Définissez une nouvelle stratégie de partitionnement.
- Quelles partitions doivent être fractionnées ou combinées ?
- Quelle est la nouvelle clé de partition ?
Migrez des données à partir de l’ancien schéma de partitionnement vers le nouveau jeu de partitions.

Vous devrez peut-être rendre les partitions indisponibles pendant que vous déplacez des données, appelées migration hors connexion. Selon le magasin de données, vous pouvez migrer des données entre des partitions pendant leur utilisation. Cette technique est appelée migration en ligne.

Migration hors connexion

La migration hors connexion réduit le risque de contention. Pour effectuer une migration hors connexion :

Marquez la partition en mode hors connexion. Vous pouvez marquer une partition en lecture seule pour que les applications puissent toujours lire les données lors de leur déplacement.
Fractionnez/fusionnez et déplacez les données vers les nouvelles partitions.
Vérifier les données
Publiez les nouvelles partitions en ligne.
Supprimez l’ancienne partition.

Migration en ligne

La migration en ligne est plus complexe, mais moins perturbatrice par rapport à la migration hors connexion. Le processus est similaire à la migration hors connexion, mais vous ne marquez pas la partition d’origine comme étant hors connexion. Selon la granularité du processus de migration, par exemple l’élément par élément par partition, le code d’accès aux données dans les applications clientes peut avoir à lire et écrire des données situées à deux emplacements, la partition d’origine et la nouvelle partition.

Facilitation Azure

Les sections suivantes décrivent les recommandations relatives au partitionnement des données stockées dans les services Azure.

Partition dans Azure SQL Database

Une base de données SQL est limitée quant au volume de données qu’elle peut contenir. Le débit est limité par des facteurs architecturaux et par le nombre de connexions simultanées prises en charge.

Les pools élastiques prennent en charge la mise à l’échelle horizontale d’une base de données SQL. Utilisez des pools élastiques pour partitionner vos données en partitions réparties entre plusieurs bases de données SQL. Vous pouvez également ajouter ou supprimer des partitions à mesure que le volume de données augmente et diminue. Les pools élastiques permettent également de réduire la contention en répartissant la charge parmi les bases de données.

Chaque partition est mise en œuvre sous forme de base de données SQL. Une partition peut contenir plusieurs jeux de données. Chaque jeu de données est appelé shardlet. Chaque base de données a des métadonnées qui décrivent les shardlets qu’elle contient. Un shardlet peut être un seul élément de données ou un groupe d’éléments qui partagent la même clé de partition. Par exemple, dans une application multilocataire, la clé shardlet peut être l’ID de locataire, et toutes les données d’un locataire peuvent se trouver dans le même shardlet.

Les applications sont responsables de l’association d’un jeu de données à une clé shardlet. Une base de données SQL distincte fonctionne comme un gestionnaire global des cartes des partitions. Cette base de données possède une liste de l’ensemble des partitions et shardlets dans le système. L’application se connecte à la base de données du gestionnaire des cartes de partitions afin d’obtenir une copie des cartes de partitions. Il met en cache la carte de partitions localement et utilise la carte pour acheminer les demandes de données vers la partition appropriée. Cette fonctionnalité est masquée derrière une série d’API contenues dans la bibliothèque cliente de la fonctionnalité base de données élastique de SQL Database, disponible pour Java et .NET.

Pour plus d’informations sur les pools élastiques, consultez Scale-out avec SQL Database.

Pour réduire la latence et améliorer la disponibilité, vous pouvez répliquer la base de données du gestionnaire global des cartes des partitions. Avec les niveaux tarifaires Premium, vous pouvez configurer la géoréplication active pour copier en continu des données vers des bases de données dans différentes régions.

Vous pouvez également utiliser SQL Synchronisation des données pour SQL Database ou Azure Data Factory pour répliquer la base de données du gestionnaire de cartes de partitions entre les régions. Cette forme de réplication s’exécute régulièrement et est plus appropriée si la carte de partitions change rarement et ne nécessite pas le niveau Premium.

La fonction Base de données élastique présente deux schémas de mappage des données vers les shardlets et de stockage dans ces derniers :

Une carte de partitions de liste associe une seule clé à un shardlet. Par exemple, dans un système mutualisé, les données relatives à chaque client peuvent être associées à une clé unique et stockées dans leur propre shardlet. Pour garantir l’isolation, chaque shardlet peut être stocké dans sa propre partition.

Télécharger un fichier Visio de ce diagramme.
Une carte de partitions de plage associe un ensemble de valeurs de clé contiguës à un shardlet. Par exemple, vous pouvez regrouper les données d’un ensemble de locataires, chacun avec leur propre clé, dans le même shardlet. Ce schéma est moins coûteux qu’une carte de partitions de liste, car les locataires partagent le stockage des données, mais elles offrent moins d’isolation.

Télécharger un fichier Visio de ce diagramme

Une même partition peut comporter des données relatives à plusieurs shardlets. Par exemple, vous pouvez utiliser des shardlets de liste pour stocker des données relatives à différents clients non contigus dans la même partition. Vous pouvez également combiner des shardlets de plage et des shardlets de liste dans la même partition, mais ils sont ensuite traités via différentes cartes. Le diagramme qui suit montre cette approche :

Télécharger un fichier Visio de ce diagramme.

Avec les pools élastiques, vous pouvez ajouter et supprimer des partitions à mesure que le volume de données augmente et diminue. Les applications clientes peuvent créer et supprimer des partitions dynamiquement et mettre à jour de manière transparente le gestionnaire de cartes de partitions. Toutefois, la suppression d’une partition est une opération destructive qui nécessite également la suppression de toutes les données présentes dans cette partition.

Si une application doit fractionner une partition en deux partitions distinctes ou combiner des partitions, utilisez l’outil de fractionnement et de fusion. Cet outil s’exécute en tant que service web Azure et migre les données en toute sécurité entre les partitions.

Le schéma de partition peut considérablement affecter les performances de votre système. Il peut également affecter la vitesse à laquelle les partitions doivent être ajoutées ou supprimées, celle à laquelle les données doivent être repartitionnées entre les partitions. Observez les points suivants :

Regroupez les données utilisées ensemble dans la même partition et évitez les opérations qui accèdent aux données de plusieurs partitions. Une partition est une base de données SQL en son propre droit, et les jointures inter-bases de données doivent être effectuées côté client lorsque les opérations accèdent à plusieurs partitions.

Bien que SQL Database ne prend pas en charge les jointures inter-bases de données, vous pouvez utiliser les outils de base de données élastique pour effectuer des requêtes à plusieurs partitions. Une requête multi-partitions envoie des requêtes individuelles à chaque base de données et fusionne les résultats.
Concevez un système qui n’a pas de dépendances entre les partitions. Les contraintes d’intégrité référentielle, les déclencheurs et les procédures stockées d’une base de données ne peuvent pas référencer d’objets dans une autre.
Envisagez de répliquer des données sur des partitions si vous avez des données de référence fréquemment utilisées par les requêtes. Cette approche peut éliminer la nécessité de joindre des données entre les bases de données. Dans l’idéal, ces données doivent être statiques ou lentes pour réduire l’effort de réplication et réduire le risque qu’elles soient obsolètes.
Utilisez le même schéma pour les shardlets qui appartiennent au même mappage de partitions. Cette aide n’est pas appliquée par SQL Database, mais la gestion et l’interrogation des données sont complexes si chaque shardlet a un schéma différent. Créez plutôt des cartes de partitions distinctes pour chaque schéma. Vous pouvez stocker des données qui appartiennent à des shardlets différents dans la même partition.
Stockez des données dans la même partition ou implémentez la cohérence éventuelle si votre logique métier doit effectuer des transactions. Les opérations transactionnelles sont uniquement prises en charge pour les données qui se trouvent dans une partition, et non pour les partitions. Les transactions peuvent s’étendre sur des shardlets s’ils font partie de la même partition.
Disposez les partitions à proximité des utilisateurs qui accèdent aux données stockées dans ces partitions. Cette stratégie aide à réduire la latence.
Évitez d’avoir une combinaison de partitions hautement actives et relativement inactives. Essayez de répartir la charge de manière homogène parmi les partitions. Vous devrez peut-être hacher les clés de partitionnement. Si vous recherchez des partitions géographiquement, assurez-vous que les clés hachées sont mappées aux shardlets conservés dans des partitions stockées à proximité des utilisateurs qui accèdent à ces données.

Partition dans Stockage Blob Azure

Avec le Stockage Blob, vous pouvez stocker des objets binaires volumineux. Utilisez des objets blob de blocs dans des scénarios qui vous obligent à charger ou télécharger rapidement de grands volumes de données. Utilisez des objets blob de pages pour les applications qui nécessitent un accès aléatoire, plutôt qu’en série, à des parties des données.

Chaque objet blob de blocs ou objet blob de pages est conservé dans un conteneur dans un compte de stockage Azure. Utilisez des conteneurs pour regrouper les objets blob associés qui ont les mêmes exigences de sécurité. Ce regroupement est logique, et non physique. Dans un conteneur, chaque objet blob a un nom unique.

La clé de partition d’un objet blob est le nom du compte, le nom du conteneur et le nom de l’objet blob. La clé de partition est utilisée pour partitionner des données en plages. Ces plages sont équilibrées en charge sur le système. Les objets blob peuvent être distribués sur de nombreux serveurs pour effectuer un scale-out de l’accès à ces objets. Un seul objet blob ne peut être servi que par un seul serveur.

Si votre schéma d’affectation de noms utilise des horodatages ou des identificateurs numériques, cela peut entraîner un trafic excessif vers une seule partition. Il empêche le système d’équilibrer efficacement la charge. Par exemple, si vous avez des opérations quotidiennes qui utilisent un objet blob avec un horodatage, tel que aaaa-mm-jj, tout le trafic de cette opération passe à un serveur de partition unique. Au lieu de cela, préfixez le nom avec un hachage à trois chiffres. Pour plus d’informations, consultez la convention d’affectation de noms de partition.

Les actions d’écriture d’un bloc ou d’une page sont atomiques, mais les opérations qui s’étendent sur des blocs, des pages ou des objets blob ne le sont pas. Si vous devez garantir la cohérence lorsque des opérations d’écriture sont effectuées sur des blocs, des pages et des objets blob, supprimez un verrou d’écriture à l’aide d’un bail d’objet blob.

À propos de l’installation

Le partitionnement des données présente des défis et des complexités que vous devez prendre en compte.

La synchronisation des données entre les partitions peut devenir un défi. Assurez-vous que les mises à jour ou les modifications apportées à une partition sont propagées aux autres partitions de manière opportune et cohérente.
Les processus de basculement et de récupération d’urgence deviennent complexes lorsque vous devez coordonner la sauvegarde et la restauration de plusieurs partitions. Les problèmes d’intégrité des données peuvent survenir si certaines partitions ou leurs sauvegardes sont endommagées ou indisponibles.
Le partitionnement des données peut affecter les performances et la fiabilité si vous avez besoin d’effectuer une requête sur plusieurs partitions, et lorsque vous rééquilibrez les partitions si les données augmentent de manière inégale.

Liste de contrôle de fiabilité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de fiabilité

Partager via

Recommandations pour le partitionnement des données

Stratégies de conception