Tout d'abord, notez qu'un milliard de lignes peuvent être traitées efficacement avec une architecture partitionnée sur du matériel de serveur ordinaire. Les architectures exotiques de partage de données ne seront pas nécessaires pour ce volume de données, mais vous bénéficierez probablement d'importants avantages du partitionnement de table.
Le partitionnement est quelque chose de différent du partitionnement horizontal et implique une architecture de «partage de rien», qui n'est pas prise en charge par la plupart des versions de SQL Server 1
SQL Server peut prendre en charge le partitionnement horizontal et une architecture de disque partagé sera suffisante pour environ 1 ligne de milliard.
Dans SQL Server, vous créez une fonction de partition sélectionne une partition basée sur des valeurs ou des plages de valeurs dans une colonne sur une table, par exemple
create partition function F_AccPrdPart (int)
as range left for values (
180001 -- Dummy value
,199012 ,199112 ,199212 ,199312, 199412 ,199512
,199612 ,199712 ,199812 ,199912 ,200012 ,200112
,200212 ,200312 ,200412 ,200512 ,200612 ,200712
,200812
,200901, 200902, 200903, 200904, 200905, 200906
,200907, 200908, 200909, 200910, 200911, 200912
,201001, 201002, 201003, 201004, 201005, 201006
,201007, 201008, 201009, 201010, 201011, 201012
,201101, 201102, 201103, 201104, 201105, 201106
,201107, 201108, 201109, 201110, 201111, 201112
,202012
,939999 -- Dummy value
)
go
Créez ensuite un ou plusieurs groupes de fichiers auxquels allouer les partitions. Pour un ensemble de données volumineux, ces groupes de fichiers peuvent être configurés sur différents volumes physiques. Notez que le stockage à connexion directe sera beaucoup plus rapide qu'un SAN pour cela dans presque tous les cas. Dans l'exemple ci-dessous, nous aurions créé 6 groupes de fichiers appelés PartVol1-PartVol6.
Un ou plusieurs schémas de partition peuvent être créés pour allouer des partitions de table à des groupes de fichiers en fonction de la valeur de la fonction de partition, par exemple
create partition S_AccPrdPart as partition F_AccPrdPart
TO ([PRIMARY]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1], [PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6]
,[PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2], [PartVol3], [PartVol4], [PartVol5], [PartVol6], [PartVol1]
,[PartVol2]
,[PRIMARY]
,[PRIMARY])
go
Ce schéma est conçu pour se répartir sur une période comptable. Les dates sont également fréquemment utilisées pour cela, bien que n'importe quelle clé puisse être utilisée.
Vous pouvez créer une table sur le schéma de partition comme s'il s'agissait d'un groupe de fichiers, par exemple
Create table FooTrans (
FooTransID int identity (1,1) not null
,AccPeriod int not null
,[...]
) on S_AccPrdPart (AccPeriod)
go
Notez que la table est créée sur le schéma de partition au lieu d'un groupe de fichiers spécifié et la clause spécifie la colonne à utiliser comme clé de partition. En fonction de la clé de partition, les lignes de la table seront allouées à l'un des groupes de fichiers du schéma de partition.
Remarque: Une règle d'or pour concevoir un schéma de partitionnement est que chaque partition doit avoir un nombre de lignes dans les 10 premiers millions, disons entre 10 et 50 millions selon la largeur des lignes. Le volume de disque sur lequel se trouve la partition doit être suffisamment rapide pour effectuer une analyse d'au moins une seule partition en quelques secondes.
Systèmes de partitionnement, de partitionnement et de partage de rien
Un peu de terminologie semble ici pour lever l'ambiguïté de la discussion sur ce sujet.
Un système «rien partagé» est un système parallèle dans lequel les nœuds n'ont pas de stockage SAN partagé, mais utilisent un stockage local sur le nœud. L'exemple classique de ce type d'architecture est Teradata. Les systèmes de partage de données évoluent bien avec de très grands ensembles de données car ils n'ont pas de goulots d'étranglement d'E / S centrales. Le débit d'E / S évolue avec le nombre de nœuds du système.
Un système de «disque partagé» est un système où un ou plusieurs serveurs de base de données partagent un seul sous-système de stockage sur disque. La base de données peut être un serveur unique avec un stockage local ou attaché à un SAN, ou un cluster de serveurs attachés à un SAN partagé. Les systèmes de ce type sont limités par le débit disponible à partir du sous-système de stockage.
«Sharding» est un terme utilisé pour décrire le fractionnement d'une base de données entre plusieurs serveurs physiques dans une architecture de partage rien. Diverses plates-formes prendront plus ou moins en charge les bases de données fragmentées. Dans les cercles Teradata, le terme n'est pas utilisé car Teradata présente une image système unique transparente aux clients, même si l'architecture physique est un type de partage rien.
Les anciennes versions de SQL Server ont une prise en charge limitée du partage via des vues partitionnées distribuées. Microsoft propose désormais une version de SQL Server 2008 R2 qui prend en charge une architecture de partage de rien avec une seule image système, mais cette version n'est disponible que pour les OEM et ne peut être achetée que dans un ensemble matériel.
Pour 1 milliard de lignes
Pour 1 milliard de lignes (sauf si les lignes individuelles sont extrêmement larges), une architecture partagée ou fragmentée est confortablement dans les domaines de la surpuissance. Ce type de volume peut être géré sur un seul serveur de spécifications raisonnables s'il dispose d'un sous-système de disque suffisamment rapide.
Le disque à connexion directe locale est de loin le plus rentable en termes de prix pour les performances. Un seul contrôleur RAID SAS peut prendre plusieurs baies et plusieurs contrôleurs peuvent être installés sur un serveur. Selon la configuration, une baie SAS moderne de 24 à 25 emplacements peut offrir des milliers d'E / S par seconde ou 1 Go + / s en performances de streaming; un serveur avec plusieurs bus PCI-e et plusieurs contrôleurs peut théoriquement en gérer davantage.
Le type de performances nécessaire pour travailler avec une base de données à 1 milliard de lignes peut être obtenu assez facilement et à moindre coût avec du matériel de serveur de base et un stockage à connexion directe de ce type. Un SAN peut également être utilisé, mais vous pouvez avoir besoin de plusieurs contrôleurs SAN pour obtenir des performances équivalentes, et le matériel est susceptible d'être d'un ordre de grandeur plus cher.
En tant que recommandation générale, utilisez le stockage à connexion directe pour les applications avec des exigences d'E / S élevées, sauf si vous avez vraiment besoin d'une bonne disponibilité. Les erreurs de configuration et de contrôle des modifications sont une source beaucoup plus importante de temps d'arrêt imprévus que les pannes matérielles dans les opérations de datacenter modernes.
Les SAN peuvent vous offrir une plate-forme de stockage plus facile à gérer si vous disposez d'un large portefeuille d'applications, car ils vous offrent une gamme d'installations de gestion de stockage centralisées. Cependant, cela a un prix élevé et obtenir des performances élevées de l'infrastructure basée sur SAN est difficile et coûteux.
1 Microsoft fabrique une version parallèle de SQL Server, mais elle n'est disponible que via les canaux OEM fournis avec le matériel. Les versions disponibles sur étagère ne prennent pas en charge cette fonctionnalité.
