Recommandations pour le partitionnement des données

Article
11/15/2023

S’applique à cette recommandation de liste de vérification de fiabilité 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 associé :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 base de données et 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 la scalabilité, réduit les conflits 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 négatifs.

Notes

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 SQL Server table.

Pourquoi partitionner les données ?

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 sur plusieurs partitions, chaque partition étant 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 volume de données plus petit que les 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 en 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 pour la gestion, la surveillance, la sauvegarde et la restauration, ainsi que 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 type différent de magasin de données en fonction du coût et des fonctionnalités intégrées qu’offre 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 sur plusieurs serveurs. Lorsqu’une instance échoue, seules les données de cette partition sont indisponibles. Les opérations se poursuivent dans d’autres partitions. Cette considération est moins pertinente pour les magasins de données PaaS (Managed Platform as a Service), car ils disposent d’une redondance intégrée.

Concevoir des partitions

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 partitionnement. Cet exemple montre comment diviser 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 le 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 accessible plus fréquemment. Il est également important de s’assurer qu’une seule partition ne dépasse pas les limites de mise à l’échelle, en termes de capacité et de ressources de traitement, du magasin de données.

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

Choisissez une clé de partitionnement qui réduit le besoin futur de fractionner des partitions volumineuses, de combiner de petites partitions en partitions plus grandes ou de modifier le schéma. Ces opérations prennent beaucoup de temps et peuvent vous obliger à mettre une ou plusieurs partitions hors connexion.

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 du partitionnement vertical consiste à réduire les coûts d’E/S et de performances associés à l’extraction des é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 les données qui sont consultées 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 de stock 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) des données plus dynamiques (niveau de stock 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 délimité peut être identifié pour chaque secteur d’activité distinct 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 dont les données d’inventaire sont 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 la scalabilité

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 partition unique.

Suivez ces étapes lorsque vous concevez des partitions pour la scalabilité :

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 grandes entités exigent la plupart des ressources de traitement.
Utilisez cette analyse pour déterminer les objectifs de scalabilité actuels et futurs, tels que la taille des données et la charge de travail. 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 une distribution uniforme. 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, la puissance de traitement ou la 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édit. Vous devrez peut-être rééquilibrer les partitions ou reconcevoir 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 d’espace 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 donnée. 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 totale ou le débit de ces tables dépasse la capacité d’un compte de stockage, vous devrez peut-être créer d’autres 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 en utilisant de petits jeux de données et en exécutant des requêtes parallèles. Chaque partition doit contenir une petite proportion du jeu de données entier. 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 appropriées de la base de données. Veillez à implémenter 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 fonctionnent 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 cumulée de ressources peut être importante.
Partitionnez les données qui entraînent 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 les 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 de performances de débit et de requête, utilisez un 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 appropriée, mais dans certains cas, il est plus efficace de combiner les deux stratégies.
Exécutez des requêtes en parallèle sur plusieurs partitions pour améliorer les performances.

Concevoir des partitions pour la disponibilité

Partitionner les données pour améliorer la disponibilité des applications. Le partitionnement garantit que l’ensemble du jeu de données n’a pas un seul point de défaillance 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 le caractère critique 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 les partitions qui contiennent des informations de journalisation ou de suivi.

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 aux heures creuses pour chaque emplacement. Assurez-vous que les partitions ne sont pas si volumineuses qu’elles empêchent la maintenance planifiée de se terminer 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.

Considérations relatives à la conception d’applications

Le partitionnement complique la conception et le développement du système. Partitionner les données en tant que partie fondamentale de la conception de votre système, même si le système ne contient initialement qu’une seule partition. Si vous envisagez le partitionnement après coup, c’est difficile, car vous avez déjà 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 les distribuer entre les partitions.
Rencontrez des défis, 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 serveur unique 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 tirent également parti 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 les conflits 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 les 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 être plus long d’interroger entre des partitions plutôt que d’interroger au sein d’une seule partition. Toutefois, l’optimisation des partitions pour un ensemble de requêtes peut nuire à 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épliquer des 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 codes postaux ou des listes de produits, envisagez de répliquer ces données dans toutes les partitions afin de 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 important provenant de l’ensemble du système. Des coûts supplémentaires sont 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 sur 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 une exigence. 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 d’application garantit que les mises à jour se terminent correctement. La logique d’application gère également les incohérences qui découlent de l’interrogation des données pendant qu’une opération 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, cela affecte considérablement les performances, même lorsque 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 qui est utilisée pour rechercher l’emplacement de partition des éléments. Implémentez cette carte dans la logique de partitionnement de l’application. Il peut également être géré par le magasin de données si le magasin de données prend en charge le partitionnement transparent.

Rééquilibrez les partitions régulièrement. Avec le partitionnement horizontal, le rééquilibrage des partitions peut aider à répartir 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 du 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 supplémentaire contre les défaillances. Si une seule réplica échoue, les requêtes sont dirigées vers une copie de travail.

Étendez la scalabilité à 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 et l’intégrité transactionnelles pour les 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 de 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 des tâches de gestion et opérationnelles appropriées lorsque les données sont partitionnées. 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 appropriée.
Archivez et supprimez des données régulièrement. Pour éviter la croissance excessive des partitions, archivez et supprimez des données chaque mois. Vous devrez peut-être transformer les données pour qu’elles correspondent à un autre schéma d’archive.
Localiser 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 aux 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, les partitions individuelles peuvent commencer à recevoir un volume de trafic disproportionné et devenir chaudes, ce qui entraîne une contention excessive. Ou 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 ?
- Qu’est-ce que 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 le déplacement des données, ce qui est appelé 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 conflit. Pour effectuer une migration hors connexion :

Marquez la partition comme hors connexion. Vous pouvez marquer une partition comme en lecture seule afin que les applications puissent toujours lire les données pendant que vous les déplacez.
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 que la migration hors connexion. Le processus est similaire à la migration hors connexion, mais vous ne marquez pas la partition d’origine comme hors connexion. En fonction de la granularité du processus de migration, par exemple élément par élément et partition par partition, le code d’accès aux données dans les applications clientes peut devoir lire et écrire des données qui se trouvent à deux emplacements, la partition d’origine et la nouvelle partition.

Facilitation Azure

Les sections suivantes décrivent des recommandations pour le 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 sur 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é un 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 shardlet. Par exemple, dans une application multilocataire, la clé de 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é de 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é se cache derrière une série d’API contenues dans la bibliothèque cliente de la fonctionnalité de 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 Data Sync 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 clé unique à 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 sa 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 il offre 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 mélanger des shardlets de plage et répertorier des shardlets dans la même partition, mais ils sont ensuite traités via des cartes différentes. 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 en toute transparence mettre à jour le gestionnaire de carte 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 dans la même partition et évitez les opérations qui accèdent aux données à partir de plusieurs partitions. Une partition est une base de données SQL à part entière, et les jointures entre bases de données doivent être effectuées côté client lorsque des 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 élastiques pour effectuer des requêtes multi-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érentielles, les déclencheurs et les procédures stockées dans 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 des 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 d’obsolescence.
Utilisez le même schéma pour les shardlets qui appartiennent à la même carte de partitions. Ces conseils ne sont pas appliqués 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 à différents shardlets dans la même partition.
Stockez les données dans la même partition ou implémentez une 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 sur les partitions. Les transactions peuvent s’étendre sur des shardlets si elles 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 géolocalisez des partitions, assurez-vous que les clés de hachage sont mappées à des partitions conservées dans des partitions stockées à proximité des utilisateurs qui accèdent à ces données.

Partition dans Stockage Blob Azure

Avec 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 que série, à certaines parties des données.

Chaque objet blob de bloc ou objet blob de page est conservé dans un conteneur dans un compte de stockage Azure. Utilisez des conteneurs pour regrouper des 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 les données en plages. Ces plages sont équilibrées en charge sur l’ensemble du système. Les objets blob peuvent être distribués sur de nombreux serveurs pour augmenter l’accès à ceux-ci. Un objet blob unique ne peut être pris en charge que par un seul serveur.

Si votre schéma de nommage utilise des horodatages ou des identificateurs numériques, cela peut entraîner un trafic excessif vers une partition. Cela empêche le système d’équilibrer efficacement la charge. Par instance, 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 est dirigé vers un serveur de partition unique. Au lieu de cela, préfixez le nom d’un hachage à trois chiffres. Pour plus d’informations, consultez Convention de nommage de partition.

Les actions d’écriture d’un seul 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.

Considérations

Le partitionnement des données présente certains défis et 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 modifications apportées à une partition sont propagées aux autres partitions de manière cohérente et en temps opportun.
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. Des 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 devez interroger les 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é

Recommandations pour le partitionnement des données