Base de données bon point de découplage système?

Question

Nous avons deux systèmes où le système A envoie des données à un système B. Il est nécessaire que chaque système peut fonctionner indépendamment de l'autre et ne va exploser si l'autre est en panne. La question est quelle est la meilleure façon pour le système A à communiquer avec le système B tout en respectant l'exigence de découplage.

Système B a actuellement un processus qui interroge les données dans une table db et traite les nouvelles lignes qui ont été insérées.

Une conception proposée est pour le système A à juste insérer des données dans la table système b db et ont système processus B les nouvelles lignes par le processus existant. La question est cette solution ne répond à l'exigence de découplage des deux systèmes? Est une base de données considérée comme faisant partie d'un système B qui pourrait devenir un système indisponible et cause de faire sauter?

Une autre solution consiste pour le système A pour mettre les données dans une file d'attente MQ et un processus qui se lit de MQ, puis l'insérer dans la base de données du système hôte. Mais est-ce que les frais généraux supplémentaires? En fin de compte est une file d'attente MQ plus tolérant aux pannes d'une table db?

Answer 1

D'une manière générale, le partage de base de données est un couplage étroit et ne pas être préféré, sauf peut-être à des fins de vitesse. Non seulement pour des raisons de disponibilité, mais aussi parce que le système A et B est modifié et mis à jour en plusieurs points dans leur avenir, et devraient avoir des dépendances minimales sur l'autre - le passage de messages est une dépendance évidente, alors que les bases de données partagées ont tendance à vous mordre (ou vos) sur la héritières postérieure au moment prévu. Si vous allez la route de partage de base de données, au moins rendre l'interface de partage explicite avec des tables ou des vues dédiées.

Il existe quatre niveaux communs d'intégration:

1. Partage de la base de données
2. Partage de fichiers
3. appel de procédure à distance
4. Message Passing

qui peut être appliqué et combiné dans diverses situations, avec différentes disponibilité et maintenabilité. Vous avez une excellente vue d'ensemble à la modèles d'intégration d'entreprise le site.

Comme toute infrastructure d'intégration centrale, MQ doit être hébergé dans un environnement avec une grande disponibilité, plein basculement et c. Il existe d'autres solutions de file d'attente qui vous permettent de distribuer la coordination de la file d'attente.

Answer 2

Utilisez Queues pour la communication. Ne pas « passer » les données du Système A au système B à la base de données. Vous utilisez la base de données comme une file d'attente de messages géant, coûteux et complexe,.

Utiliser une file d'attente de message en tant que file d'attente de message.

Ce n'est pas en tête "Extra". Ceci est la meilleure façon de découpler les systèmes. Il appelle l'architecture orientée services (SOA) et l'utilisation des messages est absolument central à la conception.

Une file d'attente MQ est beaucoup plus simple que d'une table de base de données.

Ne pas comparer « la tolérance aux pannes », car un SGBDR utilise les frais généraux énormes (presque inimaginables) pour atteindre un niveau d'assurance raisonnable que votre transaction terminée correctement. Verrouillage. Tamponnage. Ecrire Queues. Gestion du stockage. Etc Etc.

Une implémentation de file d'attente de messages fiable utilise certains magasins de support pour maintenir l'état de la file d'attente. Les frais généraux est beaucoup, beaucoup moins un SGBDR. La performance est bien meilleure. Et il est beaucoup, beaucoup plus simple d'interagir avec.

Answer 3

Dans SQL Server je le faire grâce à un package SSIS ou un emploi (en fonction du nombre d'enregistrements et de la complexité de ce que je bougeais). D'autres bases de données ont également des solutions ETL. J'aime la solution ETL becasue je peux tenir des registres de ce qui a été changé et quelles erreurs ont été traitées, je peux envoyer des documents qui, pour une raison quelconque ne vont à l'autre système (structures de données sont rarement les mêmes entre deux bases de données) à une participation table sans tuer le reste du processus. Je peux aussi apporter des modifications aux données circulant pour tenir compte des différences de base de données (des choses comme valeurs de la table de recherche, par exemple l'état achevé en DB1 est 5 et il est 7 db2 ou dire db2 a un champ obligatoire DB1 ne fonctionne pas et vous doivent ajouter une valeur par défaut au dépôt si elle est nulle). Si l'un ou l'autre servver est en cours d'exécution sur le travail le package SSIS échouera et aucun système seront touchés, il maintient les datbases découplés en utilisant des déclencheurs ou la réplication ne serait pas.