web-dev-qa-db-fra.com

Le partitionnement de table améliore-t-il les performances? Est-ce que ça vaut le coup?

Je viens de m'impliquer dans un projet sur lequel je devrai développer un processus de migration de données et une interface web utilisant une base de données SQL Server déjà existante. Cette base de données a été développée par une autre personne il y a plusieurs années, elle contient environ 100 Go de données et elle augmente toutes les 10 minutes (elle stocke 10 minutes de données de plusieurs unités -> 144 enregistrements par jour et par appareil). Plusieurs tables ont environ 10 millions de lignes. Le fait est que je pense que les tableaux principaux ont été conçus d'une manière qui n'est pas la plus efficace ou appropriée pour le type de requêtes qui seront généralement exécutées. Maintenant, je dois prouver si ce que je dis est meilleur que ce qu'il est déjà implémenté. La base de données est vaste en nombre de tables, mais la structure peut être simplifiée par le diagramme suivant: enter image description here

Le champ Date_Id est généré automatiquement par une fonction utilisant le champ DateTime. Il existe deux index dans les deux tables. L'index de cluster pour chaque table contient les champs PK dans le même ordre. Le deuxième index de la table Unit contient uniquement le champ Unit_Id, tandis que le deuxième index dans UnitData contient les champs Unit_Id et DateTime dans cet ordre.

Cependant, je pense que le design devrait être celui-ci: enter image description here

Dans ce cas, seul un index clusterisé pour les champs PK sera nécessaire. Pour cette conception de base de données, la requête habituelle serait quelque chose comme:

SELECT ud.*
FROM Unit u, UnitData ud
WHERE u.Unit_Id = ud.Unit_Id and ud.DateTime >= 'dd-MM-yyyy'
ORDER BY ud.Unit_Id, ud.DateTime

Vient maintenant la chose que je ne comprends vraiment pas: on m'a dit que la seule raison d'avoir une colonne Date_Id est de l'utiliser comme colonne de partitionnement pour cette table. J'ai demandé s'il était vraiment nécessaire de partitionner cette table et la réponse était "d'exécuter les requêtes plus efficacement lorsque l'on voulait des données quotidiennes ou mensuelles". Je ne savais pas grand-chose sur le partitionnement avant cela, j'ai donc vérifié ces liens:

http://msdn.Microsoft.com/en-us/library/ms190787.aspx

Comment le partitionnement de table aide-t-il?

Améliorez les performances en partitionnant

Étant donné que la requête idéale serait le filtrage par périphérique et date/heure, les questions sont les suivantes:

  1. Selon vous, quelle serait la requête la plus efficace et idéale pour la première conception de base de données (avec partitionnement)?
  2. Pensez-vous vraiment que la requête la plus efficace contre la première conception de base de données est meilleure que la seconde (celle que j'ai écrite ci-dessus)?
  3. Si le précédent était affirmatif, pensez-vous vraiment que l'amélioration vaut suffisamment d'avoir deux champs supplémentaires (Id et Date-Id) et un index supplémentaire?

Merci beaucoup!!

sql-serverperformancepartitioningquery-performance
5
Hauri

L'utilisation du partitionnement ne vous aidera à améliorer les performances de votre requête que si le schéma de partitionnement est conçu pour répondre à vos requêtes spécifiques.

Vous devrez revoir vos modèles de requête et voir comment ils accèdent à la table afin d'identifier la meilleure approche. La raison en est que vous ne pouvez partitionner que sur une seule colonne (la clé de partitionnement) et c'est ce qui sera utilisé pour élimination de la partition .

Il y a deux facteurs qui affectent si l'élimination de la partition peut se produire et comment elle fonctionnera:

  1. Clé de partition - Le partitionnement ne peut se produire que sur une seule colonne et votre requête doit inclure cette colonne. Par exemple, si votre table est partitionnée à la date et que votre requête utilise cette colonne de date, alors l'élimination de la partition doit se produire. Cependant, si vous n'incluez pas la clé de partition dans le prédicat de requête, le moteur ne peut pas effectuer l'élimination.
  2. Granularité - Si vos partitions sont trop volumineuses, vous ne tirerez aucun avantage de l’élimination, car elle récupérera toujours plus de données que nécessaire. Cependant, rendez-le trop petit et cela devient difficile à gérer.

À bien des égards, le partitionnement est semblable à l'utilisation de tout autre index, avec des avantages supplémentaires. Cependant, vous ne réalisez pas ces avantages à moins d'avoir affaire à des tables incroyablement grandes. Personnellement, je n'envisage même pas de partitionner jusqu'à ce que ma table dépasse 250 Go. La plupart du temps, une indexation bien définie couvrira de nombreux cas d'utilisation sur des tables plus petites que cela. Sur la base de votre description, vous ne voyez pas une énorme croissance des données, il se pourrait donc qu'une table correctement indexée fonctionne très bien pour votre table.

Je vous recommande fortement de vérifier si le partitionnement est réellement nécessaire pour résoudre vos problèmes. On partitionne généralement une très grande table dans le but de:

  • Répartir les données entre différents types de disques afin que des données plus "actives" puissent être placées sur un stockage plus rapide et plus cher, tandis que des données moins actives sont placées sur un stockage moins cher et plus lent. Il s'agit principalement d'une mesure de réduction des coûts.
  • Aide à la maintenance d'index pour les tables extrêmement volumineuses. Étant donné que vous pouvez reconstruire des partitions individuellement, cela peut aider à maintenir correctement les index avec un impact minimal.
  • Tirer parti du partitionnement pour un processus d'archivage amélioré. Voir fenêtres coulissantes .
10
Mike Fal

Le partitionnement de table peut améliorer les performances si vous êtes capable de travailler dans les limites du fonctionnement de la partition. Voir la description sur:

http://technet.Microsoft.com/en-us/library/ms177411 (v = sql.105) .aspx

Cependant, le partitionnement peut également ralentir le fonctionnement de votre serveur si vos partitions ne sont pas configurées "comme ça" et que vos requêtes ne peuvent pas rester dans une seule partition. Gail Shaw a écrit un article à ce sujet:

https://www.simple-talk.com/sql/database-administration/gail-shaws-sql-server-howlers/

Quelques citations: "Le partitionnement peut améliorer les performances des requêtes, mais il n'y a aucune garantie." Et, "En résumé, le partitionnement est principalement destiné à une maintenance améliorée, à des chargements rapides, à des suppressions rapides et à la capacité de répartir une table sur plusieurs groupes de fichiers; ce n'est pas principalement pour les performances des requêtes."

2
RLF

Lisez ceci sur le partitionnement - SQL Server - Partitions de table sur SSD . En ce qui concerne # 2, votre table sera fragmentée si vous la concevez de cette façon. Vous devez changer l'emplacement des colonnes. Faites de DateTime la première colonne, de cette façon, les nouvelles lignes seront ajoutées en bas, au lieu de trouver de la place pour chaque Unit_Id tous les jours - beaucoup de fractionnements de page. Ensuite, vous pouvez créer un index non sécurisé pour votre requête.

0
DenisT