Utilisateur:HediMokhtar/Brouillon
Ségrégation des responsabilités de commande et de requêtes
[modifier | modifier le code]La ségrégation des responsabilités de commande et de requêtes (Command-Query Responsibility Segregation ou CQRS) repose sur un principe simple mais peu naturel pour les adeptes des bases de données classiques. Il s'agit de la séparation de la base en lecture et en écriture pour des raisons d'optimisation.
Histoire
[modifier | modifier le code]Le grand principe de CQRS à été introduit par Bertrand Meyer dans son livre Object-Oriented Software Construction. Il a appelé séparation de commande et de requêtes (Command Query Separation ou CQS) un pattern où chaque méthode est soit une commande effectuant une certaine action, soit une requête retournant des données. Les commandes et requêtes sont faites indépendamment les unes des autres. On y retrouve ainsi cette citation faite par lui même : "Poser une question ne devrait pas en changer la réponse". Ce concept fut repris plus tard par Greg Young et Udi Dahan, qui ont fusionné les idées de la conception piloté par le domaine (Domain Driven Design) d'Eric Evans pour créer le pattern CQRS.
Définitions et principes
[modifier | modifier le code]Approche traditionnelle
[modifier | modifier le code]
Dans l'approche traditionnelle, le même modèle est utilisé pour la lecture et l'écriture.
Cependant, la lecture et l'écriture possèdent des besoins différents.
- Lecture : Normalisation des données, cohérence entre elles et besoin transactionnel.
- Ecriture : Besoin de dé-normalisation, de scalabilité (mise à l’échelle) et de performance.
Ceci s'explique par le fait que les données peuvent prendre différentes formes et que leurs mises à jour doivent respecter une norme et des règles précises.
Cependant l'écriture n'est pas autant utilisée que la lecture. La lecture représente 85% des actions faites sur une application contre 15% pour l’écriture. Utiliser le même modèle pour la lecture et l'écriture n'assure donc pas la meilleure optimisation, une approche différent existe.
Approche CQRS
[modifier | modifier le code]
Le principe se trouve dans la division du modèle en deux parties distinctes :
- Commande (command) : Change l'état du système mais ne retourne pas de valeur
- Requête (Query) : Retourne un résultat et ne change pas la structure ou visibilité du système.
Il y a différentes manière d'implémenter une telle interface, les modèles sont sur des processus logiques différents, des matériels différents. La base de données peut être partagée (architecture monolithique) ou unique par modèle (micro-services)
Relation avec l'event sourcing
[modifier | modifier le code]Le pattern CQRS peut être étendu et complété en y appliquant un certain nombre d'autre patterns. De ce fait, CQRS observe une très bonne synergie avec l'event sourcing.[3]
"Event Sourcing : stop thinking of your datas as a stock but rather as a list of events…" [4] qui signifie, "Arretez d'imaginer vos bases de données comme des réserves mais plutôt comme une liste d'événements..."
Inconvénients
[modifier | modifier le code]L'approche CQRS n'est pas adaptée à tous les problèmes, il ne faut pas utiliser CQRS sur tout le système mais uniquement sur une portion en général.
Cette approche est surtout adaptée aux systèmes où le nombre de requêtes est bien plus important que le nombre de commandes de création ou modification. Ceci est valable pour n'importe quel système d'informations standard. Par exemple un site d'achat en ligne, où le nombre de consultations des articles est bien plus grand que le nombre d'achats ou de mises en vente.
Lagom
[modifier | modifier le code]Lagom est un mot suédois signifiant "Strict minimum" et c'est aussi un framework mettant tout en oeuvre pour s'éloigner d'un système monolithique et tendre vers un système de micro-services.
Axon
[modifier | modifier le code]Axon est fait pour faciliter la vie des personnes souhaitant développer à l'aide du pattern CQRS.
Exemples existants
[modifier | modifier le code]Dans le milieu médical[5]
[modifier | modifier le code]Dans cette partie sera illustrée plusieurs exemples où il sera possible d'observer l'effet du Pattern CQRS, il y aura une mise en contexte, le passage d'une base de donnée classique en base de donnée CQRS et l'analyse de cette migration.
Cette étude a été réalisée sur la base de données principale de medis.NET de la ville de Nis en Serbie, cette base de données contient 348 tableaux de données et l'instance utilisée est un exemple collecté d'un an d'utilisation d'une taille de 5,5 GB de données. (ce qui sera suffisant pour différentes analyses)
Dans la ville de Nis il y a 430000 habitants, en 1 an dans le centre médical principale de la ville, on observe 2,25 millions de visite et 3,4 différents types d'examen. Il est intéressant de voir que le plus grand nombre de visite pour un seul patient est de 748 et que 230000 habitants n'ont pas été à la clinique de l'année.
Pour chaque visite, l'utilisateur du système médical passe par le même ensemble de formulaires où les données de nombreuses tables sont collectées, jointes et affichées. Les médecins accèdent au formulaire d'admission. À partir de ce formulaire, ils peuvent soit commencer immédiatement une nouvelle visite, soit, ce qui est beaucoup plus fréquent, ouvrir le dossier médical du patient contenant un large éventail de données différentes mais rarement modifiées. L'intention de cette expérience était de déplacer ces données, autant que possible, dans la base de données de lecture et de stocker dans les tables créées par dé-normalisation de la structure de la base de données principale. En ce qui concerne la structure et les activités actuelles de la base de données, il a été décidé de commencer par les données démographiques et administratives étant donné que son taux de changement est très faible. (Tableau suivant)
| Table | nombres de ligne | Ajout/Modification/Délétion |
|---|---|---|
| Patient | 431567 | 17335 (4%) |
| Dossier médical | 360234 | 10170 (2,8%) |
| Visites | 1885030 | 78434 (4,1%) |
| Assurance | 460333 | 55635 (12%) |
La figure 2 montre le formulaire d'admission. Une fois le patient sélectionné, le formulaire d'admission s'affiche. Dans plusieurs zones les données de base (voir Figure 1) relative au patient sont affichées (nom, adresse, date de naissance...). Ces informations sont dispersées dans 5 tables différentes et sont très rarement changé. Le fait qu'elles soient rarement changées les rend candidates au déplacement dans une base de donnée de lecture uniquement nommée "ReadPatientData". On réitère ce genre d'analyse pour trouver des données que l'on bougera en lecture uniquement.
De même pour les autres formulaires existant (Figure 2). Certaines données comme l'assurance sont uniquement accessible en lecture. Après avoir repérer toute nos bases de données en lecture, on analyse la différence du temps d’exécution et de la consommation de mémoire avant et après la création des bases de données de lecture.
Le tableau suivant montre l'effet de l'utilisation des tables de lecture inspiré de la Figure 1 dans la base de données:
| Le nombre d'utilisation de table de lecture | Temps de réponse moyenne (en secondes) | Montant moyen de données brutes chargées dans la base de données |
|---|---|---|
| Aucune | 1,243 | 32296 |
| 1 | 0,961 | 21553 |
| 1,2 | 0,774 | 11658 |
La table 1 correspond à ReadPatientData et la table 2 à ReadScheduledForm
On effectue la même opération pour le dossier médical de la Figure 2 et les tables de base de données associées, voici les résultats :
| Le nombre d'utilisation de table de lecture | Temps de réponse moyenne (en secondes) | Montant moyen de données brutes chargées dans la base de données |
|---|---|---|
| Aucune | 1,927 | 12,858 |
| 1 | 1,675 | 11,026 |
| 1,2 | 1,674 | 11,027 |
| 1,2,3 | 1,509 | 7,182 |
| 1,2,3,4 | 1,416 | 4,971 |
Table 1 : ReadPatientData, 2: ReadElectronicPatientRecord, 3: ReadInsurance, 4: ReadEmployment
On remarque ainsi que pour certaine table il y a un temps d'amélioration conséquent, et pour d'autre non.
Bibliographie
[modifier | modifier le code]- « Lagom : Reactive microservice framework », {{Article}} : paramètre «
périodique» manquant, (lire en ligne, consulté le ) - « Lagom : Reactive microservice framework », {{Article}} : paramètre «
périodique» manquant, (lire en ligne, consulté le ) - (en) Jaap Kabbedijk, Slinger Jansen, Sjaak Brinkkemper, « A case study of the variability consequences of the CQRS pattern in online business software. », EuroPLoP, , p. 10
- « Event Sourcing & noSQL | OCTO talks ! », sur blog.octo.com (consulté le )
- (en) Petar Rajkovic, Dragan Jankovic, Aleksandar Milenkovic, « Using CQRS Pattern for Improving Performances in Medical Information Systems. BCI (Local) 2013: 86 », BCI (Local): 86, , p. 10