Refactoring à partir du modèle de base de données partagée

Question

Au travail, nous avons plusieurs applications avec des bases de données dans un serveur SQL centralisé. Chaque fois qu'une application doit travailler avec des données d'une autre application, elle les interroge ou les met à jour via la base de données. Je crois que c'est le modèle de "base de données partagée" comme décrit dans le livre Enterprise Integration Patterns (Hohpe & Woolf).

Ces dépendances de bases de données croisées nous causent beaucoup, beaucoup de maux de tête. Le plus gros de ces problèmes est que nous sommes confrontés à des problèmes de performance sur le serveur SQL et que nous ne pouvons pas faire évoluer les choses à cause des dépendances entre les bases de données. Je pense que ce que nous devrions faire est de s'éloigner du modèle de base de données partagée vers un système de messagerie tel que décrit dans le livre EIP. Chaque application serait responsable de toutes ses propres données, et d'autres applications qui veulent accéder à ces données l'obtiendraient à travers les services (sur un bus de messagerie?). Où commençons-nous le refactoring vers le modèle de messagerie?

• Est-ce qu'on commence par refactoriser l'une des applications pour gérer sa propre base de données d'applications?
• Alors, qu'en est-il des autres applications qui sont actuellement intégrées à celle-là via la base de données?
• Est-ce la meilleure façon de découpler nos dépendances de base de données ou devrions-nous commencer ailleurs?

Answer 1

Je suggérerais une transition en 3 phases.

1. Ajoutez une couche de messagerie à chacune de vos applications.
2. Modifiez tous les accès aux données inter-applications pour utiliser la nouvelle couche de messagerie.
3. Mettre à l'échelle les bases de données (désormais indépendantes) selon les besoins.

De plus, disons que vous avez 3 applications; A, B et C.

Vous pouvez voir aussi ce que 3 transitions distinctes:

• application A

  • Ajouter messagerie à un
  • changement Appels à A dans B & C

• Application B

  • Ajouter la messagerie à B
  • Modifier appels à B en A & C

• Application C

  • Ajouter messagerie à C
  • changement Appels à C dans A & B

À ce stade du processus, les résultats sont les mêmes qu'à la fin de la phase 2 et la phase 3 peut se poursuivre. La différence est simplement de savoir s'il est plus productif de se concentrer sur un type de refactoring ou de se concentrer sur une application.

Answer 2

La messagerie peut certainement être l'un des moyens les plus élégants. Cependant, cela demande aussi un peu de travail et devra changer au fil du temps à chaque changement de base de données. Nous avons adopté l'approche «plus facile» en demandant simplement à chaque application de se connecter à l'autre base de données, puis d'interroger chaque base de données à partir de là. Nous avons constaté que la plupart des requêtes de base de données croisées sont assez légères et ne posent donc pas de base de code substantielle dans la deuxième application. Il y a une certaine duplication des requêtes select, mais cela a été moins de travail qu'un système de messagerie aurait été.

Tout dépend de la mesure dans laquelle vous allez pousser et tirer des données. Si c'est important, la messagerie est la meilleure solution. Si c'est minime, alors une simple nouvelle connexion à l'autre base de données est peut-être une bonne solution.

Answer 3

Je considérerais également comment les applications utilisent la base de données. Généralement, une base de données (implémentation des deux modèles &) doit appartenir à l'une des deux catégories suivantes: transaction (OLTP) ou reporting (OLAP).

Une base de données transactionnelle bien conçue (et implémentée) devrait fournir d'excellentes performances dans un scénario d'application de type secteur d'activité; de même, une base de données de rapports bien conçue (et implémentée) devrait fournir d'excellentes performances lors de l'interrogation de grandes quantités de données complexes.

Une autre distinction importante est la différence entre «temps réel» et «temps quasi réel». Supposons que vos diverses applications doivent effectuer des opérations transactionnelles (en temps réel) et des rapports sur les données actuelles/anciennes; Vous aurez besoin de deux magasins de données: un stockage transactionnel conçu uniquement pour la vitesse opérationnelle afin de prendre en charge les opérations «en temps réel» des applications, et un autre contenant des données «historiques» qui seront construites uniquement pour le reporting.

L'astuce consiste alors à déterminer combien de données vous devez conserver dans le magasin de données transactionnel et quand/comment le déplacer vers le magasin de données de rapport.