Escolar Documentos
Profissional Documentos
Cultura Documentos
de SQL Server
Introduction
Ce livre blanc dcrit les diffrentes technologies qui permettent la monte en charge par ajout de serveurs
( scale out ) dune application de base de donnes Microsoft SQL Server, en dtaillant les facteurs
de choix de la ou des solutions adaptes votre application. On parle galement de monte en charge
horizontale.
Copyright
Les informations contenues dans ce document reprsentent l'opinion actuelle de Microsoft Corporation
sur les points traits la date de publication. Microsoft s'adapte aux conditions fluctuantes du march et
cette opinion ne doit pas tre interprte comme un engagement de sa part. En outre, Microsoft ne
garantit pas l'exactitude des informations fournies aprs la date de publication.
qsjdlkqjs
Ce livre blanc est fourni titre informatif uniquement. LES INFORMATIONS CONTENUES DANS CE
DOCUMENT SONT FOURNIES PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU
IMPLICITE.
L'utilisateur est tenu d'observer la lgislation relative aux droits d'auteur en vigueur dans son pays. Sans
prjudice des droits accords par la lgislation en matire de droits d'auteur, aucune partie de ce
document ne peut tre reproduite, stocke, introduite dans un systme de rcupration des donnes ou
transmise quelque fin ou par quelque moyen que ce soit (lectronique, mcanique, photocopie,
enregistrement ou autre) sans l'autorisation expresse crite de Microsoft Corporation.
1
Microsoft peut dtenir des brevets, avoir dpos des demandes d'enregistrement de brevets ou tre
titulaire de marques, de droits d'auteur ou d'autres droits de proprit intellectuelle portant sur tout ou
partie des lments qui font l'objet du prsent document. Sauf stipulation expresse contraire d'un contrat
de licence crit de Microsoft, la fourniture de ce document n'a pas pour effet de vous concder une
licence sur ces brevets, marques, droits d'auteur ou autres droits de proprit intellectuelle.
Introduction ........................................................................................................................................................................................... 1
Copyright ................................................................................................................................................................................................ 1
Table des matires .............................................................................................................................................................................. 3
La monte en charge horizontale ou scale out ................................................................................................................ 4
Types de donnes ............................................................................................................................................................................... 4
Donnes de rfrence ................................................................................................................................................................... 5
Donnes d'activit .......................................................................................................................................................................... 6
Donnes de ressources................................................................................................................................................................. 6
Facteurs influant sur la monte en charge horizontale ........................................................................................................ 8
Frquence de mise jour ............................................................................................................................................................ 8
Aptitude modifier l'application .............................................................................................................................................. 8
Capacit de partitionnement des donnes ........................................................................................................................... 9
Interdpendance et couplage des donnes ...................................................................................................................... 10
Solutions de monte en charge horizontale .......................................................................................................................... 12
Bases de donnes partages volutives ............................................................................................................................. 12
Rplication d'gal gal ........................................................................................................................................................... 13
Serveurs lis et requtes distribues .................................................................................................................................... 15
Vues partitionnes distribues ............................................................................................................................................... 17
Routage dpendant des donnes ......................................................................................................................................... 18
Fdration SQL Azure ................................................................................................................................................................ 21
Conclusion........................................................................................................................................................................................... 21
Rfrences ........................................................................................................................................................................................... 22
Types de donnes
Pour choisir la meilleure stratgie de monte en charge horizontale, il est essentiel de comprendre que les
applications grent diffrents types de donnes, chacun impliquant des exigences spcifiques en termes
d'architecture de monte en charge. Avec une seule base de donnes, le plus simple est d'appliquer le
mme traitement toutes les donnes. Mais lorsque l'on commence rpartir et rpliquer les donnes
en vue d'une monte en charge horizontale, il est important de bien comprendre leur utilisation pour
4
adopter la solution la plus adapte. Dans nombre d'applications, plusieurs approches de monte en
charge horizontale sont requises en raison des multiples types de donnes impliqus. Cette section
aborde trois types de donnes et leur incidence sur les dcisions de monte en charge horizontale.
Donnes de rfrence
Les donnes de rfrence, comme leur nom l'indique, sont des informations utilises par une application
qui ne gre pas leur maintenance. Les donnes de rfrence sont relativement stables et leur validit
s'tend sur une priode prcise. Parmi les exemples reprsentatifs de donnes de rfrence, citons les
catalogues de pices utiliss par les systmes de saisie de commandes, les horaires des compagnies
ariennes ou encore les plans comptables exploits par les systmes financiers. La stabilit relative de ces
donnes s'explique par le fait qu'elles peuvent tre utilises par d'autres applications. Par consquent, des
changements trop frquents pourraient gnrer une certaine confusion. Ainsi, un prix catalogue modifi
plusieurs fois dans une mme journe risque de provoquer l'incomprhension et le mcontentement des
clients (bien sr, cela ne s'applique pas au cours des actions ni aux prix des carburants qui voluent en
permanence). Les donnes de rfrence changent habituellement intervalles fixes. Par exemple, les prix
peuvent voluer chaque jour ou chaque semaine, et les numros de compte chaque mois. Les donnes de
rfrence peuvent galement comporter un indicateur de version qui apparat dans les transactions faisant
appel ces donnes. Par exemple, un bon de commande peut faire rfrence la version du catalogue
utilise pour la cration de la commande, ce qui vite toute ambigut sur le mode de dtermination des
prix. Une entreprise peut faire le choix d'accepter plusieurs versions de donnes de rfrence pour tre
certaine que ses clients ne se basent pas sur des donnes obsoltes.
Les donnes de rfrence restant stables sur une certaine priode et souvent identifies par un numro
d'ordre qui indique la version utilise, il est possible de les copier sur de nombreux systmes diffrents,
sans risque majeur d'incohrence. Dans une batterie de serveurs Web, chaque entit doit hberger un
exemplaire du catalogue pour pouvoir rpondre rapidement aux requtes de consultation du catalogue.
Le plus souvent, les donnes de rfrence communes sont mises en cache dans la mmoire. Les donnes
de rfrence stables peuvent tre transfres vers un client intelligent pour offrir un accs rapide et la
possibilit de naviguer hors ligne. En cas de perte ou d'altration de la copie, il est facile d'en obtenir une
nouvelle. Le numro de version des donnes de rfrence permet de dterminer s'il existe une version
plus rcente disponible.
Toutes les copies des donnes de rfrence sont celles d'une copie principale. Elles ne sont donc
actualises qu'en cas de modification du fichier matre. Ce systme vite les conflits de mise jour. Ainsi,
toute rplication de capture instantane ou transactionnelle peut tre utilise pour tenir jour les donnes
de rfrence. Le dtenteur de la copie principale peut demander un service de renvoyer une copie des
donnes de rfrence aux applications qui ne les stockent pas dans une base de donnes.
En conclusion, la monte en charge horizontale des donnes de rfrence est facile mettre en uvre et
peut amliorer les performances avec un investissement minimum. D'autres types de donnes courants
prsentent les mmes caractristiques et peuvent tre traits comme les donnes de rfrence. Ainsi,
5
l'histoire ne change pour ainsi dire jamais (mme si elle se rpte souvent). C'est pourquoi, les donnes
historiques type chiffres trimestriels des ventes ou cours des actions peuvent tre traites comme des
donnes de rfrence.
Donnes d'activit
Les donnes d'activit sont des informations associes une activit particulire ou une transaction
commerciale. Par exemple, un bon de commande ou la vente d'un produit en stock gnre des donnes
lies la transaction. Ces donnes entrent dans le champ d'application d'une activit commerciale et, sauf
pour les besoins de la conservation d'un historique, elles n'ont plus grande utilit une fois l'activit
termine. Au terme de l'activit, les donnes correspondantes deviennent gnralement des donnes de
rfrence, et les mmes considrations s'appliquent en matire de monte en charge.
En gnral, les donnes d'activit prsentent de faibles exigences de simultanit. En effet, il est peu
probable que plusieurs centaines d'utilisateurs tentent d'accder au mme moment un mme bon de
commande. Bien que ce principe ne soit pas universel, il est suffisamment fiable pour servir de base la
stratgie de monte en charge des donnes d'activit. Les donnes d'activit possdent par ailleurs des
taux de mise jour raisonnablement faibles. Par exemple, lorsqu'un bon de commande est cr, il n'est
modifi que par des vnements de type changement de statut ou date de livraison, ce qui arrive
relativement rarement (plusieurs fois par jour, par rapport de nombreuses actualisations chaque
seconde). Les donnes d'activit sont gnralement faciles identifier sans ambigut et ne sont pas
souvent consultes en dehors du cadre de l'activit. Ce qui veut dire que si la monte en charge implique
la rpartition des donnes d'activit entre plusieurs bases de donnes, elles resteront faciles trouver. Une
transaction commerciale devant accder un bon de commande connat le plus souvent son numro. Par
consquent, partitionner les bons de commandes par plage de numro permet d'identifier facilement la
base de donnes qui contient le bon de commande recherch.
Les donnes d'activit entrent souvent dans le champ d'application d'un autre objet de donnes. Il peut
donc tre judicieux de stocker toutes les commandes passes par un client dans la mme base de
donnes avec les autres informations relatives ce client, si ce mode d'accs aux commandes est le plus
courant. De mme, vous pouvez stocker tous les bons de commandes d'un fournisseur dans la base de
donnes de ce fournisseur.
En conclusion, il est relativement facile de rpliquer des donnes d'activit lorsque ncessaire et, dans de
nombreux cas, il est pratique de partitionner les donnes entre plusieurs bases de donnes pour les
besoins d'une monte en charge horizontale. La mthode de monte en charge horizontale retenir pour
les donnes d'activit dpend de l'utilisation des donnes, comme l'explique la section Facteurs influant
sur la monte en charge horizontale .
Donnes de ressources
6
Les donnes relatives aux ressources sont les informations centrales dont dpend votre entreprise :
inventaire, informations comptables, fichier de clientle, etc. Une perte de donnes de ressources peut
purement et simplement stopper votre activit. Les bases de donnes utilisent de nombreuses
fonctionnalits pour garantir l'intgrit et la haute disponibilit des donnes afin que ces donnes
sensibles soient constamment disponibles. Elles imposent gnralement de grandes exigences en matire
de simultanit car de nombreuses applications et utilisateurs diffrents doivent y accder. Elles possdent
galement un taux de mise jour lev. La quantit disponible pour un article ou le solde d'un compte
sont des valeurs qui changent plusieurs fois par jour. Si le grand nombre de mises jour simultanes fait
de la monte en charge horizontale une option trs intressante en termes de performances, le besoin
d'intgrit et de haute disponibilit de ces donnes implique bien souvent une monte en charge
verticale.
Les donnes relatives aux ressources ne reprsentent en gnral que les donnes actives. Les comptes
inactifs et les pices dont la fabrication n'est pas continue, par exemple, sont souvent conservs dans des
tableaux historiques relativement statiques, o ils deviennent de fait des donnes de rfrence. Des
captures instantanes des donnes de ressources peuvent tre enregistres pour la cration de rapports
ou d'un historique ; il s'agit l aussi de donnes de rfrence. Les exigences d'intgrit et de haute
disponibilit inhrentes ce type de donnes perdent de leur importance lorsque ces informations
deviennent des donnes de rfrence. Cette conversion en donnes de rfrence prserve la pertinence
des donnes de ressources, limite leur volume et rduit la ncessit d'une monte en charge.
rpartir les donnes de ressources par application, moins de modifier l'application. Vous pouvez monter
en charge les donnes de rfrence et d'activit de manire horizontale, ou partitionner les donnes de
ressources de telle sorte que la monte en charge reste possible si les donnes de ressources sont
troitement couples. Mais certaines options de monte en charge horizontale ncessitant la rpartition
des donnes peuvent imposer une redfinition de l'architecture de l'application pour l'adapter la
nouvelle architecture des donnes. Comme indiqu dans la section sur la modification des applications,
concevoir le modle de donnes de manire ce qu'il puisse tre subdivis par la suite est une pratique
suivre pour laborer une nouvelle application.
11
12
Bien entendu, une base de donnes qui n'volue jamais offre un intrt limit. Par consquent, pour
mettre jour la base de donnes, toutes les instances de SQL Server dtachent la base de donnes, une
instance la lie en mode lecture-criture et la base de donnes peut tre actualise avec des donnes
jour. Cette opration peut prendre un certain temps si elle implique la modification d'un grand nombre de
donnes. Si le SAN possde suffisamment d'espace libre, il peut tre intressant de grer deux bases de
donnes de manire mettre jour l'une pendant que l'autre est utilise. Pour plus d'informations,
reportez-vous aux manuels en ligne sur SQL Server et aux articles indiqus la section Rfrences .
La limite de huit moteurs attachs une seule base de donnes n'est pas d'ordre technique. Elle a t
dtermine suite la ralisation de tests. Les prochaines versions pourront vraisemblablement prendre en
charge plus de huit moteurs. Puisque l'on n'crit jamais dans la base de donnes et que le maximum de
donnes possible est mis en cache, le taux rel d'E/S disque est relativement bas, mme avec huit moteurs
de base de donnes assumant une lourde charge.
Nombre d'applications de base de donnes les plus exigeantes fonctionnent parfaitement en lecture seule.
La charge de travail d'un entrept de donnes consiste en un nombre relativement modr de requtes
vastes et complexes concernant des donnes historiques raisonnablement statiques. La frquence de mise
jour de la plupart des entrepts de donnes est quotidienne, voire hebdomadaire. Ainsi, il est simple
d'utiliser l'entrept en lecture seule lorsqu'il fonctionne. Une base de donnes partage volutive permet
galement de rsoudre un problme courant propre aux entrepts de donnes : un utilisateur crit une
requte qui monopolise toutes les ressources de la base de donnes durant des heures. Lorsque cette
requte s'excute sur l'un des moteurs de base de donnes, les autres moteurs restent disponibles pour
traiter les requtes, ce qui minimise l'impact des requtes infernales .
Les bases de donnes partages volutives ne sont utiles que si la frquence de mise jour est trs faible,
car la base de donnes ne peut pas tre actualise tant qu'elle est partage. Les bases de donnes
partages volutives ne ncessitent aucun changement au niveau de l'application, sous rserve que celleci ne tente pas de mettre jour la base de donnes. La base de donnes est monte en charge
horizontalement sans modification. Par consquent, les facteurs de partitionnement et de couplage
n'influencent pas la dcision d'utiliser les bases de donnes partages volutives. En rsum, les bases de
donnes partages volutives sont utiles dans des applications type entrepts de donnes, mini-Data
Warehouses et bases de donnes de cration de rapports o la frquence des mises jour de donnes
peut tre limite des changements priodiques par lots. Si ce schma de mise jour est acceptable pour
l'application, les bases de donnes partages volutives constituent la mthode de monte en charge
horizontale privilgie, car elles sont faciles mettre en uvre et ncessitent peu de changements au
niveau de l'application.
exemplaires pour que chaque moteur tienne jour sa propre copie. Cette option offre la fois la monte
en charge horizontale et la mise jour des donnes. La rplication permet de propager les changements
vers toutes les copies des donnes. La Figure 2 prsente l'utilisation de la rplication d'gal gal comme
solution de monte en charge horizontale.
uniques, voire des portions de tables. Elle est donc intressante pour une monte en charge horizontale
de parties de donnes d'une application. Par exemple, des donnes de rfrence (catalogues ou tarifs, par
exemple) peuvent tre rpliques pour optimiser la monte en charge, mme si les donnes de ressources
ne bnficient pas de cette monte en charge. La rplication est galement utile en association avec
d'autres solutions de monte en charge horizontale. Si les donnes d'activit sont montes en charge
horizontalement par rpartition dans diffrentes bases de donnes, il peut tre intressant de rpliquer les
donnes de rfrence utilises par les donnes d'activit vers toutes les bases de donnes d'activit. En
gnral, la rplication est l'une des solutions de monte en charge horizontale les plus simples et les plus
largement applicables dans SQL Server.
Reportez-vous la page sur la topologie de rplication d'gal gal pour effectuer des tches courantes
de configuration (ajout et suppression de nuds, ajout de connexions entre des nuds existants). Cet
outil d'interface graphique convivial et intuitif facilite la cration et la maintenance de la topologie de
rplication d'gal gal.
La rplication d'gal gal dans SQL Server offre notamment la possibilit de reprer les conflits au sein
d'une topologie d'gal gal. Cette option permet d'viter les problmes causs par des conflits non
dtects, notamment des incohrences dans le comportement d'une application ou la perte de mises
jour. En activant cette option, un changement conflictuel est trait par dfaut comme une erreur critique
qui met en chec l'agent de distribution.
15
Les serveurs lis sont particulirement utiles dans un environnement o les donnes peuvent tre
subdivises par secteur fonctionnel parmi des bases de donnes faisant trs peu appel au couplage. Les
contraintes d'intgrit rfrentielle ne sont pas compatibles avec les tables distantes et les relations entre
donnes locales et distantes doivent donc tre minimises. Les requtes distantes sont considrablement
plus coteuses que les requtes locales. Les jonctions entre tables locales et distantes peuvent elles aussi
coter trs cher et les mises jour des tables distantes ncessitent des transactions distribues. Par
consquent, la monte en charge horizontale d'une base de donnes avec des serveurs lis ncessite une
conception minutieuse de la base de donnes de manire minimiser l'accs aux donnes distantes. Si les
applications utilisent des lots de donnes prsentant peu de couplages et si les requtes envoyes ces
lots sont relativement peu nombreuses, il est possible de rpartir les lots de donnes entre des bases de
donnes pour optimiser la monte en charge horizontale. S'il existe des points chauds o plusieurs
applications utilisant diffrents lots de donnes exploitent certaines tables de manire intensive, vous
pouvez recourir la rplication pour rpondre au mieux aux requtes impliquant ces tables locales.
Les bases de donnes montes en charge horizontalement doivent galement tre conues pour que
l'essentiel des donnes utilises par une application soit stock dans une mme base de donnes. Par
exemple, si plusieurs applications utilisent des donnes relatives aux clients et aux commandes dans la
plupart de leurs requtes, la sparation des donnes clients et commandes dans des bases de donnes
distinctes n'aura pas grand intrt (mme si les donnes sont librement couples). En effet, quelle que soit
la base de donnes ouverte par une application, elle accde en permanence aux donnes distance.
Toutefois, si certaines applications accdent aux donnes clients de manire quasi exclusive tandis que
d'autres se consacrent entirement ou presque aux donnes de commandes, ce type de sparation peut
s'avrer efficace. L encore, si quelques requtes font une utilisation intensive des deux bases de donnes,
la rplication peut permettre de rduire le trafic rseau. Par exemple, si des commandes requirent un
numro de client valide et si chaque commande inclut un nom de client, les colonnes Numro et Nom du
client de la base de donnes client peuvent tre rpliques dans la base de donnes des commandes.
Tout comme la rplication, les serveurs lis sont de prcieux outils dans certaines autres solutions de
monte en charge horizontale. Dans toute base de donnes distribue, un certain nombre de requtes
doit franchir les limites des bases de donnes. Les serveurs lis offrent un moyen simple de prendre en
charge ces requtes.
Les serveurs lis ont galement leur utilit en cas de sparation de donnes par type. Par exemple, si
toutes les informations historiques de plus de 60 jours sont transfres vers d'autres bases de donnes, la
mise en uvre d'un serveur li peut permettre l'application de grer un petit nombre de requtes qui
accdent aux donnes de rfrence historiques comme si elles taient stockes localement. Grce cette
stratgie, le traitement des donnes de rfrence est efficacement transfr vers un matriel ddi, sans
affecter les applications qui les exploitent. Les applications qui accdent frquemment aux donnes
historiques peuvent s'excuter sur les systmes historiques et atteindre les donnes actives uniquement
lorsque c'est ncessaire.
La frquence de mise jour a un impact modr sur une solution de monte en charge horizontale par
serveur li, sous rserve que les mises jour ne couvrent pas les bases de donnes. Par consquent, une
16
validation en deux phases n'est pas ncessaire. Ce qui signifie qu'une solution de serveur li est efficace
pour certaines applications de traitement des transactions en ligne (OLTP). Par ailleurs, les serveurs lis
ncessitent peu ou pas de changement au niveau applicatif. C'est pourquoi, ils conviennent tout fait aux
applications existantes. Le partitionnement des donnes par valeur cl n'est gnralement pas utilis dans
les mises en uvre de serveurs lis. Il n'entre donc pas en ligne de compte. Le principal facteur pour
dterminer si la monte en charge horizontale par serveur li constitue une solution approprie est le
couplage des donnes. Si le degr de couplage est lev, la surcharge engendre par les requtes
distribues annulera les avantages de la monte en charge en termes de performances. Une bonne
comprhension des relations entre les donnes et de l'utilisation des donnes d'application est essentielle
pour savoir si les serveurs lis reprsentent une solution viable.
hbergeant les partitions. Une proportion leve de requtes locales implique gnralement une
conception minutieuse du schma de partitionnement, mais aussi la modification de l'application en vue
de tirer pleinement parti du partitionnement. Ainsi, mme si les DPV ont t conues pour assurer une
monte en charge horizontale transparente, dans bien des cas, la modification des applications reste
ncessaire. Trouver un schma de partitionnement adapt plusieurs applications diffrentes n'est pas
chose facile. C'est pourquoi, les DPV sont gnralement plus intressants lorsqu'un nombre limit
d'applications associes exploite la base de donnes partitionne. Pour limiter le nombre d'applications
qui accdent un modle DPV, il suffit de sparer les donnes par application et de les partitionner par
valeur cl. En procdant ainsi, il est probable que seules quelques bases de donnes soient suffisamment
volumineuses pour bnficier des DPV et qu'il en rsulte une combinaison de schmas partitionns et non
partitionns.
Les DPV sont particulirement performantes dans les applications aux mises jour frquentes, car la
plupart des transactions d'actualisation affectent un petit nombre de lignes et peuvent donc s'excuter
dans une base de donnes unique. Les DPV reprsentent ainsi la solution de monte en charge
horizontale la plus efficace en cas de mises jour frquentes. En thorie, une mise en uvre de DPV ne
devrait ncessiter aucun changement d'application, car les montes en charge horizontales sont gres
par SQL Server et transparentes au niveau de l'application. Dans la ralit, certains changements peuvent
tre requis dans l'application pour tirer pleinement parti de la monte en charge. Le facteur qui dtermine
le choix de mettre en uvre des DPV est la capacit de partitionnement des donnes. En l'absence de cls
de partitionnement efficaces, capables de partitionner les donnes de manire homogne et de minimiser
les requtes entre les partitions, les DPV ne sont d'aucun secours. Choisir les cls de partitionnement
adaptes requiert un important travail d'analyse et de planification en amont. Le couplage des donnes
n'a que peu d'impact sur une vue partitionne, mais si les bases de donnes contiennent de nombreuses
tables non partitionnes, un taux de couplage lev peut entraver la bonne distribution des donnes.
Les applications OLTP sont souvent les meilleures candidates aux vues partitionnes distribues car elles
allient d'importants volumes de donnes des frquences de mise jour leves. D'une manire gnrale,
une vue partitionne demande un effort de gestion beaucoup plus consquent que si les donnes se
trouvaient dans une seule table. Les oprations de sauvegarde et de restauration doivent pouvoir
synchroniser toutes les partitions d'une table pour restaurer un tat cohrent, par exemple. Cet effort de
gestion supplmentaire, associ celui relativement important de la mise en place d'une solution DPV,
explique principalement le faible nombre d'applications exploitant les DPV comme solution de monte en
charge horizontale.
d'une requte, plus elle dispose d'informations sur les donnes, plus sa dcision pourra tre judicieuse. Le
DDR peut galement prendre en charge des options non gres directement par SQL Server actuellement.
Par exemple, si plusieurs copies des mmes donnes sont disponibles, le DDR peut distribuer des
commandes SELECT entre ces copies, tout en dirigeant les mises jour vers la copie principale. La Figure 4
prsente l'utilisation du routage dpendant des donnes comme solution de monte en charge
horizontale.
(nom, SID Windows, etc.) vers un ID client. Dernire pice du puzzle : une table charge de mapper les ID
clients vers le serveur de base de donnes sur lequel l'entit client est enregistre. Une fois ce mcanisme
en place, une couche d'accs aux donnes (dans l'application ou dans une application intermdiaire) peut
soumettre une API permettant l'application d'accder aux donnes stockes dans une entit client
donne. Les requtes sont achemines en fonction des donnes transmises par la requte, d'o le nom de
routage dpendant des donnes .
ce stade, il est logique de se demander comment lancer une recherche dans plusieurs centaines de
bases de donnes pour obtenir des donnes de rsum ou trouver toutes les commandes. La rponse est
simple : Ne le faites pas. Dans le cadre de la conception d'une application DDR, vous devez mettre en
place les installations ncessaires pour grer ces requtes. Une approche type consiste rpliquer des
donnes de rsum de chaque commande dans une base de donnes de commandes en les associant
un ID client, de telle sorte que la plupart des requtes de commande puissent accder ces donnes de
rsum. Si une application requiert les dtails d'une commande, elle peut utiliser l'ID client des donnes
de rsum pour retrouver la commande. Les donnes de rsum sont aussi couramment charges dans un
entrept ou dans des bases de donnes de cration de rapports pour diffrentes utilisations (gnration
de rapports, exploration de donnes, analyse de donnes, etc.).
Bien qu'il ne soit pas trs courant d'avoir recours au DDR pour raliser des montes en charge
horizontales de milliers de serveurs de bases de donnes, l'utilisation de ces mmes principes pour monter
en charge des dizaines de serveurs de bases de donnes peut s'avrer viable pour de nombreuses
applications. La relocalisation des donnes, la gestion de la rplication ou l'extraction des donnes de
rsum rendent cette solution relativement complexe grer. Mais pour l'essentiel, ces tches sont
rptitives et peuvent tre automatises.
La solution DDR a t pense pour des volumes de transactions consquents. Elle s'impose donc tout
naturellement pour les applications avec une frquence de mise jour leve. Le DDR a besoin d'une
couche de donnes qui puisse localiser les entits de donnes et y accder depuis les bases de donnes
o elles sont stockes. Ainsi, le DDR est la solution la plus adapte pour une nouvelle application. Le
recours une application intermdiaire pour grer le routage des donnes rduira le nombre de
changements apports au code de l'application. Mais l'adaptation d'une application existante au DDR
ncessite des modifications importantes. Les exigences lies la capacit de partitionnement des donnes
sont extrmement leves. En effet, cette solution ne fonctionne que si les donnes sont partitionnes et
qu'une cl de partitionnement permette de reprer toutes les entits de donnes. Un faible degr de
couplage des donnes peut galement tre requis, car il est gnralement impossible de partitionner la
totalit de la base de donnes sur une seule cl. Dans notre exemple de saisie de commande, le
partitionnement de l'inventaire par ID client n'aurait aucun intrt. Les donnes d'inventaire devraient tre
isoles dans leur propre ensemble de serveurs de bases de donnes, voire partitionnes par numro de
catalogue. En gnral, le DDR est l'une des mthodes les plus efficaces pour monter en charge
horizontalement une base de donnes, mais c'est aussi l'une des plus difficiles mettre en uvre. Elle est
souvent plus approprie dans les cas de reconception ou de modification d'applications. Le DDR convient
galement la monte en charge horizontale partielle d'une application. Par exemple, vous pouvez
appliquer le DDR votre base de donnes de commandes et utiliser une autre stratgie de monte en
20
charge horizontale pour le reste des donnes. Vous pouvez aussi opter pour une monte en charge
verticale des autres donnes si l'extraction des donnes de commande laisse un volume de donnes
suffisamment modr pour tre gr ainsi.
Conclusion
Retenons de cette discussion sur la monte en charge horizontale de SQL Server que les applications
contiennent diffrents types de donnes. Une solution efficace de monte en charge peut intgrer des
approches diffrentes pour chaque type de donnes. Les donnes de rfrence peuvent tre rpliques et
mises en cache plusieurs emplacements ; les donnes historiques peuvent tre exposes via des
requtes distribues dans un systme de stockage conomique de grande capacit ; les donnes d'activit
peuvent tre partitionnes sur plusieurs serveurs ; enfin, les donnes de ressources peuvent tre rparties
par application.
Le choix d'une solution de monte en charge horizontale repose sur un certain nombre de facteurs. Le
Tableau 1 rcapitule l'importance de ces facteurs pour chaque solution.
21
Aptitude modifier
l'application
Capacit de
partitionnement
des donnes
Couplage des
donnes
Bases de donnes
Lecture seule.
partages volutives
Sans importance.
Sans importance.
Sans importance.
Sans importance.
Serveurs lis
Certains changements
Trs important.
peuvent tre requis.
Impact minime.
Changements
Trs important.
importants possibles.
Un faible taux de
couplage peut tre
utile pour certaines
applications.
Rappelons que certaines architectures de monte en charge horizontale peuvent incorporer plusieurs
solutions. La rplication et les serveurs lis font gnralement partie de ce type d'architecture.
Avec une bonne comprhension des donnes, des besoins et des contraintes applicatives, il est possible
de dvelopper une solution SQL Server efficace et capable de prendre en charge tout type de monte en
charge horizontale. Mme si la monte en charge horizontale n'est pas une exigence initiale pour une
application, considrer cette volution ds la conception peut se rvler payant par la suite, lorsque
l'application et votre activit se dvelopperont.
Si vous avez besoin d'une solution de monte en charge horizontale d'envergure pour des applications de
bases de donnes en mode cloud, la fdration SQL Azure introduit le concept d'informatique souple qui
offre des possibilits de monte en charge horizontale vers des centaines de nuds mais aussi des
possibilits de rgression.
Rfrences
Site Web SQL Server : http://www.microsoft.com/sqlserver/en/us/default.aspx
Base de donnes partage volutive
22
Serveurs lis
Monte en charge horizontale de SQL Server par le routage dpendant des donnes :
http://technet.microsoft.com/en-us/library/cc966448.aspx
Ce livre blanc vous a-t-il t utile ? N'hsitez pas nous faire part de vos commentaires. Sur une chelle
allant de 1 (mauvais) 5 (excellent), quelle note attribueriez-vous ce livre blanc et pourquoi ? Par
exemple :
Lui attribuez-vous une note leve pour ses exemples utiles, ses captures d'cran pertinentes ou sa
clart rdactionnelle ?
Lui attribuez-vous une mauvaise note cause de ses exemples insuffisants, ses captures d'cran
floues ou son style confus ?
Vos commentaires nous aideront amliorer la qualit de nos livres blancs.
Envoyez vos commentaires.
23