Conseils de partitionnement des données

Dans de nombreuses solutions à grande échelle, les données sont divisées en partitions qui peuvent être gérées et accessibles séparément. Le partitionnement peut améliorer l’extensibilité, réduire la contention et optimiser les performances. Il peut également offrir un mécanisme pour la division des données à l’aide d’un modèle d’utilisation. Par exemple, vous pouvez archiver les données plus anciennes dans un stockage de données plus économique.

Toutefois, la stratégie de partitionnement doit être choisie avec soin pour maximiser les avantages tout en minimisant les effets indésirables.

Pourquoi partitionner des données ?

• Améliorez la scalabilité. Lorsque vous effectuez un scale-up d’un système de base de données unique, il atteint finalement une limite matérielle physique. Si vous divisez les données entre plusieurs partitions, chacune hébergée sur un serveur distinct, vous pouvez effectuer un scale-out du système presque indéfiniment.

• Améliorez les performances. Les opérations d’accès aux données sur chaque partition ont lieu sur un plus petit volume de données. Correctement effectué, le partitionnement peut 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.

• Fournir une flexibilité opérationnelle. Le partitionnement offre de nombreuses possibilités d’optimisation des opérations, d’optimisation de l’efficacité administrative et de réduction des coûts. Par exemple, vous pouvez définir différentes stratégies de gestion, de supervision, 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. Le partitionnement permet à chaque partition d’être déployée 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, les données binaires volumineuses peuvent être stockées dans le stockage d’objets blob, tandis que des données plus structurées peuvent être conservées dans une base de données de documents. Pour plus d’informations, consultez Choisir le magasin de données approprié.

• Améliorer la disponibilité. La séparation des données entre plusieurs serveurs évite un point de défaillance unique. Si une instance échoue, seules les données de cette partition ne sont pas disponibles. Les opérations sur d’autres partitions peuvent continuer. Pour les magasins de données PaaS (Managed Platform as a Service), cette considération est moins pertinente, car ces services sont conçus avec une redondance intégrée.

Conception de partitions

Il existe trois stratégies classiques pour le partitionnement des données :

• Partitionnement horizontal (souvent appelé partitionnement). 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 spécifique des données, comme toutes les commandes d’un ensemble spécifique de clients.

• Partitionnement vertical. Dans cette stratégie, chaque partition contient un sous-ensemble des champs des éléments du magasin de données. Les champs sont divisés en fonction de leur modèle d’utilisation. Par exemple, les champs fréquemment consultés peuvent être placés dans une partition verticale et des champs moins fréquemment consultés dans un autre.

• Partitionnement fonctionnel. Dans cette stratégie, les données sont agrégées en fonction de la façon dont elles sont utilisées par chaque contexte limité dans le système. Par exemple, un système de commerce électronique peut stocker des données de facture dans une partition et des données d’inventaire des produits dans une autre.

Ces stratégies peuvent être combinées et nous vous recommandons de les considérer toutes lorsque vous concevez un schéma de partitionnement. Par exemple, vous pouvez diviser les données en partitions, puis utiliser le partitionnement vertical pour subdiviser davantage les données de chaque partition.

Partitionnement horizontal (partitionnement)

La figure 1 montre le partitionnement horizontal ou le partitionnement. Dans cet exemple, les données d’inventaire des produits sont divisées en partitions en fonction de la clé de produit. Chaque partition contient les données d’une plage contiguë de clés de partitions (A-G et H-Z), organisées par ordre alphabétique. Le partitionnement répartit la charge sur plus d’ordinateurs, ce qui réduit la contention et améliore les performances.

Figure 1 : partitionnement horizontal (partitionnement) des données basées sur une clé de partition.

Le facteur le plus important est le choix d’une clé de partitionnement. Il peut être difficile de modifier la clé une fois que le système est en cours d’opération. La clé doit s’assurer que les données sont partitionnées pour répartir la charge de travail aussi uniformément que possible sur les partitions.

Les partitions n’ont pas besoin d’être de la même taille. Il est plus important d’équilibrer le nombre de demandes. Certaines partitions peuvent être très volumineuses, mais chaque élément a un faible nombre d’opérations d’accès. D’autres partitions peuvent être plus petites, mais chaque élément est accessible beaucoup plus fréquemment. Il est également important de s’assurer qu’un seul fragment ne dépasse pas les limites d’échelle (en termes de capacité et de ressources de traitement) du magasin de données.

Évitez de créer des partitions « chaudes » qui peuvent affecter les performances et la disponibilité. Par exemple, l’utilisation de la première lettre du nom d’un client provoque une distribution déséquilibré, car certaines lettres sont plus courantes. Utilisez plutôt un hachage d’un identificateur de client pour distribuer les données de manière plus uniforme entre les partitions.

Choisissez une clé de partitionnement qui réduit les exigences futures pour fractionner de grandes partitions, fusionner de petites partitions en partitions plus grandes ou modifier le schéma. Ces opérations peuvent prendre beaucoup de temps et nécessiter une ou plusieurs partitions hors connexion pendant qu’elles sont effectuées.

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

Pour plus d’informations sur le partitionnement horizontal, consultez le 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 d’éléments fréquemment consultés. La figure 2 montre un exemple de partitionnement vertical. Dans cet exemple, différentes propriétés d’un élément sont stockées dans différentes partitions. Une partition contient des données plus fréquemment accessibles, notamment le nom du produit, la description et le prix. Une autre partition contient les données d’inventaire : le nombre d’actions et la date de la dernière commande.

Figure 2 : partitionnement vertical des données par son modèle d’utilisation.

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

Autres avantages du partitionnement vertical :

• Les données relativement lentes (nom du produit, description et prix) peuvent être séparées des données plus dynamiques (niveau 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.

• Les données sensibles peuvent être stockées dans une partition distincte avec des contrôles de sécurité supplémentaires.

• Le partitionnement vertical peut réduire la quantité d’accès simultané 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 la décomposer d’un élément large à un ensemble d’éléments étroits . 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, vous pouvez également envisager d’utiliser des magasins de colonnes dans SQL Server.

Partitionnement fonctionnel

Lorsqu’il est possible d’identifier un contexte limité pour chaque domaine d’activité distinct dans une application, le partitionnement fonctionnel permet d’améliorer les performances d’isolation et d’accès aux données. Une autre utilisation courante du partitionnement fonctionnel consiste à séparer les données en lecture-écriture des données en lecture seule. La figure 3 présente une vue d’ensemble du partitionnement fonctionnel où les données d’inventaire sont séparées des données client.

Figure 3 : partitionnement fonctionnel des données par contexte ou sous-domaine délimité.

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

Conception de partitions pour l’extensibilité

Il est essentiel de prendre en compte la taille et la charge de travail de chaque partition et de les équilibrer 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 lors de la conception de partitions pour l’extensibilité :

1. 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 de calcul côté serveur. Dans de nombreux cas, quelques entités majeures demandent la plupart des ressources de traitement.
2. Utilisez cette analyse pour déterminer les cibles actuelles et futures de scalabilité, telles que la taille des données et la charge de travail. Ensuite, distribuez les données entre les partitions pour répondre à la cible d’extensibilité. Pour le partitionnement horizontal, il est important de choisir la clé de partition appropriée pour vous assurer que la distribution est égale. Pour plus d’informations, consultez le modèle de partitionnement.
3. 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, la quantité d’espace de stockage, la puissance de traitement ou la bande passante réseau par partition peuvent être limitées. 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, en combinant éventuellement deux stratégies ou plus.
4. Surveillez le système pour vérifier que les données sont distribuées 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. Si c’est le cas, il peut être possible de rééquilibrer les partitions, ou de revoir certaines parties du système pour obtenir l’équilibre requis.

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

Par exemple, si vous utilisez le stockage de tables Azure, il existe une limite au volume de requêtes qui peuvent être gérées par une partition unique dans une période particulière. (Pour plus d’informations, consultez les objectifs de performance et d’extensibilité du stockage Azure.) Une partition occupée peut nécessiter plus de ressources qu’une seule partition peut gérer. Si c’est le cas, la partition peut avoir besoin d’être repartitionnée 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 des comptes de stockage supplémentaires et répartir les tables entre ces comptes.

Conception de partitions pour les performances des requêtes

Les performances des requêtes peuvent souvent être améliorées à l’aide de jeux de données plus petits et en exécutant des requêtes parallèles. Chaque partition doit contenir une petite proportion de l’ensemble du jeu de données. Cette réduction du volume peut améliorer les performances des requêtes. Toutefois, le partitionnement n’est pas une alternative à la conception et à la configuration appropriée d’une base de données. Par exemple, vérifiez que vous disposez des index nécessaires en place.

Suivez ces étapes lors de la conception de partitions pour les performances des requêtes :

1. Examinez les exigences et les performances de l’application :

   • Utilisez les exigences métier pour déterminer les requêtes critiques qui doivent toujours être effectuées rapidement.
   • Surveillez le système pour identifier les requêtes qui s’exécutent lentement.
   • Recherchez les requêtes qui sont effectuées le plus fréquemment. Même si une requête unique a un coût minimal, la consommation cumulative des ressources peut être importante.

2. Partitionnez les données à l’origine de performances lentes :

   • Limitez la taille de chaque partition afin que le temps de réponse de la requête soit dans la cible.
   • Si vous utilisez le partitionnement horizontal, concevez la clé de partition afin que l’application puisse facilement sélectionner la partition appropriée. Cela empêche la requête d’avoir à analyser chaque partition.
   • Considérez l’emplacement d’une partition. Si possible, essayez de conserver des données dans des partitions qui sont géographiquement proches des applications et des utilisateurs qui y accèdent.

3. 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 cela ne répond toujours pas aux exigences, appliquez également le partitionnement horizontal. Dans la plupart des cas, une stratégie de partitionnement unique suffit, mais dans certains cas, il est plus efficace de combiner les deux stratégies.

4. Envisagez d’exécuter des requêtes en parallèle entre les partitions pour améliorer les performances.

Conception de partitions pour la disponibilité

Le partitionnement des données peut améliorer la disponibilité des applications en s’assurant que l’ensemble du jeu de données ne constitue pas un point de défaillance unique et que les sous-ensembles individuels du jeu de données peuvent être gérés indépendamment.

Tenez compte des facteurs suivants qui affectent la disponibilité :

Critique des données pour les opérations métier. Identifiez les données critiques, telles que les transactions, et les données moins critiques, telles que les fichiers journaux.

• Envisagez de stocker des données critiques dans des partitions hautement disponibles avec un plan de sauvegarde approprié.

• Établissez des procédures de gestion et de surveillance distinctes pour les 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 ensemble à une fréquence appropriée. Par exemple, les partitions qui contiennent des données de transaction peuvent avoir besoin d’être sauvegardées plus fréquemment que les partitions qui contiennent des informations de journalisation ou de trace.

Gestion des partitions individuelles. La conception de partitions pour prendre en charge la gestion et la maintenance indépendantes offre plusieurs avantages. Par exemple:

• En cas d’échec d’une partition, elle peut être récupérée indépendamment sans les applications qui accèdent aux données 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 trop volumineuses pour empêcher toute maintenance planifiée d’être terminée pendant cette période.

Indique s’il faut répliquer des données critiques entre les partitions. Cette stratégie peut améliorer la disponibilité et les performances, mais peut également introduire des problèmes de cohérence. Il faut du temps pour synchroniser les modifications avec chaque réplica. Pendant cette période, différentes partitions contiennent des valeurs de données différentes.

Considérations relatives à la conception d’application

Le partitionnement ajoute de la complexité à la conception et au développement de votre système. Envisagez le partitionnement comme une partie fondamentale de la conception du système, même si le système ne contient initialement qu’une seule partition. Si vous traitez le partitionnement comme une réflexion après coup, cela devient plus difficile car vous avez déjà un système en production à maintenir.

• La logique d’accès aux données doit être modifiée.
• Il peut être nécessaire de migrer de grandes quantités de données existantes pour la distribuer entre les partitions.
• Les utilisateurs s’attendent à pouvoir continuer à utiliser le système pendant la migration.

Dans certains cas, le partitionnement n’est pas considéré comme important, car le jeu de données initial est petit et facilement géré par un seul serveur. Cela peut être vrai pour certaines charges de travail, mais de nombreux systèmes commerciaux doivent s’étendre à mesure que le nombre d’utilisateurs augmente.

De plus, il ne s’agit pas seulement de magasins de données volumineux qui bénéficient du partitionnement. Par exemple, un petit magasin de données peut être largement accessible par des centaines de clients simultanés. Le partitionnement des données dans cette situation peut contribuer à réduire la contention et à améliorer le débit.

Tenez compte des points suivants lorsque vous concevez un schéma de partitionnement de données :

Réduisez les opérations d’accès aux données entre partitions. Si possible, conservez les données pour les opérations de base de données les plus courantes dans chaque partition afin de réduire les opérations d’accès aux données entre partitions. L’interrogation sur plusieurs partitions peut prendre plus de temps que d’interroger au sein d’une seule partition, mais l’optimisation des partitions pour un ensemble de requêtes peut affecter négativement d’autres ensembles de requêtes. Si vous devez interroger des partitions, réduisez le temps de requête en exécutant des requêtes parallèles et en agrégeant les résultats au sein de l’application. (Cette approche peut ne pas être possible dans certains cas, par exemple lorsque le résultat d’une requête est utilisé dans la requête suivante.)

Envisagez de 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 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 provenant de l’ensemble du système. Toutefois, il existe un coût supplémentaire associé à la synchronisation des modifications apportées aux données de référence.

Réduisez les jointures entre partitions. Si possible, réduisez les exigences en matière d’intégrité référentielle sur les partitions verticales et fonctionnelles. Dans ces schémas, l’application est chargée de maintenir l’intégrité référentielle entre les partitions. Les requêtes qui joignent des données sur plusieurs partitions sont inefficaces, car l’application doit généralement effectuer des requêtes consécutives en fonction d’une clé, puis d’une clé étrangère. Au lieu de cela, envisagez de répliquer ou de dé normaliser les données pertinentes. Si des jointures entre partitions sont nécessaires, exécutez des requêtes parallèles sur les partitions et joignez les données au sein de l’application.

Embrassez la cohérence éventuelle. Évaluez si une cohérence forte est en fait une exigence. Une approche courante dans les systèmes distribués consiste à implémenter la cohérence éventuelle. Les données de chaque partition sont mises à jour séparément et la logique de l’application garantit que les mises à jour sont terminées correctement. Il gère également les incohérences qui peuvent provenir de l’interrogation des données pendant qu’une opération cohérente est en cours d’exécution.

Réfléchissez à la façon dont les requêtes localisent la partition correcte. Si une requête doit analyser toutes les partitions pour localiser les données requises, il existe un impact significatif sur les performances, même lorsque plusieurs requêtes parallèles sont en cours d’exécution. Avec le partitionnement vertical et fonctionnel, les requêtes peuvent naturellement spécifier la partition. Le partitionnement horizontal, d’autre part, peut rendre difficile la localisation d’un élément, car chaque partition a le même schéma. Solution classique pour gérer une carte utilisée pour rechercher l’emplacement de partition pour des éléments spécifiques. Cette carte peut être implémentée dans la logique de partitionnement de l’application ou gérée par le magasin de données si elle prend en charge le partitionnement transparent.

Envisagez de rééquilibrer périodiquement les partitions. Avec le partitionnement horizontal, le rééquilibrage des partitions peut aider à distribuer les données uniformément par taille et par charge de travail pour réduire les points d’accès, optimiser les performances des requêtes et contourner les limitations de stockage physique. Toutefois, il s’agit d’une tâche complexe qui nécessite souvent l’utilisation d’un outil ou d’un processus personnalisé.

Répliquer des partitions. Si vous répliquez chaque partition, elle offre une protection supplémentaire contre les défaillances. En cas d’échec d’un seul réplica, les requêtes peuvent être dirigées vers une copie de travail.

Si vous atteignez les limites physiques d’une stratégie de partitionnement, vous devrez peut-être étendre l’extensibilité à un autre niveau. Par exemple, si le partitionnement se trouve au niveau de la base de données, vous devrez peut-être localiser ou répliquer des partitions dans plusieurs bases de données. Si le partitionnement est déjà au niveau de la base de données et que les limitations physiques sont un problème, cela peut signifier que vous devez localiser ou répliquer des partitions dans plusieurs comptes d’hébergement.

Évitez les transactions qui accèdent aux données 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, vous devez probablement l’implémenter 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 activité de gestion opérationnelle et de surveillance. Les tâches peuvent aller du chargement des données, de la sauvegarde et de la restauration des données, de la réorganisation des données et de l’exécution correcte et efficace du système.

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

• Comment implémenter des tâches de gestion et opérationnelles appropriées lorsque les données sont partitionnés. Ces tâches peuvent inclure la sauvegarde et la restauration, l’archivage des données, la surveillance du système et d’autres tâches administratives. Par exemple, la maintenance de la cohérence logique pendant les opérations de sauvegarde et de restauration peut être un défi.

• Comment charger les données dans plusieurs partitions et ajouter 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.

• Comment archiver et supprimer régulièrement les données. Pour éviter la croissance excessive des partitions, vous devez archiver et supprimer des données régulièrement (par exemple, mensuellement). Il peut être nécessaire de transformer les données pour qu’elles correspondent à un autre schéma d’archivage.

• Comment 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 à des informations manquantes dans une autre. Le processus peut tenter de résoudre ces problèmes automatiquement ou générer un rapport pour une révision manuelle.

Rééquilibrage des partitions

À mesure qu’un système mûrit, vous devrez peut-être ajuster le schéma de partitionnement. Par exemple, des partitions individuelles peuvent commencer à obtenir 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é de certaines partitions.

Certains magasins de données, tels qu’Azure Cosmos DB, peuvent rééquilibrer automatiquement les partitions. Dans d’autres cas, le rééquilibrage est une tâche administrative qui se compose de deux étapes :

1. Déterminez une nouvelle stratégie de partitionnement.

   • Quelles partitions doivent être fractionnées (ou éventuellement combinées) ?
   • Qu’est-ce que la nouvelle clé de partition ?

2. Migrez les données de l’ancien schéma de partitionnement vers le nouvel ensemble de partitions.

Selon le magasin de données, vous pouvez peut-être migrer des données entre des partitions pendant leur utilisation. Il s’agit de la migration en ligne. Si cela n’est pas possible, vous devrez peut-être rendre les partitions indisponibles pendant que les données sont déplacées (migration hors connexion).

Migration hors connexion

La migration hors connexion est généralement plus simple, car elle réduit les risques de contention. Conceptuellement, la migration hors connexion fonctionne comme suit :

1. Marquez la partition hors connexion.
2. Fractionnez-fusionnez et déplacez les données vers les nouvelles partitions.
3. Vérifier les données
4. Mettez en ligne les nouvelles partitions.
5. Supprimez l’ancienne partition.

Si vous le souhaitez, vous pouvez marquer une partition comme étant en lecture seule à l’étape 1, afin que les applications puissent toujours lire les données lorsqu’elles sont déplacées.

Migration en ligne

La migration en ligne est plus complexe à effectuer, mais moins perturbatrice. Le processus est similaire à la migration hors connexion, sauf que la partition d’origine n’est pas marquée hors connexion. En fonction de la granularité du processus de migration (par exemple, élément par élément par partition par partition), le code d’accès aux données dans les applications clientes peut avoir à gérer la lecture et l’écriture de données conservées à deux emplacements, la partition d’origine et la nouvelle partition.

Étapes suivantes

• Découvrez les stratégies de partitionnement pour des services Azure spécifiques. Pour plus d’informations, consultez stratégies de partitionnement des données.
• Objectifs de performance et d’extensibilité du stockage Azure

Ressources associées

• Choisir le magasin de données approprié

Les modèles de conception suivants peuvent être pertinents pour votre scénario :

• Le modèle de partitionnement décrit certaines stratégies courantes pour les données de partitionnement.

• Le modèle de table d’index montre comment créer des index secondaires sur des données. Une application peut rapidement récupérer des données avec cette approche, en utilisant des requêtes qui ne référencent pas la clé primaire d’une collection.

• Le modèle de vue matérialisé décrit comment générer des vues préremplies qui résument les données pour prendre en charge les opérations de requête rapides. Cette approche peut être utile dans un magasin de données partitionné si les partitions qui contiennent les données récapitulisées sont distribuées sur plusieurs sites.