Amélioration de l'évolutivité
Les applications de niveau intermédiaire utilisent souvent pour stocker les données une seule base de données, ce qui peut limiter l'évolutivité à mesure que la base de données s'accroît. Si les applications exécutent plus de lectures que d'écritures, par exemple sur un catalogue publié sur le Web, il est possible de distribuer horizontalement la portion lecture de la charge de travail en mettant en cache dans plusieurs bases de données les données en lecture seule et en répartissant les connexions des clients sur ces bases de données afin de distribuer la charge.
Le diagramme qui suit présente une configuration dans laquelle les serveurs d'application et les serveur Web utilisent des données en provenance de trois serveurs de mise en cache.
.gif "Utilisation de la réplication pour l'échelle d'activité de lecture")
Si votre application nécessite également une disponibilité accrue et/ou exige que les lectures et les mises à jour d'un utilisateur donné soient transmises vers un serveur d'application puis vers un serveur de mise en cache spécifiques, consultez l'exemple proposé dans Amélioration de la disponibilité et de l'évolutivité.
Exemple Adventure Works Cycles
Adventure Works Cycles est une société de fabrication fictive utilisée pour illustrer des scénarios et des concepts de base de données. Pour plus d'informations, consultez Exemples de bases de données AdventureWorks2008R2.
Adventure Works Cycles a récemment mis à niveau son site Web pour y intégrer de nouvelles fonctions :
Commande de produits en ligne pour les clients.
Consultation en ligne de l'état de la commande.
Amélioration des capacités d'interrogation de la documentation produits.
La mise en place de la commande en ligne de produits à partir du site Web a accru l'activité de l'unique ordinateur de l'entreprise, qui exécute Microsoft SQL Server. Les administrateurs de Adventure Works ont décidé d'utiliser cet ordinateur comme source pour les données répliquées. Toute l'activité de lecture a été distribuée horizontalement vers trois autres ordinateurs exécutant SQL Server, avec en cache les données en provenance de l'ordinateur source. Les ordinateurs de mise en cache traitent toute l'activité de lecture, notamment celle des utilisateurs qui consultent et interrogent le catalogue des produits et vérifient l'état de leur commande. Toute l'activité d'écriture est dirigée vers la base de données source.
Conditions communes pour ce scénario
Les applications qui utilisent la réplication pour l'évolutivité présentent en général les conditions suivantes, auxquelles doit répondre une solution de réplication appropriée :
Le système doit assurer la cohérence des transactions.
Le système doit avoir une faible latence : les mises à jour effectuées à la source doivent atteindre rapidement le cache.
Le système doit avoir un débit élevé : il doit assurer la réplication d'un grand nombre de transactions.
Le traitement des réplications doit nécessiter une charge minimale sur le serveur source.
Les données nécessaires au niveau du cache peuvent être un sous-ensemble des données disponibles à la source.
Type de réplication à utiliser pour ce scénario
SQL Server utilise une métaphore du secteur de l'édition pour décrire les composants du système de réplication. Ces composants sont le serveur de publication, les Abonnés, les publications et articles et les abonnements. Pour plus d'informations sur les composants de ce système, consultez Présentation du modèle de publication de réplication.
Dans le diagramme ci-dessus, le serveur source est le serveur de publication Tout ou partie des données du serveur source sont incluses dans la publication, chaque table de données étant un article (les articles peuvent aussi être d'autres objets de bases de données, tels que des procédures stockées). Chaque cache est un Abonné à la publication, et reçoit comme abonnement des schémas et des données.
SQL Server offre différents types de réplication pour différents besoins des applications : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. La plus adaptée à ce scénario est la réplication transactionnelle, qui convient bien pour prendre en compte les conditions exposées dans la section qui précède. Pour plus d'informations sur la réplication transactionnelle, consultez Présentation de la réplication transactionnelle et Fonctionnement de la réplication transactionnelle.
De par sa conception, la réplication transactionnelle satisfait les principales conditions de ce scénario :
Homogénéité des transactions
Faible latence
Débit élevé
Charge minimale
La première option à envisager pour ce scénario est le filtrage. La réplication transactionnelle vous permet de filtrer les lignes et les colonnes, de façon que les tables au niveau des Abonnés ne contiennent que les données nécessaires à votre application. Pour plus d'informations, consultez Filtrage des données publiées.
Procédure de mise en œuvre de ce scénario
Pour mettre en œuvre ce scénario, vous devez tout d'abord créer une publication et des abonnements, puis initialiser chaque abonnement. Cliquez sur les liens ci-dessous pour plus d'informations sur chaque étape :
Après initialisation d'un abonnement, lorsque les données circulent entre le serveur de publication et les Abonnés, peut-être aurez-vous besoin de consulter les rubriques qui suivent pour vous informer sur les tâches d'administration et de surveillance courantes :