• Article

Déchargement de traitement par lots

Certaines applications nécessitent que des opérations par lots sollicitant un traitement intensif soient effectuées sur les données. Dans certains cas, ces opérations par lots ne peuvent pas être effectuées sur le serveur de traitement transactionnel en ligne (OLTP), car la charge de traitement interfère avec d'autres opérations sur le serveur. Dans ce cas, il est nécessaire d'effectuer le traitement par lots sur un serveur séparé. Dans certains cas, le traitement par lots est simplement déchargé, dans d'autres cas, les résultats du traitement par lots sont propagés en retour sur le serveur de traitement en ligne.

Le diagramme suivant montre un scénario typique de données répliquées sur un serveur de traitement pas lots :

Données de réplication pour le traitement par lots

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 utilise un traitement par lots pour contrôler la fraude par carte de crédit sur leur site Web. Les données collectées à partir des transactions sur le site Web sont répliquées à partir du serveur Microsoft SQL Server utilisé sur le site Web vers un serveur SQL Server séparé utilisé pour plusieurs applications Adventure Works Cycles. Des recherches de modèles de fraude par carte de crédit sont effectuées sur les données du serveur de traitement par lots. Bien que la détection de fraude ne produise qu'une faible quantité de données (mise à jour de données dans un petit nombre de colonnes si un compte montre une activité suspecte), les vérifications nécessitent des calculs intensifs et des ressources importantes du serveur. Une fois le traitement par lots exécuté, une faible quantité de données est renvoyée sur le serveur OLTP pour le site Web, indiquant les comptes pouvant montrer des signes de fraude.

Conditions communes requises pour ce scénario

Les applications de traitement par lots ont généralement les conditions requises suivantes, qu'une solution de réplication appropriée doit résoudre :

  • Le système doit maintenir la cohérence transactionnelle.

  • Le système doit avoir une faible latence : les mises à jour sur le serveur de traitement en ligne doivent atteindre rapidement le serveur de traitement par lots.

  • Le système doit disposer d'un débit élevé : il doit pouvoir gérer la réplication d'un grand nombre de transactions.

  • Le traitement de la réplication ne doit nécessiter qu'une charge minimale sur le serveur de traitement en ligne.

  • Les modifications de données peuvent circuler dans les deux sens : les résultats du traitement par lots peut être propagé en retour sur le serveur de traitement en ligne.

  • Les données requises sur le serveur de traitement par lots peut être un sous-ensemble des données disponibles sur le serveur de traitement en ligne.

Type de réplication à utiliser pour ce scénario

SQL Server utilise une métaphore de l'industrie de la publication pour décrire les composants du système de réplication. Les composants comprennent le serveur de publication, les abonnés, les publications et articles, et les abonnements.

  • Dans le diagramme ci-dessus, le serveur de traitement en ligne est le serveur de publication. Toute ou partie des données du serveur de traitement en ligne est ajoutée à la publication, chaque table de données étant un article (les articles peuvent également être des objets de base de données, comme des procédures stockées). Le serveur de traitement par lots est un abonné à la publication et reçoit un schéma et des données comme abonnement.

  • Si les résultats sont propagés en retour sur le serveur de traitement en ligne, le serveur de traitement par lots est également un serveur de publication (généralement avec la même publication que celle du serveur de traitement en ligne) et le serveur de traitement en ligne s'abonne à la publication.

Pour plus d'informations sur les composants du système, consultez Présentation du modèle de publication de réplication.

SQL Server offre différents types de réplication pour différents besoins d'application : la réplication de capture instantanée, la réplication transactionnelle et la réplication de fusion. Ce scénario est mieux implémenté avec la réplication transactionnelle, davantage conçue pour gérer les besoins décrits dans la section précédente. Pour plus d'informations sur la réplication transactionnelle, consultez Présentation de la réplication transactionnelle et Fonctionnement de la réplication transactionnelle.

Par défaut, la réplication transactionnelle aborde les conditions requises principales de ce scénario :

  • Homogénéité des transactions

  • Faible latence

  • Débit élevé

  • Charge minimale

Les options dont il faut tenir compte pour ce scénario sont le filtrage, la réplication transactionnelle d'égal à égal et la réplication transactionnelle bidirectionnelle :

Étapes d'implémentation de ce scénario

Pour implémenter ce scénario, vous devez 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 :

Une fois que l'abonnement est initialisé et que les données circulent entre le serveur de publication et les abonnés, vous devrez peut-être consulter les rubriques suivantes afin d'obtenir des informations sur les tâches communes d'administration et d'analyse :