Je n'ai jamais travaillé avec le partitionnement SQL Server mais je suis actuellement confronté à la conception d'une base de données pour laquelle les volumes le justifient probablement. Le système est destiné aux coupons. Les coupons doivent être émis périodiquement, généralement toutes les six semaines, mais il y aura également une émission ponctuelle - par exemple pour un événement spécial. Il y a 15 millions de clients et pour chaque événement d'émission, chaque client recevra 6 types de coupons différents, ce qui donne un total de 90 millions d'instances de coupons. Nous devons suivre les données de rachat des instances de coupons et les conserver pendant 6 mois, bien que généralement un coupon ne soit valide que pendant six semaines. Toute demande de rachat pour un coupon non valide n'atteindra pas la base de données car elle sera validée par le TPV jusqu'au.
Sur une période de six mois, nous devrons stocker jusqu'à 360 millions de lignes dans le tableau Instance du coupon et jusqu'à 72 millions (en supposant un taux de remboursement maximal de 20%) dans le tableau de remboursement. J'ai l'impression que ces chiffres sont trop gros pour une seule partition?
Ma question est - quoi utiliser comme clé de partition? Un candidat évident serait par événement d'émission, donnant environ 6 partitions. Mais alors je pense que peut-être même cela donnerait une taille de partition trop grande pour permettre des performances optimales? Serait-il possible de partitionner par deux clés, par exemple par événement d'émission + dernier chiffre de l'identifiant client? La logique serait donc:
If issuance event = 1 and last digit of customer id < 5 then
Store in partition 1
Else if issuance event = 1 and last digit of customer id >4 then
Store in partition 2
Else if issuance event =2 and last digit of customer id <5 then
Store in partition 3
Else if issuance event =2 and last digit of customer id >4 then
Store in partition 4
Etc...De plus, je ne suis pas sûr de la spécification du serveur de base de données dont nous aurons besoin. Les 16 Go et 8 processeurs seront-ils suffisants? La base de données doit être en mesure de renvoyer un résultat de la table d'instances de coupons, saisie sur une valeur de code-barres numérique en moins d'une demi-seconde. La demande de transaction attendue pour valider (sélectionner) et racheter (insérer) devrait culminer à environ 3 500 par minute.
Le serveur SQL Server 2008r2 64 bits db sera provisionné en tant que machine virtuelle à partir d'un hôte très puissant avec accès à un SAN hautes performances et de grande capacité.
Je serais très reconnaissant pour tout conseil de ceux qui ont déployé une solution SQL Server pour gérer des volumes similaires.
Cordialement
Rob.
la source
Réponses:
Les questions relatives aux spécifications du serveur doivent être adressées à Serverfault ou DBA.SE.
Pour la question du partitionnement, je ne pense pas que vous ayez nécessairement besoin de partitionner pour cela.
360m de lignes c'est beaucoup mais ce n'est pas trop lourd.
Ne pas en aucun cas essayer de partition en fonction du dernier chiffre d'un champ. Je ne suis pas sûr que cela fonctionnerait même, mais ce n'est pas SARGable qui ne serait pas tenable.
Si vous n'avez besoin d'effectuer qu'une seule recherche de ligne basée sur une clé numérique, le partitionnement n'aidera probablement pas.
Si vous décidez de poursuivre la route de partition, n'oubliez pas que pour être efficace, toutes vos requêtes doivent inclure vos clés de partition afin que le moteur sache quelle partition vérifier. Sinon, il les vérifiera tous et vous nuire aux performances.
la source
Vous POUVEZ partitionner sur plusieurs clés si vous utilisez une colonne calculée persistante; comme d'autres l'ont dit, cependant, le partitionnement ne fonctionne pas dans toutes les situations. Je ne suis pas sûr de bien comprendre votre scénario pour vous donner des conseils spécifiques, mais voici quelques directives générales:
Le partitionnement est utile pour lire les données lorsque la clé de partitionnement fait partie de l'instruction SQL, ce qui permet à l'optimiseur d'invoquer l'exclusion de la partition. Vous devez vous assurer que la clé que vous choisissez est utile pour la plupart des requêtes.
L'un des avantages d'une bonne stratégie de partitionnement est le vieillissement des données; par exemple, si votre clé de partition est basée sur la date (c'est-à-dire le jour de l'année) et que vous souhaitez supprimer toutes les données antérieures à une certaine date, il est très facile de basculer ces partitions vers une table vide et de les tronquer.
la source
Vous devez vraiment définir vos besoins un peu plus clairement. Vous mentionnez que vous aurez environ 360 millions de lignes en 6 mois. Et dans 2 ans? Allez-vous encore croître uniquement au rythme que vous êtes en train de croître. Ou y a-t-il une chance que vous connaissiez une croissance exponentielle. Voulez-vous conserver les données dans ce tableau pour toujours; ou souhaitez-vous archiver régulièrement des données.
Le partitionnement peut être utilisé pour l'archivage des données. Voir scénario de fenêtre coulissante. Voir ce livre blanc et celui-ci .
Le partitionnement peut également être utilisé pour gérer la fragmentation d'index. Vous pouvez reconstruire / réorganiser des partitions particulières.
Vous devez également considérer les vues partitionnées par opposition aux tables partitionnées. Les vues partitionnées ne nécessitent pas de licence SQL Server Enterprise. Les vues partitionnées vous permettent également d'effectuer des reconstructions d'index en ligne sur une "partition" particulière.
Le partitionnement peut également être pris en compte lors de la planification de la reprise après sinistre. Il peut être utilisé pour la récupération partielle de la base de données. Par exemple: vous pouvez avoir vos anciennes partitions sur un groupe de fichiers différent de celui des partitions principales / actuelles. Et puis, lorsque vous récupérez, vous récupérez le groupe de fichiers principal, puis le groupe de fichiers sur lequel résident vos partitions actuelles et enfin vous pouvez restaurer les groupes de fichiers sur lesquels résident les anciennes partitions. Cela peut réduire le temps d'arrêt de votre application.
Découvrez cette superbe vidéo de Kimberly Tripp sur le partitionnement .
la source
Sauf si vous effectuez un partitionnement en raison de l'archivage d'anciennes données, vous le faites pour la mauvaise raison et ne devez pas le faire.
la source