Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

HSBC, un groupe bancaire, simplifie son modèle de données en passant de 65 bases de données relationnelles à une seule base de données MongoDB
Pour tous les pays

Le , par Bill Fassinou

36PARTAGES

9  1 
La semaine passée, Narasimha Reddy, concepteur de données chez HSBC, un groupe bancaire international britannique, a expliqué comment l'organisation cherche à simplifier son approche de la livraison d'applications en migrant de 65 bases de données relationnelles vers une instance mondiale de MongoDB. HSBC est l'une des organisations de services bancaires et financiers les plus reconnues au monde, opérant dans plus de 60 pays et servant plus de 40 millions de clients. Cependant, cette échelle s'accompagne d'une complexité opérationnelle importante, notamment en ce qui concerne la manière dont la banque fournit ses applications et ses modèles de données.

Reddy a expliqué comment l'image ci-dessous a créé un modèle de données global complexe pour les applications, qui a créé un modèle à coût élevé à chaque étape du cycle de développement logiciel. Cela rend impossible le maintien d'une version de l'application et d'un modèle de données dans le monde des bases de données relationnelles, dit-il.


Reddy a déclaré que HSBC cherchait à réaliser un modèle de données mondial et, par conséquent, une base de données unique pour tous les pays. Les avantages de ceci incluent des coûts réduits, une flexibilité et la possibilité d'exécuter plus facilement des analyses et des rapports mondiaux (chaque pays fonctionnant sur un modèle de données unique).

Dans la pratique, cela signifie que chaque pays sera en mesure de maintenir ses exigences de demande individuelle, mais sans avoir à exploiter une base de données de pays unique. Un modèle de données unique est en cours de création, ce qui permet non seulement d'économiser sur les coûts et les ressources pour HSBC, mais lui donne la liberté de faire avancer sa propre conception de modèle de données.

Comme le montre l'image ci-dessus, HSBC avait un environnement de base de programme d'application, qui avait la plupart des fonctionnalités de base d'une application. Mais il ne pouvait pas avoir un seul environnement de programme en cours d'exécution pour tous les pays, en raison des différences dans les modèles de données et les bases de données.

Selon l'image ci-dessous, HSBC a maintenant une nouvelle architecture selon laquelle plusieurs pays à travers le monde utilisent la même application. C'est maintenant un environnement de service, une base de données et un chemin d'exécution pour tous les pays. Cela est rendu possible grâce au modèle de document de MongoDB et à la possibilité de mapper toutes les différentes exigences de tableau pour chaque pays dans une seule collection, en utilisant des sous-documents. Tout est simplifié en une seule collection en utilisant des identifiants spécifiques au pays.


« Les exigences locales pour chaque pays seront intégrées dans l'application, mais il n'est plus nécessaire de maintenir des modèles de données ou des bases de données distincts. Nous pourrions facilement concevoir le modèle de données global et la base de données en utilisant le modèle de schéma MongoDB JSON. Cela rassemble les données de tous les pays dans une seule base de données et l'application peut fonctionner sur une seule base de données. Ce qui représente beaucoup de réduction des ressources et des coûts de maintenance.

Un autre avantage est d'utiliser la même base de données pour l'analyse des données et les rapports globaux. Nous n'avons pas besoin de traduire dans un autre modèle de données ou une autre base de données pour exécuter l'analyse et les rapports à partir de ces données particulières. Tout cela entraîne de grandes économies de ressources et de coûts. J'ai appris en utilisant MongoDB que lorsqu'une base de données est sans schéma et fournit des requêtes et une indexation puissantes, je pilote la conception de mon modèle de données, pas la base de données », dit-il pour conclure.

Les internautes ne partagent pas le point de vue de Narasimha Reddy. Pour eux, un ensemble de microservices partageant une instance de base de données est un peu un anti-modèle.

Source : Diginomica

Et vous ?

Qu'en pensez-vous ?
Êtes-vous pour ou contre l'utilisation de MongoDB pour un tel projet ? Pourquoi ?
Selon vous, MongoDB est-il adapté pour un tel projet ?
Quel SGBD recommanderiez-vous pour un tel projet et pourquoi ?

Voir aussi

MongoDB 4.4, Atlas Data Lake, Atlas Search et MongoDB Realm aident les entreprises à réduire la prolifération des données et donnent aux développeurs un moyen efficace de travailler avec les données

Après Debian, Red Hat supprime MongoDB de RHEL 8 et Fedora à cause de sa licence SSPL dont le statut de licence libre ou open source est contesté

MongoDB : comment éviter les attaques qui prennent en otage vos données ? Un billet de l'entreprise pour essayer d'endiguer ce phénomène

MongoDB annonce l'abandon d'AGPL pour une nouvelle licence autour de laquelle la désignation open source fait débat

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Waldar
Modérateur https://www.developpez.com
Le 08/07/2020 à 14:01
Dans la méthodologie Merise, le MPD (Modèle Physique des Données) fait suite au MCD. Ensuite viendra le MLD.
Votre source laisse à désirer non ?
4  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 13/07/2020 à 5:16
Bonsoir,

Citation Envoyé par StringBuilder Voir le message
Mise à part si tu parts sur un SGBD NoSQL, ou des fichiers séquentiels indexés ne supportant pas les clés étrangères ou contraintes, le MPD est le même quelque soit le SGBD-R utilisé.
Je ne vois pas quelles "optimisations" ou "spécificités" tu vas y trouver.


StringBuilder, étudiez sérieusement la documentation technique de DB2 for z/OS, et vous changerez d’avis.

En ce sens, Waldar a raison quand il dit :

Citation Envoyé par Waldar Voir le message
Prenez un MCD ou un MLD et générez-le sur Oracle DB ou MS SQL-Server vous verrez bien


Et Waldar dit vrai quand il remet en quelques mots le pendules à l’heure :

Citation Envoyé par Waldar Voir le message

Citation Envoyé par
Dans la méthodologie Merise, le MPD (Modèle Physique des Données) fait suite au MCD. Ensuite viendra le MLD.
Votre source laisse à désirer non ?
Effectivement, Waldar, le loulou que vous mettez en cause n’a pas bien lu les pères de Merise, il est schismatique...

Citation Envoyé par StringBuilder Voir le message
MERISE a été inventé avant le SQL !


Plaît-il ? Merise est née en 1979, voyez la FAQ Merise, dont une partie a été rédigée par un des pères de Merise, Dominique Nanci (qui nous a malheureusement quittés en 2012, RIP) « Historique et origine de la méthode Merise ».

Quant à lui, SQL est né en 1974 (nommé alors SEQUEL), cf. Proceedings of the 1974 ACM SIGFIDET (now SIGMOD) workshop on Data description, access and control - May 1974, Pages 249–264...
L’article des pères de SQL, Chamberlin et Boyce (RIP) : SEQUEL: A structured English query language.

Puisqu’on cause Merise, MCD, MLD, MPD, j’apporte quelques précisions.

Pour l’aspect historique :

En juin 1979, le Centre Technique Informatique de la Mission à l’informatique (Ministère de l’Industrie) publia le fascicule 4 (dont je conserve pieusement un exemplaire), « Guide pratique pour l'élaboration des modèles de données et de traitements », document à considérer par conséquent comme la norme définie pour la modélisation dans le contexte de la mise en oeuvre de la méthode MERISE.



Ce fascicule 4 organise la modélisation des données en 3 étapes :

1. Elaboration du MCD

2. Passage du MCD au MLD

3. Passage du MLD au MPD.


En notant que le MLD est conforme aux concepts préconisés par CODASYL, et ignore donc l’approche relationnelle (présentée en 1969 par E. F. Codd Derivability, Redundancy and Consistency of Relations Stored in Large Data Banks, puis en 1970 avec son article considéré comme fondateur, A Relational Model for Large Shared Data Banks).

Les ouvrages de référence sur Merise ont systématiquement repris ces étapes, tout en prenant en compte la représentation relationnelle au stade MLD.

Un ouvrage de référence (qui ne considère pas le MPD de manière formelle) :

La Méthode Merise Tome 1 Principes et outils (Hubert Tardieu, Arnold Rochfeld, René Colletti)



L’exemplaire dont je dispose date des années quatre-vingts, mais j’ai aussi celui de l’édition de poche (3e tirage, 2003), et les bugs que j’avais repérés il y a 35 ans ont été scrupuleusement reconduits. A titre d’exercice, je vous invite à corriger ceux qui figurent le paragraphe 5.7.3., lequel concerne les règles de passage du MCD au MLD et affirme que le résultat obtenu est prétendument en troisième forme normale, sans donner du reste la définition de celle-ci...

Un autre grand ouvrage de référence, téléchargeable sous forme de PDF :

Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001)



Dans cet ouvrage (sa 4e édition), les auteurs s’intéressent à l’organisation physique des données, mais nous devons être conscients que cette organisation ne peut être considérée qu’en fonction du SGBD utilisé : ne pas en tenir compte a pour conséquence que tout travail de « modélisation physique » ne pourra qu’être repris de A à Z. Mettre en oeuvre un « modèle physique » est du ressort des spécialistes du SGBD utilisé, les DBA (administrateurs des bases de données), on sort donc complètement de Merise pour descendre dans la soute. Disons que vouloir traiter a priori du MPD était acceptable dans le cas des SGBD CODASYL, c’est-à-dire pré relationnels, tels qu’IDS2 et IDMS, mais devient parfaitement vain dans les cas des SGBD relationnels. Ainsi, du temps où je fus DBA DB2, je couvris de notes véhémentes les pages du chapitre 13 de la 3e édition de l’ouvrage en question, « Modèle physique des données et modèle physique des traitements », ne fut-ce que pour les aberrations parsemant ce chapitre. Il est intéressant de noter que — prudence à retardement des auteurs — ce chapitre a totalement disparu dans la 4e édition de l’ouvrage (celle dont la photo est affichée), absorbé par le chapitre 14 de cette dernière édition, intitulé de façon plus neutre, politiquement correcte, « Optimisation des modèles de données ». Il n’en demeure pas moins que mes notes fulminatoires concernant la non pertinence des recommandations faites sont toujours là : remplaçons le contenu des 20 pages de ce chapitre 14 par quelque chose du genre :

La modélisation physique des données est du ressort du DBA, à savoir le spécialiste du SGBD utilisé pour la base de données à mettre en oeuvre. Le DBA prend connaissance des dossiers de conception mis à sa disposition par les chefs de projets, avec qui il entretient un dialogue poussé, lui permettant d’identifier les traitements qui poseront le plus de problèmes de performance, de concurrence d’accès aux données, donc de verrouillage de ces données, donc de blocage des utilisateurs et autres impedimenta. Le DBA produira un prototype lui permettant de surveiller et régler ces problèmes. Tout ceci sort du domaine Merise qui doit se limiter à rester sur le pont et ne pas s'occuper de la soute.


Dans ces quelques lignes, j’ai très succinctement résumé mon activité de DBA chargé de construire les « MPD », avec pénalités financières à la clé, en cas de non respect des engagements contractés avec mes clients quant à la performance. Tout ça depuis le début des années 70, du temps des SGBD pré-relationnels...

Et dans l’activité de DBA, rien n’est jamais acquis ! (voir mon couplet sur la dénormalisation a priori.
En tout cas, quand j’observe par exemple la figure 14.14 de l’ouvrage en ligne, je me dis qu’avec sa solution de relationnel « optimisé » (sic !), l’auteur aurait fait un piètre DBA malgré sa volonté manifeste de bien faire, il aurait fallu qu’on repasse derrière lui pour revenir à une solution de relationnel « non optimisé ».

Et puis dans tout ça, comme dit Waldar, le MPD c’est à la base le DDL, mais il ne s’agit là que de la partie émergée de la base de données, et si vous voulez vous en convaincre, et pour changer de la littérature DB2, plongez-vous dans l’ouvrage de SQLpro : SQL Server 2014 Développer et administrer pour la performance (1200 pages quand même)…
4  0 
Avatar de Waldar
Modérateur https://www.developpez.com
Le 08/07/2020 à 12:31
Citation Envoyé par StringBuilder Voir le message
Mise à part si tu parts sur un SGBD NoSQL, ou des fichiers séquentiels indexés ne supportant pas les clés étrangères ou contraintes, le MPD est le même quelque soit le SGBD-R utilisé.
Je ne vois pas quelles "optimisations" ou "spécificités" tu vas y trouver.
Non pas du tout, ne serait-ce que les types de données, la gestion des clefs primaires et des index, le partitionnement, le code SQL des vues, le stockage des données tout diffère au niveau du MPD.
Prenez un MCD ou un MLD et générez-le sur Oracle DB ou MS SQL-Server vous verrez bien.

Le MPD c'est le code DDL/DML qu'on exécute sur la base pour générer les objets.
3  0 
Avatar de SimonDecoline
Expert confirmé https://www.developpez.com
Le 15/06/2020 à 13:09
Citation Envoyé par SQLpro Voir le message
Comme ça les clients français vont se retrouver mélanger avec les clients des autres pays
Je doute fortement que les ingé de HSBC n'aient pas pensé à ça.

Citation Envoyé par SQLpro Voir le message
et le tout sur un cloud US.....
J'ai peut-être raté un truc mais c'est indiqué où ? Et de toute façon, ça n'a rien à voir : leurs bases précédentes étaient peut-être toutes dans du cloud US ou dans un datacenter US.

Citation Envoyé par SQLpro Voir le message
Donc, la NSA et le FBI pourront avoir accès aux données des comptes bancaires français en toute légalité !
Oui, alors qu'avec Sql Server, ça aurait été beaucoup plus protégé...
4  2 
Avatar de pokap
Membre du Club https://www.developpez.com
Le 15/06/2020 à 14:26
Je me demande comment une banque (qui est - pas hsbc - à l'initiative des BDD relationnel) peut allez vers une bdd comme mongodb.
Parce que la cohérence de donnée ne peut pas être aussi bien assuré, même avec une bonne application maître, et d'après le diagramme ils sont en connexion parallèle dessus donc pas de cohérence. Ou alors ils sont développer des outils satellites pour gérer des problèmes spécifiques.
À moins qu'il fasse de simples écritures de transaction bancaire et quelques workers pour faire des calcules.

En tout cas ça m'intrigue.
2  0 
Avatar de al1_24
Modérateur https://www.developpez.com
Le 15/06/2020 à 15:26
[Hors Sujet]
HSBC et la rigueur des transactions bancaires, c'est toute une histoire.
[/Hors Sujet]
2  0 
Avatar de escartefigue
Expert éminent sénior https://www.developpez.com
Le 06/07/2020 à 20:56
Citation Envoyé par StringBuilder Voir le message
Chez moi un modèle de données, ça vient tout droit de la modélisation MERISE (puis UML), et ça parle du modèle logique (ou physique) des données.
Wikipedia semble d'accord avec moi : https://fr.wikipedia.org/wiki/Mod%C3...e_donn%C3%A9es

C'est à dire des notions abstraites sans aucun rapport avec le support (SGBD, serveur, localisation). Simplement que quelque soit l'application, la base ou le pays, la table "client" est la même (en termes de structure).
D'accord pour le modèle logique (MLD), mais le modèle physique (MPD) est au contraire la déclinaison du modèle logique en fonction du choix du SGBD et des optimisations mises en œuvre par les équipes techniques (DBA notamment).
Par ailleurs, le modèle de données selon la méthode Merise commence en amont, certes facultativement mais c'est très fortement recommandé, car ça évite bien des erreurs, par le modèle conceptuel (le MCD).
2  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 15/06/2020 à 12:32
C'est bien.... Comme ça les clients français vont se retrouver mélanger avec les clients des autres pays et le tout sur un cloud US.....

Donc, la NSA et le FBI pourront avoir accès aux données des comptes bancaires français en toute légalité !

A +
4  3 
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 15/06/2020 à 18:34
Citation Envoyé par Waldar Voir le message
Surtout on n'a pas le contexte sur le type d'application concernée.
Car une banque ça va des comptes bancaires bien entendu aux outils de blogging interne pour les RH.
Oui je ne suis pas sûr de vraiment comprendre l'article.

Est-ce qu'on parle de l'ensemble de TOUTES les données HSBC ?

Dans ce cas je ne serais pas surpris de voir un article dans 2 ans présentant la migration inverse ... (vers SQL Server ou PostGreSQL ou DB2 ou Oracle)

Par contre si les 65 DB représentent en fait un sous-ensemble plus "documentaire" tel que des données marketing client alors oui ok MongoDB unique mais bon ...
1  0 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 15/06/2020 à 18:47
Surtout, y'a un truc que je pige pas trop...

Le titre parle de "modèle de données".
Chez moi un modèle de données, ça vient tout droit de la modélisation MERISE (puis UML), et ça parle du modèle logique (ou physique) des données.
Wikipedia semble d'accord avec moi : https://fr.wikipedia.org/wiki/Mod%C3...e_donn%C3%A9es

C'est à dire des notions abstraites sans aucun rapport avec le support (SGBD, serveur, localisation). Simplement que quelque soit l'application, la base ou le pays, la table "client" est la même (en termes de structure).

Alors que l'article parle de la recentralisation de bases déportées... je ne vois pas la rapport.
D'autant que les modèles de données hétérogènes semble conservés... ce qui va à l'encontre du bon sens dans un tel scénario : si je mets toutes les données au même endroit, c'est pour faciliter leur consolidation... ça commence donc par une harmonisation de leur structure !

Et sinon, pour en revenir à la remarque de SQLPro, HSBC gère des données bancaires, et effectivement, au même titre que les données de santé, la RGPD est très restrictive en termes de stockage de ces données hors UE.
A l'inverse, je doute que les américains acceptent de stocker leurs données bancaires dans un pays communiste tel que la France...

Bref, on parle de leur Facebook d'entreprise, ou de la tenue des comptes bancaires ?
2  1