Monte en charge par ajout de serveurs

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.

2012 Microsoft Corporation. Tous droits rservs.

Microsoft, SQL Server et SQL Azure sont des marques de Microsoft.

Table des matires

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

La monte en charge horizontale ou scale out

L'volutivit est la capacit d'une application exploiter efficacement davantage de ressources pour faire
face une charge de travail plus importante. Par exemple, une application utilise par quatre personnes
sur un systme dot d'un seul processeur peut desservir 15 utilisateurs sur un systme quatre
processeurs. On parle alors d'une application volutive. Si l'ajout de processeurs n'augmente pas le
nombre d'utilisateurs desservis (par exemple, avec une application thread unique), l'application n'est pas
volutive.
Il existe deux types d'volutivit : la monte en charge verticale ( scale up ) et la monte en charge
horizontale ( scale out ). La monte en charge verticale consiste voluer vers un serveur plus
volumineux et plus puissant, par exemple en passant d'un systme quatre processeurs un systme
dot de 128 processeurs. Pour une base de donnes, c'est la mthode d'volution la plus couramment
utilise. Lorsque votre base de donnes n'a plus suffisamment de ressources sur le matriel utilis, il suffit
de vous procurer un systme plus important, quip de davantage de processeurs et de mmoire. Point
positif de la monte en charge verticale, elle ne ncessite pas de modifications significatives dans la base
de donnes. En gnral, il suffit d'installer la base de donnes sur un systme plus puissant et de continuer
l'utiliser normalement, l'augmentation de puissance permettant de grer une charge de travail plus
importante. La monte en charge horizontale consiste dvelopper plusieurs serveurs au lieu de disposer
d'un seul serveur plus consquent. Cette dmarche est intressante du point de vue du cot initial du
matriel : huit serveurs quips de quatre processeurs reviennent gnralement moins cher qu'un seul
serveur de 32 processeurs. Mais cet avantage est souvent balay par les frais de licence et de
maintenance. Dans certains cas, la redondance d'une monte en charge horizontale peut galement
s'avrer utile en termes de disponibilit.
D'innombrables articles, ouvrages et livres blancs ont dj t publis sur les technologies de monte en
charge horizontale de SQL Server. Le prsent livre blanc sintresse plus particulirement aux facteurs
prendre en considration pour choisir la solution la plus pertinente pour votre application. Pour plus
d'informations sur les technologies de monte en charge horizontale, reportez-vous la section
Rfrences .
Les nouvelles gnrations des technologies SQL Server protgent encore davantage votre infrastructure
de donnes, avec les niveaux de service et les performances dont vous avez besoin, en particulier pour les
charges de travail critiques, pour un prix comptitif. En choisissant Microsoft, non seulement vous obtenez
une plateforme prouve, mais surtout vous avez face vous un partenaire de confiance et un rseau
reconnu de fournisseurs expriments.

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.

Facteurs influant sur la monte en charge horizontale

Nous venons de voir les types de donnes stockes dans des systmes de base de donnes. Intressonsnous prsent aux caractristiques d'utilisation qui vont influer sur le choix de la technologie de monte
en charge pour ces donnes. SQL Server prend en charge plusieurs technologies de monte en charge
horizontale. Pour choisir la plus adapte, il faut avant tout tudier les particularits des donnes et de
l'application concernes.

Frquence de mise jour

Certaines donnes sont actualises trs frquemment. C'est le cas des donnes de journaux issues des
serveurs Web et des mesures d'instruments mises par les machines d'un atelier (remarque : ces donnes
sont plus concernes par des processus d'insertion que de mise jour, mais pour les besoins de notre
dmonstration, nous considrerons que c'est la mme chose). D'autres donnes sont rarement, voire
jamais, mises jour et peuvent tre considres comme des informations essentiellement en lecture seule.
C'est le cas des donnes historiques telles que les chiffres trimestriels des ventes. Les informations
conserves dans des entrepts de donnes sont gnralement mises jour par lots en dehors des
horaires de travail, mais leur statut passe en lecture seule lorsque l'entrept est utilis.
Il est assez difficile de rpliquer efficacement les donnes mises jour trs frquemment car la surcharge
impose par la rplication des actualisations limite l'volutivit des copies rpliques. Autrement dit, la
base de donnes passe tellement de temps rpliquer les changements que ses performances globales
peuvent devenir infrieures ce qu'elles seraient si les donnes taient conserves dans une base de
donnes unique. Il est donc essentiel de connatre le taux de mise jour de vos donnes lorsque vous
envisagez une rplication pour une monte en charge horizontale.
Une base de donnes avec un taux de mise jour trs faible est facile rpliquer. Dans ce cas, la
rplication peut tre une stratgie adapte de monte en charge horizontale. Si le taux de mise jour est
suffisamment modr pour que la base de donnes puisse tre considre en lecture seule la plupart du
temps, le choix de la base de donnes partage volutive prend tout son intrt. Cette option sera
dtaille plus loin dans ce document.

Aptitude modifier l'application

Bien que ce ne soit pas une caractristique des donnes au sens strict, le degr de flexibilit dont vous
disposez pour reconfigurer l'application peut avoir un impact considrable sur les stratgies de monte en
charge horizontale adaptes vos besoins. Certaines de ces stratgies ne requirent aucun changement
dans l'application ; certaines demandent des modifications mineures dans les requtes et les procdures
stockes. D'autres enfin peuvent ncessiter de repenser entirement le fonctionnement de l'application.
Naturellement, la flexibilit est maximale si vous partez d'une application entirement nouvelle. C'est
8

pourquoi, il est recommand d'anticiper la monte en charge ds la phase de conception d'une

application, mme si cette opration est inutile au dpart. En effet, apporter des modifications une fois
que l'application est en production et manque de ressources s'avre beaucoup plus compliqu que
l'intgration initiale d'une option de monte en charge horizontale. Les applications packages ainsi que
certaines applications existantes peuvent tre impossibles modifier. Dans ce cas, la monte en charge
horizontale doit tre absolument transparente pour le code de l'application.

Capacit de partitionnement des donnes

L'une des mthodes les plus efficaces pour monter les donnes en charge de manire horizontale consiste
les partitionner entre plusieurs bases de donnes de telle sorte que chaque serveur gre une partie des
donnes. Bien qu'assez vidente, cette technique n'est pas efficace pour toutes les donnes. De plus,
lorsqu'elle est applicable, le mode de partitionnement joue un rle important sur les performances.
Pour illustrer les effets du partitionnement, voyons comment une base de donnes de commandes
pourrait tre partitionne. Les commandes peuvent tre partitionnes en fonction des produits
commands : livres dans une base de donnes, vtements dans une autre, etc. Outre les questions
courantes (Comment traiter une commande contenant la fois des livres et des vtements ?), ce modle
ne donne pas de bons rsultats si la majorit des requtes relie les commandes aux clients, car cette
jonction ncessite de rechercher les commandes correspondantes dans toutes les bases de donnes de
commandes.
Autre mthode de partitionnement d'une base de donnes de commandes : subdiviser les commandes
par plages de numros. Cette mthode peut tre intressante si les commandes sont majoritairement
consultes par numro plutt que par emplacement. Mais si les jonctions avec la table des clients sont
nombreuses, cette technique impose aussi de distribuer les jonctions. La seule solution ce problme
consisterait partitionner la base de donnes des commandes par numro de client, de telle sorte que la
base de donnes de commandes utiliser pour un client particulier soit toujours connue. Cette technique
est particulirement efficace si la base de donnes des clients est partitionne, et si les commandes de
chaque client sont stockes dans la mme base de donnes que le client. D'autres informations doivent
tre jointes aux donnes de commandes et, si possible, elles doivent tre partitionnes selon le mme
modle pour viter la distribution de jonctions. Il peut s'agir de donnes de rfrence (descriptions
d'article, par exemple) pouvant tre rpliques vers toutes les bases de donnes de commandes pour
liminer la distribution de jonctions avec la base de donnes d'inventaire.
Si les donnes d'application peuvent tre rparties entre plusieurs bases de donnes et si la puissance de
traitement supplmentaire fournie par les diffrents serveurs dpasse les cots de communication
imputables au regroupement des rsultats, les donnes peuvent tre partitionnes. Il est impossible de
partitionner efficacement toutes les donnes d'application, et il est crucial de bien choisir le modle de
partitionnement pour garantir l'efficacit de la monte en charge horizontale des donnes partitionnes.

Interdpendance et couplage des donnes

Une autre mthode pour distribuer les donnes en vue d'une monte en charge horizontale consiste les
subdiviser en fonction de leur utilisation. Si des parties de la base de donnes sont exploites par
diffrentes applications, il peut tre intressant de la subdiviser la frontire des applications, de faon
ce que chacune dispose d'un traitement adapt aux donnes qu'elle utilise. Cette procdure est efficace
lorsque les donnes exploites par les diffrentes applications peuvent tre segmentes pour permettre
un traitement spcifique la base de donnes sans que l'interdpendance des donnes ne pnalise le
trafic rseau. titre d'exemple extrme, si une base de donnes de commandes est subdivise de telle
sorte que les lignes de commande se trouvent dans une base de donnes tandis que tous les en-ttes de
commande sont stocks dans une autre, chaque requte d'accs aux commandes devra effectuer une
jonction distribue entre les deux bases de donnes. Le trafic rseau gnr par les jonctions distribues
annulera tous les avantages de la rpartition des donnes.
Le meilleur moyen de dterminer comment subdiviser une base de donnes consiste tudier
soigneusement le modle de donnes. Dans un schma entit-relation, les relations reprsentent la fois
les chemins de jonction et les contraintes d'intgrit rfrentielles. Les jonctions et les contraintes sont
coteuses mettre en uvre dans des bases de donnes distribues. La base de donnes ne mettra pas
en application de contraintes rfrentielles entre les bases de donnes. Par consquent, si des tables
associes sont rparties entre plusieurs bases de donnes, la contrainte devra tre ignore ou applique
par un dclencheur ou par l'application. Pour viter ces problmes, recherchez les lots de donnes
associes dans votre modle de donnes. Ce sont des groupes de tables prsentant peu ou pas de liens
avec le reste du modle de donnes. Dans une base de donnes de saisies de commandes, on trouve
gnralement peu de relations entre les tables de clients et les tables d'inventaire, par exemple.
Une fois que vous avez slectionn les groupes de tables qui peuvent tre isols dans des bases de
donnes diffrentes sans trop de problmes d'intgrit rfrentielle, il convient d'tudier les modles de
mise jour. Si la rpartition de vos donnes entre les bases de donnes cre un grand nombre de
transactions distribues couvrant les bases de donnes, la surcharge de mise jour impose par la
validation en deux phases peut annuler certains avantages de la monte en charge horizontale.
Le dernier facteur considrer pour le couplage de donnes est le mode de prise en charge des tables
partages. Un certain nombre de tables est accd par plusieurs applications. Il est donc important,
lorsque vous rpartissez les donnes, de dcider de l'emplacement des tables partages. Parfois, une table
peut tre lue par plusieurs applications, mais mise jour par une seule. Il est donc plus logique de la situer
au mme emplacement que l'application de mise jour. Les problmes d'intgrit relationnelle et de
distribution voqus plus haut peuvent galement influencer le choix de l'emplacement de la table
partage. Si la table est relativement petite et utilise intensivement par plusieurs applications, il est utile
de la rpliquer dans plusieurs bases de donnes. C'est la mthode la plus simple si la table est mise jour
par une seule application, car la rplication transactionnelle depuis la copie principale peut alors tre
utilise pour maintenir jour les autres copies.
Les donnes de ressources sont souvent extrmement interdpendantes, et prsentent de nombreuses
contraintes d'intgrit, ce qui induit un niveau lev de couplage. Dans certains cas, cela empche de
10

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

Solutions de monte en charge horizontale

prsent que nous avons dfini les facteurs qui interviennent dans le choix d'une solution de monte en
charge pour SQL Server, nous allons tudier chacune de ces solutions et les facteurs en faveur de chacune.
Ce livre blanc n'entre pas dans le dtail des solutions de monte en charge horizontale. Pour plus
d'informations, reportez-vous aux articles mentionns la section Rfrences .

Bases de donnes partages volutives

La solution de monte en charge horizontale la plus facile mettre en uvre dans SQL Server est celle des
bases de donnes partages volutives. Vous crez une base de donnes sur un rseau SAN et huit
instances de SQL Server fonctionnant sur diffrents serveurs lis la base de donnes pour commencer
prendre en charge les requtes. Il s'agit l de la solution classique de disque partag o la puissance
de traitement est monte en charge de manire horizontale, mais o une seule image disque des donnes
est utilise. ce stade, les experts de SQL Server se demandent : Et les verrouillages ? Je croyais que
chaque instance de SQL Server conservait ses propres verrouillages dans sa mmoire. C'est bien le cas.
Chaque instance conserve ses propres verrouillages de base de donnes, et aucune ne connat ceux des
autres instances. Le seul moyen de faire marcher ce systme est de n'avoir aucun verrouillage. Les bases
de donnes partages volutives ne fonctionnent alors que si elles sont relies une base de donnes en
lecture seule. Ce qui signifie que les bases de donnes partages volutives sont trs utiles pour les
entrepts de donnes ou les bases de donnes de cration de rapports, mais qu'elles ne conviennent pas
aux applications qui mettent jour des donnes. Revenons aux caractristiques des donnes : les bases de
donnes partages volutives ne fonctionnent que si la frquence de mise jour est nulle. Ces donnes
sont, par dfinition, historiques. Ce sont donc toutes des donnes de rfrence. La Figure 1 prsente
l'utilisation de bases de donnes partages volutives comme solution de monte en charge horizontale.

Figure 1. Base de donnes partage volutive

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.

Rplication d'gal gal

Pour la monte en charge horizontale des donnes devant tre mises jour une frquence relativement
modre, on obtiendra souvent les meilleurs rsultats par la rplication. Au lieu que plusieurs moteurs de
base de donnes accdent une mme copie de la base de donnes, celle-ci est disponible en plusieurs
13

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.

Figure 2. Rplication d'gal gal

La rplication d'gal gal dans SQL Server propage les changements apports une copie des donnes
vers toutes les autres copies. Cette opration ne rsout pas les conflits. Elle n'est donc prconise que
dans les configurations o une seule copie d'un lment de donnes est mise jour. Par exemple, si la
rplication d'gal gal est choisie pour grer l'inventaire d'une chane de magasins d'alimentation, seul
le point de vente dtenteur d'une entre d'inventaire serait habilit mettre jour cette entre. Dans ce
cas, tous les magasins pourraient consulter l'inventaire des autres, mais ne pourraient modifier que leur
propre stock.
Les rgles autorisant uniquement le dtenteur d'un lment de donnes le modifier sont appeles
grance des donnes . La grance est une mthode extrmement efficace pour viter les conflits de
mise jour des donnes. Dans les cas o la grance des donnes n'est pas envisageable, une rplication
de fusion peut permettre de grer les conflits. Cette mthode implique une surcharge plus importante que
la rplication d'gal gal, car elle doit grer des conflits. On prfrera donc la rplication d'gal gal
dans les cas o les conflits peuvent tre vits. La rplication d'gal gal doit tre configure partir de
chaque copie de la base de donnes vers chaque autre copie, de sorte que la gestion de cette structure
peut s'avrer fastidieuse lorsque de nombreuses bases de donnes sont impliques. La solution la plus
simple et la plus efficace consiste utiliser une seule copie principale avec rplication transactionnelle
pour maintenir les autres copies jour, sous rserve que les mises jour de la base de donnes puissent
tre limites une seule copie de la base de donnes.
La rplication est une solution de monte en charge horizontale satisfaisante pour les donnes dont la
frquence de mise jour est modre. La grance des donnes peut liminer les conflits de mise jour et
permettre de recourir une rplication d'gal gal. Si besoin, la rplication peut tre applique toutes
les donnes d'une mme base de donnes. Elle est donc utile lorsque le partitionnement des donnes est
compliqu ou que le degr de couplage est important. Dans la plupart des cas, elle ne ncessite pas de
changement au niveau de l'application. Elle peut donc tre utilise pour faciliter la monte en charge
horizontale des applications existantes. La rplication peut donner de bons rsultats avec des tables
14

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.

Serveurs lis et requtes distribues

SQL Server est capable d'interroger des objets de bases de donnes distantes comme s'il s'agissait de
bases locales. Ainsi, une base de donnes monte en charge horizontalement peut se prsenter une
application sous l'aspect d'une seule grande base de donnes. Le changement majeur pour les
requtes SQL rside dans le nom des tables qui inclura le nom du serveur li sur lequel les donnes sont
hberges. Les serveurs lis constituent une option intressante de monte en charge horizontale lorsqu'il
est difficile de modifier les applications. Dans SQL Server, il est possible d'utiliser des synonymes pour
soumettre un nom en quatre parties incluant le nom du serveur comme un nom unique. Ainsi, les requtes
qui renvoyaient une table locale peuvent dsormais renvoyer une table distante sans modifier la
requte. La Figure 3 prsente l'utilisation de serveurs lis comme solution de monte en charge
horizontale.

Figure 3. Serveurs lis

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.

Vues partitionnes distribues

Des vues partitionnes distribues (DPV) ont t intgres SQL Server dans l'objectif prcis d'assurer la
monte en charge horizontale transparente des donnes partitionnes. Les donnes d'une table sont
partitionnes entre les tables de plusieurs bases de donnes distribues, en fonction d'une cl de
partitionnement. Par exemple, une table client peut tre partitionne en plusieurs plages de numros
clients (1 10 000 dans une base de donnes, 10 001 20 000 dans une deuxime, 20 001 30 000 dans
une troisime, et ainsi de suite). Des contraintes de vrification indiquent SQL Server dans quelle base de
donnes se trouvent les diffrents clients. Une requte qui accde un numro de client ne sera excute
que dans la base de donnes qui contient le numro de client souhait. Les requtes exemptes de numro
de client doivent tre excutes dans toutes les partitions. Par exemple, si vous souhaitez consulter des
informations sur George Bush sans connatre son numro de client, SQL Server doit effectuer une
recherche dans toutes les bases de donnes contenant une partition de la table des clients. De mme, une
jonction entre deux tables sur le numro de client peut s'excuter paralllement dans chaque base de
donnes, les rsultats tant renvoys la base d'o mane la requte.
l'instar de la plupart des solutions de monte en charge horizontale, le recours aux DPV implique un
nombre limit de requtes ncessitant un transfert de donnes entre bases de donnes. Si toutes les
donnes des bases de donnes DPV sont partitionnes l'aide de la mme cl de partitionnement, toutes
les jonctions correspondant cette cl peuvent s'excuter en local. Si vous partitionnez une base de
donnes de saisies de commandes de telle sorte que toutes les tables soient partitionnes sur la cl client,
et si les requtes de la base de donnes contiennent une cl client, toutes les requtes peuvent tre
satisfaites dans la base de donnes qui contient cette cl. Bien entendu, si vous excutez la requte depuis
une base de donnes qui ne contient pas cette cl, la requte sera distribue. En pratique, il n'est pas
possible de partitionner toutes les donnes sur une mme cl. Par consquent, certaines tables doivent
tre partitionnes sur diffrentes cls et de nombreuses tables ne sont pas partitionnes dans la plupart
des mises en uvre. Ainsi, de nombreuses requtes doivent accder plusieurs bases de donnes. La
russite de la monte en charge horizontale dpend donc de la composition relative de requtes
distribues et locales. Une jonction entre une table partitionne et une table non partitionne peut
s'avrer coteuse du fait que les donnes non partitionnes doivent tre envoyes tous les serveurs
17

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.

Routage dpendant des donnes

Avec les vues partitionnes distribues, SQL Server comprend comment les donnes sont partitionnes et
dtermine o les chercher. Avec le routage dpendant des donnes (DDR), les informations sont
partitionnes parmi les bases de donnes. L'application ou certains services middleware se chargent
ensuite d'acheminer les requtes vers la bonne base de donnes. Le DDR est donc beaucoup moins
transparent au niveau applicatif. Toutefois, si l'application intervient dans le choix du point d'excution
18

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.

Figure 4. Routage dpendant des donnes

Beaucoup de grandes bases de donnes qui grent d'importants volumes de transactions utilisent des
variantes de la monte en charge horizontale par DDR pour rpartir le traitement parmi des centaines,
voire des milliers de serveurs de bases de donnes. Face une telle quantit de serveurs, la plupart des
requtes doivent tre diriges vers un seul serveur. Le modle de donnes doit donc tre conu pour que
toutes les donnes ncessaires pour une requte ou une mise jour soient hberges sur le mme
serveur. Par exemple, un grand distributeur en ligne peut partitionner ses bases de donnes en fonction
de l'identifiant client. Ainsi, toutes les informations concernant un client, toutes les commandes qu'il a
passes, le statut de ses factures, ses informations de carte bancaire, etc. se trouvent dans la mme base
donnes. Ce sont les donnes de ce client prcis. On parle souvent dans ce cas d'entit client. Le
partitionnement de donnes entre des entits (groupes de donnes indpendants auquel un seul
identifiant peut faire rfrence) est la mthode la plus utilise pour concevoir des bases de donnes trs
volumineuses. Chaque moteur de base de donnes gre des requtes pour les entits clients de sa propre
base. Lorsque le nombre d'entits devient trop important, un nouveau serveur est ajout et les entits
sont redistribues.
Une fois que toutes les donnes clients sont partitionnes en entits identifies par un ID client, reste
dterminer comment l'application sait quel ID client utiliser. La plupart du temps, c'est assez simple. Si le
client est cens passer des commandes, on peut supposer qu'une connexion a t cre et que l'ID client
est dans un enregistrement de connexion (sur le serveur Web ou dans un cookie, par exemple). Si aucune
procdure de connexion n'existe, il suffit de mettre en uvre une table mappant l'identit des clients
19

(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.

Fdration SQL Azure

Face aux besoins hautement volutifs du cloud computing, Microsoft a instaur un principe de fdration
dans Microsoft SQL Azure pour augmenter la capacit de monte en charge horizontale, parer aux
problmes de rpartition et de redistribution des donnes, et rpondre la ncessit d'un routage de
connexion performant. La fdration permet aux applications d'voluer de plusieurs dizaines plusieurs
centaines de bases de donnes SQL. Elle facilite galement le repartitionnement des donnes sans
interruption d'activit. Pour rpondre aux exigences d'architecture mutualise, la fdration fournit des
oprations de repartitionnement qui facilitent la gestion du positionnement et du repositionnement des
locataires, sans que l'application ne soit interrompue. Parmi les applications de base de donnes pouvant
bnficier de la fdration, on retrouve les diteurs de logiciels qui mettent en uvre des solutions SaaS
mutualises, les solutions de base de donnes Web grande chelle visant faire face aux pics de
demandes, aux rafales, aux mines ou aux nouveaux flux d'utilisateurs, et les applications NoSQL.

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

Tableau 1. Facteurs influenant le choix des solutions de monte en charge horizontale

Frquence de mise jour

Aptitude modifier
l'application

Capacit de
partitionnement
des donnes

Couplage des
donnes

Bases de donnes
Lecture seule.
partages volutives

Peu, voire pas de

changement requis.

Sans importance.

Sans importance.

Rplication d'gal Lecture essentiellement,

gal
pas de conflits.

Peu, voire pas de

changement requis.

Sans importance.

Sans importance.

Serveurs lis

Mises jour minimises

Changements
entre les bases de donnes. mineurs.

Gnralement sans Faible taux de

importance.
couplage essentiel.

Vues partitionnes Mises jour frquentes

distribues
prises en charge.

Certains changements
Trs important.
peuvent tre requis.

Impact minime.

Routage dpendant Mises jour frquentes

des donnes
prises en charge.

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

Bases de donnes partages volutives : http://msdn.microsoft.com/en-us/library/ms345584.aspx

22

Rplication d'gal gal

Rplication transactionnelle d'gal gal : http://msdn.microsoft.com/enus/library/ms151196(v=sql.110).aspx

Configuration de la topologie de rplication transactionnelle d'gal gal :
http://msdn.microsoft.com/en-us/library/ms183664.aspx
Dtection de conflits dans la rplication transactionnelle d'gal gal :
http://msdn.microsoft.com/en-us/library/bb934199(v=sql.110).aspx

Serveurs lis

Liaison de serveurs : http://msdn.microsoft.com/en-us/library/ms188279.aspx

Vues partitionnes distribues

Mise en uvre de serveurs de bases de donnes fdrs : http://msdn.microsoft.com/enus/library/ms191185.aspx

Rsolution des vues partitionnes distribues : http://technet.microsoft.com/enus/library/ms187836.aspx
Modification de donnes dans des vues partitionnes distribues : http://msdn.microsoft.com/enus/library/ms187067.aspx

Routage dpendant des donnes

Monte en charge horizontale de SQL Server par le routage dpendant des donnes :
http://technet.microsoft.com/en-us/library/cc966448.aspx

Fdration SQL Azure

Fdration dans SQL Azure : http://msdn.microsoft.com/enus/library/windowsazure/hh597452.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