Concepts sur les tables et les index partitionnés
Le partitionnement facilite la gestion des tables et des index de grande taille, car il permet de gérer et d'accéder rapidement et efficacement à des sous-ensembles de données, tout en conservant l'intégrité d'une collection de données. En utilisant le partitionnement, une opération telle que le chargement des données d'un système OLTP vers un système OLAP ne prend que quelques secondes au lieu des minutes et des heures qu'elle exigeait dans les versions précédentes de SQL Server. En outre, les opérations de maintenance réalisées sur les sous-ensembles de données sont effectuées plus efficacement car elles ne ciblent que les données concernées, au lieu de la totalité de la table.
Notes
Les tables et les index partitionnés sont disponibles uniquement dans les éditions Enterprise, Developer et Evaluation de SQL Server.
Les données des tables et des index partitionnés sont divisées en unités qui peuvent être réparties sur plusieurs groupes de fichiers d'une base de données. Les données sont partitionnées horizontalement, de sorte que les groupes de lignes sont mappés à des partitions individuelles. La table ou l'index est traité en tant qu'entité logique unique lorsque des requêtes ou des mises à jour sont effectuées sur les données. Toutes les partitions d'un index ou d'une table unique doivent résider dans la même base de données.
Les tables et les index partitionnés prennent en charge toutes les propriétés et fonctions associées à la conception et à l'interrogation des tables et des index standard, notamment les contraintes, les valeurs par défaut, les valeurs d'identité et de cachet temporel, ainsi que les déclencheurs. Par conséquent, si vous souhaitez mettre en œuvre une vue partitionnée locale à un serveur, il peut être judicieux de mettre en œuvre une table partitionnée à la place.
La décision concernant la mise en œuvre du partitionnement dépend principalement de la taille actuelle ou future de votre table, de son utilisation et de son niveau de performances par rapport aux requêtes utilisateur et aux opérations de maintenance.
Généralement, une table de grande taille peut être un bon candidat au partitionnement si les deux conditions suivantes sont réunies :
La table contient, ou il est prévu qu'elle contienne, un grand nombre de données utilisées de différentes manières.
Les requêtes ou les mises à jour sur la table ne fonctionnent pas comme prévu, ou les coûts de maintenance dépassent les périodes de maintenance prédéfinies.
Par exemple, si un mois actuel de données est principalement utilisé pour les opérations INSERT, UPDATE, DELETE et MERGE alors que les mois précédents sont principalement soumis à des requêtes SELECT, la gestion de cette table peut être plus facile si elle est partitionnée par mois. Cet avantage se vérifie particulièrement si les opérations régulières de maintenance sur la table doivent seulement cibler un sous-ensemble de données. Si la table n'est pas partitionnée, ces opérations peuvent consommer une grande quantité de ressources sur un ensemble de données complet. Grâce au partitionnement, les opérations de maintenance, telles que les reconstructions d'index et les défragmentations, peuvent être effectuées sur un seul mois de données en écriture seule par exemple, tandis que les données en lecture seule restent accessibles en ligne.
Pour prolonger cet exemple, supposez que vous voulez déplacer un mois de données en lecture seule de cette table dans une table d'un entrepôt de données pour l'analyser. Grâce au partitionnement, les sous-ensembles de données peuvent être séparés rapidement en zones de transit pour une maintenance hors connexion, puis ajoutés en tant que partition aux tables partitionnées existantes, en supposant que ces tables sont toutes dans la même instance de base de données. De telles opérations demandent en général quelques secondes au lieu des minutes ou des heures qu'elles exigeaient dans les versions précédentes.
Le partitionnement d'une table ou d'un index peut améliorer les performances des requêtes, si les partitions sont correctement conçues en fonction du type des requêtes fréquemment exécutées et de la configuration matérielle. Pour plus d'informations, consultez Conception de partitions pour améliorer les performances des requêtes.
Le partitionnement est souvent utilisé avec la réplication SQL Server. Le fait d'utiliser des partitions vous permet d'optimiser les performances de la réplication transactionnelle et de la réplication de fusion en réduisant efficacement la quantité de données et de métadonnées qui doivent être fusionnées par le système de réplication. La réplication prend en charge un maximum de 1024 partitions par table. Pour plus d'informations, consultez Réplication de tables et d'index partitionnés.
Pour illustrer l'application d'une solution de partitionnement dans une base de données réelle, vous pouvez mettre en œuvre un scénario de partitionnement disponible dans l'exemple de base de données AdventureWorks2008R2. Ce scénario est expliqué dans Partitionnement dans l'exemple de base de données AdventureWorks2008R2.
Architecture du partitionnement
Dans SQL Server, toutes les tables et tous les index d'une base de données sont considérés partitionnés, même s'ils sont constitués d'une seule partition. Grossièrement, les partitions forment l'unité organisationnelle de base dans l'architecture physique des tables et des index. En d'autres termes, l'architecture logique et physique des tables et des index composés de plusieurs partitions reflète celle des tables et des index à partition unique. Pour plus d'informations, consultez Organisation des tables et des index.