Modèle pour la mise à jour des bases de données SQL Server 2008 à partir d'un maître tout en minimisant la perturbation

Question

Nous avons une application Web ASP.NET hébergée par une ferme Web de nombreuses instances utilisant SQL Server 2008 dans laquelle nous effectuons l'agrégation et le pré-traitement des données à partir de plusieurs sources dans un format optimisé pour les performances de requête utilisateur rapide (produisant 5 à 10 millions de lignes dans certaines tables). L'agrégation et l'optimisation sont effectuées par un service sur un serveur principal que nous voulons ensuite distribuer à plusieurs copies frontales en lecture seule utilisées par les instances d'application Web pour faciliter l'évolutivité maximale.

Ma question concerne le meilleur moyen d'obtenir ces données à partir d'une base de données dorsale vers les copies frontales en lecture seule, de manière à ne pas nuire à leurs performances au cours du processus. Les instances de l'application Web frontale seront soumises à une charge élevée constante et doivent avoir une bonne réactivité à tout moment. La base de données principale est constamment mise à jour donc je suspecte que la réplication transactionnelle ne sera pas la meilleure approche, car le flot constant de mises à jour des copies nuira à leurs performances.

L'inertie des données n'est pas un problème majeur, la réplication d'instantanés peut être la solution, mais cela entraînera des performances médiocres pendant les périodes de réplication.

Si vous effectuez une insertion en bloc et en masse, vous obtiendrez des périodes sans données pour les requêtes utilisateur. Je ne veux pas vraiment entrer dans l'écriture d'une approche de cluster complexe où nous laissons des copies hors du cluster pendant la mise à jour - y a-t-il quelque chose dans ce sens que nous pouvons faire sans trop d'efforts ou existe-t-il une meilleure alternative? ?

Answer 1

Il existe en fait une technologie intégrée à SQL Server 2005 (et 2008) conçue pour résoudre ce type de problème. Service Broker (je ferai référence plus loin comme SSB). Le problème est qu'il a une courbe d'apprentissage très raide.

Je sais que MySpace est devenu public comment utiliser SSB pour gérer leur parc de serveurs SQL: MySpace Uses SQL Server Service Broker to Protect Integrity of 1 Petabyte of Data. Je connais plusieurs autres (principaux) sites qui utilisent des modèles similaires, mais malheureusement, ils ne sont pas rendus publics, donc je ne peux pas référencer les noms. J'ai été personnellement impliqué dans certains projets autour de cette technologie (je suis un ancien membre de l'équipe SQL Server).

Maintenant, gardez à l'esprit que SSB n'est pas une technologie de transfert de données dédiée comme la réplication. En tant que tel, vous ne trouverez rien de semblable aux assistants de publication et aux options de déploiement simples de la réplication (vérifiez une table et elle est transférée). La SSB est une technologie de messagerie fiable et en tant que telle ses primitives s'arrêtent au niveau de l'échange de messages, vous devrez écrire le code qui utilise le data change capture, le conditionne comme messages et aussi le déballage du message dans les tables relationnelles à destination. Pourquoi certaines entreprises préfèrent encore la réplication SSB à une tâche comme vous l'avez décrite, car SSB a une bien meilleure histoire en termes de fiabilité et d'évolutivité. Je connais des projets qui échangent des données entre plus de 1500 sites, bien au-delà des capacités de la réplication. La SSB est également extraite de la topologie physique: vous pouvez déplacer des bases de données, renommer des machines, reconstruire des serveurs sans modifier l'application. Parce que le flux de données se produit sur logical routes l'application peut s'ajouter à la volée à de nouvelles topologies. La SSB résiste également aux longues périodes de disocnnect et d'indisponibilité, étant capable de reprendre le flux de données après des heures, des jours et même des mois de déconnexion. La grande capacité d'intégration des moteurs (la SSB fait partie du moteur SQL lui-même, pas une collection d'applications satellites et des processus comme Replication) signifie que les retards de traitement peuvent être des processus à des temps raisonnables (je connais des sites qui traversent la moitié millions transactions par minute).Les applications SSB s'appuient généralement sur internal Activation pour traiter les données entrantes. SSB a également des caractéristiques uniques comme load balancing intégré (via des routes) avec sémantique de session collante, support pour la livraison deadlock free application specific correlated processing, priority data, support spécifique pour la mise en miroir de base de données, certificate based authentication pour les opérations inter-domaines, persisted timers intégré et beaucoup plus.

Ceci n'est pas une réponse spécifique 'comment déplacer des données de la table T sur le serveur A vers le serveur B'. Est plus une technologie générique sur la façon «d'échanger des données entre le serveur A et le serveur B».

Answer 2

Je n'ai jamais eu à faire face à ce scénario auparavant, mais j'ai trouvé une solution possible pour cela. Fondamentalement, cela nécessiterait un changement dans la structure de votre base de données principale. Au lieu de stocker les données, vous conservez des enregistrements des modifications de ces données. Ainsi, si un enregistrement est ajouté, vous stockez "Table X, nouvel enregistrement inséré avec ces valeurs: ..." Avec des modifications, il suffit de stocker la table, le champ et la valeur modifiée. Avec les suppressions, il suffit de stocker quel enregistrement est supprimé. Chaque modification sera stockée avec un horodatage.

Vos systèmes clients conserveront leurs copies locales de la base de données et demanderont régulièrement toutes les modifications de la base de données après une certaine date/heure. Vous exécutez ensuite ces modifications sur la base de données locale et il sera de nouveau à jour.

Et le back-end? Eh bien, il faudrait juste garder une liste de modifications et peut-être une table avec les données de base. Garder juste les modifications signifie aussi que vous gardez une trace de l'histoire, vous permettant de demander au système à quoi il ressemblait il y a un an.

La qualité de cette opération dépend du nombre de modifications sur la base de données principale. Mais si vous demandez les changements toutes les 15 minutes, il ne devrait pas y avoir autant de données à chaque fois.

Mais encore une fois, je n'ai jamais eu l'occasion de travailler sur une application réelle, donc c'est toujours un principe théorique pour moi. Cela semble rapide mais beaucoup de travail sera nécessaire.

Answer 3

Option 1: permet d'écrire une application pour transférer les données à l'aide de transactions de niveau ligne. Cela pourrait prendre plus de temps mais n'entraînerait aucune interruption du site en utilisant les données car les lignes sont là avant et après la lecture, juste avec de nouvelles données. Ce traitement se produirait sur un serveur séparé pour minimiser la charge.

Dans le serveur SQL 2008, vous pouvez définir READ_COMMITTED_SNAPSHOT à ON pour vous assurer que la ligne en cours de mise à jour ne provoque pas de blocage.

Mais fondamentalement, toute cette application est de lire les nouvelles données comme il est disponible à partir d'une base de données et dans l'autre.

Option 2: déplace les données (tables ou base de données entière) du serveur d'agrégation vers le serveur frontal. Automatisez ceci si possible. Changez ensuite votre application Web pour qu'elle pointe vers la nouvelle base de données ou les nouvelles tables pour les demandes futures. Cela fonctionne mais nécessite un contrôle sur l'application Web, que vous ne pouvez pas avoir.

Option 3: Si vous parliez d'une seule table (ou que cela pourrait fonctionner avec plusieurs), vous pouvez faire un échange de vue. Vous écrivez donc votre code contre une vue sql qui pointe vers la table A. Vous travaillez sur la table B et quand elle est prête, vous mettez à jour la vue pour qu'elle pointe vers la table B. Vous pouvez même écrire une fonction qui détermine la table active et l'automatiser toute la chose de l'échange.

Option 4: Vous pouvez peut-être utiliser quelque chose comme la réplication au niveau octet du serveur. Cela semble effrayant cependant. Ce qui copie essentiellement le serveur du point A au point B exactement jusqu'aux octets. Il est principalement utilisé dans les situations de DR, ce qui peut sembler être une situation de type DR, mais pas vraiment.

Option 5: Abandonnez et apprenez à vendre de l'assurance. :)