Partage de données entre bases de données SQL

il y a plusieurs façons de s'attaquer à ce problème. Je recommande fortement les solutions 1, 2 ou 3 selon vos besoins:

1. réplication transactionnelle : si la base de données commune est l'enregistrement de Compte et que vous voulez fournir des versions en lecture seule des données à des applications distinctes, alors vous pouvez répliquer les tables de base, peut-être même juste les colonnes de base des tables, à chaque serveur. Un avantage de cette approche est que vous pouvez répliquer à autant de bases de données d'abonnés que vous le souhaitez. Cela signifie également que vous pouvez personnaliser quelles tables et quels champs sont disponibles pour les abonnés en fonction de leurs besoins. Ainsi, si une application a besoin de tables d'utilisateurs et non de tables de fournisseurs, alors vous ne vous abonnez qu'aux tables d'utilisateurs. Si un autre n'a besoin que de tableaux fournisseurs et non de tableaux utilisateurs, alors vous pouvez vous abonner uniquement aux tableaux fournisseurs. Un autre avantage est que la réplication reste synchronisée et vous pouvez toujours réinitialiser un abonnement si un problème se présente.

   j'ai utilisé la réplication transactionnelle pour sortir plus de 100 tableaux d'un entrepôt de données afin de séparer les applications en aval qui avaient besoin d'accéder à des données agrégées provenant de plusieurs systèmes. Étant donné que notre entrepôt de données a été mis à jour sur une base horaire à partir des sources de données d'expédition de miroirs et de journaux, les applications de production avaient des données provenant de nombreux systèmes dans une fenêtre mobile de 20 à 80 minutes chaque heure.

   réplication transactionnelle poste à poste comme type de publication peut être mieux adapté pour le cas d'utilisation que vous avez fourni. Cela peut être vraiment utile si vous voulez déployer des changements de schéma ou de réplication noeud par noeud. La réplication transactionnelle Standard présente certaines limites dans ce domaine.

   les types de publication à réplication instantanée ont plus de latence que les publications transactionnelles, mais vous pourriez vouloir considérer si un certain degré de la latence est acceptable.

   même si vous avez mentionné que vous êtes un magasin de Serveur SQL de Microsoft, s'il vous plaît garder à l'esprit d'autres RDBMs ont des technologies similaires. Étant donné que vous parlez spécifiquement DE MS SQL Server, Veuillez noter que la réplication transactionnelle vous permet également de vous répliquer dans les bases de données Oracle. Donc, si vous en avez quelques - uns dans votre organisation, cette solution peut encore fonctionner.

   un inconvénient à l'utilisation de la réplication transactionnelle est que si vous centralisez le serveur descend vous pouvez commencer à éprouver de la latence avec des données dans les copies en aval des objets répliqués. Si les objets répliqués (articles) sont vraiment grands et que vous avez besoin de réinitialiser une table, alors cela peut prendre beaucoup de temps à faire, aussi.

2. miroirs : si vous voulez rendre la base de données accessible en temps quasi réel sur les serveurs en aval, vous pouvez configurer jusqu'à deux miroirs asychronous. J'ai intégré des données avec une application CRM de cette manière. Toutes les lectures sont venus de jointures vers le miroir. Toutes les Écritures ont été placées dans une file d'attente de messages qui a ensuite appliqué les modifications au serveur central de production. L'inconvénient de cette approche est que vous ne pouvez pas créer plus de 2 asynchrone miroirs. Vous ne voulez pas utiliser de miroirs synchrones à cette fin, sauf si vous prévoyez d'utiliser les miroirs pour la récupération après sinistre, aussi.

3. Systèmes De Messagerie : si vous prévoyez d'avoir de nombreuses applications séparées qui ont besoin de données à partir d'une seule base de données centrale, alors vous pouvez envisager des systèmes de messagerie d'entreprise comme IBM Web Sphere, Microsoft BizTalk, Vitria, TIBCO, etc. Ces applications sont conçues spécifiquement pour résoudre ce problème. Ils ont tendance à être coûteux et encombrants à mettre en œuvre et à maintenir, mais ils peuvent prendre de l'ampleur si vous avez des systèmes distribués à l'échelle mondiale ou des douzaines d'applications distinctes qui ont tous besoin de partager des données un certain degré.

4. serveurs reliés : on dirait que vous avez déjà pensé à celui-ci. Vous pouvez exposer les données via des serveurs liés. Je ne crois pas que ce soit une bonne solution. Si vous voulez vraiment suivre cette voie, alors envisagez de configurer un miroir asynchrone à partir de la base de données centrale vers un autre serveur et ensuite configurer les connexions de serveur liées au miroir. Cela permettra au moins d'atténuer le risque qu'une requête sur le web les applications causeront des problèmes de blocage ou de performance avec votre base de données centrale de production.

   IMO, serveurs liés ont tendance à être une méthode dangereuse pour le partage des données pour les applications. Cette approche traite les données comme un citoyen de seconde classe dans votre base de données. Cela conduit à de très mauvaises habitudes de codage, d'autant plus que vos développeurs peuvent travailler sur différents serveurs dans différentes langues avec des méthodes de connexion différentes. Vous ne savez pas si quelqu'un va pour écrire une requête vraiment henious contre vos données de base. Si vous définissez un standard qui nécessite de pousser une copie complète des données partagées vers le serveur non-core, alors vous n'avez pas à vous soucier de savoir si oui ou non un développeur écrit du mauvais code. Au moins du point de vue que leur mauvais code ne va pas gâcher la performance d'autres systèmes bien écrits.

   il y a beaucoup, beaucoup de ressources là-bas qui expliquent pourquoi l'utilisation de serveurs liés peut être mauvaise dans ce contexte. Un la liste non-exhaustive des raisons comprend: (a) le compte utilisé pour le serveur lié doit avoir des permissions D'affichage de statistiques DBCC ou les requêtes ne seront pas en mesure de faire usage des statistiques existantes , (b) les indices de requête ne peuvent pas être uesd à moins d'être soumis comme une OPENQUERY, (c) les paramètres ne peuvent pas être passés quand utilisé avec OPENQUERY, (d) le serveur ne dispose pas de statistiques suffisantes sur le serveur lié, par conséquent, crée des plans de requête assez terribles, (e) connectivité réseau des problèmes peuvent entraîner des défaillances, (f) de l'une de ces cinq problèmes de performances , et (g) le redoutable SSPI contexte de l'erreur lors de la tentative d'authentification windows informations d'identification active directory dans un double saut scénario . Les serveurs reliés peuvent être utiles pour certains scénarios spécifiques, mais il n'est pas recommandé de construire un accès à une base de données centrale autour de cette fonctionnalité, bien que cela soit techniquement possible.

5. en Vrac ETL Processus: si un haut degré de latence est acceptable pour les applications web, alors vous pouvez écrire des processus ETL en vrac avec SSIS (lots of good links in this StackOverflow question) qui sont exécutés par des tâches D'agent de serveur SQL pour déplacer des données entre les serveurs. Il existe également d'autres outils ETL alternatifs comme Informatica, Pentaho, etc. utilisez ce qui fonctionne le mieux pour vous.

   Ce n'est pas une bonne solution si vous avez besoin d'un faible degré de latence. J'ai utilisé cette solution lors de la synchronisation vers une solution CRM hébergée par une tierce partie pour les champs qui pourraient tolérer une latence élevée. Pour les champs qui ne pouvaient tolérer une latence élevée (données de création de compte de base), nous nous sommes appuyés sur la création de doublons dans le CRM par des appels de service web au point de génération de Compte.

6. Nuit De Sauvegarde et de restauration: si vos données peuvent tolérer des degrés élevés de latence (jusqu'à un jour) et des périodes d'indisponibilité, alors vous pouvez sauvegarder et restaurer la base de données dans les environnements. Ce n'est pas une bonne solution pour les applications web qui nécessitent 100% de temps de fonctionnement. L'idée est que vous prenez une sauvegarde de base, la restaurer à un nom de restauration séparé, puis renommer la base de données originale et la nouvelle dès que le nouveau est prêt à l'emploi. J'ai vu Cela fait pour certaines applications Web internes, mais je ne recommande généralement pas cette approche. C'est mieux adapté à un environnement de développement plus faible, pas à un environnement de production.

7. Log Shipping Secondaries : vous pouvez configurer l'expédition de log entre le primaire et un nombre quelconque de secondaires. Ceci est similaire au processus de sauvegarde et de restauration nocturne, sauf que vous pouvez mettre à jour la base de données plus fréquemment. Dans un cas, cette solution a été utilisée pour exposer des données provenant de l'un de nos principaux systèmes de base pour les utilisateurs en aval en passant entre deux destinataires d'expédition de grumes. Il y avait un autre serveur pointé vers les deux bases de données et basculé entre elles chaque fois que la nouvelle était disponible. Je déteste vraiment cette solution, mais la seule fois où j'ai vu cette mise en œuvre il a répondu aux besoins de l'entreprise.