Discussion :

[fasyr]

Bonjour,

Je suis actuellement sur un projet, Il s'agit de penser une architecture serveur de bases de données. Je m'explique :

Il me faudrait une architecture qui me permette de gérer un grand nombre de BDD (180 000) sur un seul serveur. Chaque BDD représente un client dans lesquelle se trouvent des table contenant des données sur le client en question. Chaque BDD contiendra un petit volume d'information autant dire que chaque BDD ne sera pas grande en taille disque.
Les données de ces BDD seront accessible par le biais d'une page web accessible sous login. En fonction du login l’accès a une des BDD sera possible.

Je cherche donc une architecture optimale pour ce genre de problématique. Sachant que les moteur à notre disposition sont Mysql Classique édition, standard édition et entreprise édition.

Je pensais à de la virtualisation de serveur de BDD qu'en pensez vous ?

[punkoff]

bonjour,

pourquoi faire une bdd par client ..? au lieu d'une table client avec 180k lignes dedans ..?

[fasyr]

Bonjour et merci de ta réponse,

En fait c'est le cahier des charges qui est définit comme ça. Je penses que c'est plus tournée vers des notions de sécurité qu'autre chose et je dois composé avec.

[tse_jc]

Bonjour,


Permettez-moi avant de vous répondre de réagir à votre cahier des charges. Pour moi il s'agit une fois de plus d'une architecture applicative pilotée par un serveur tiers dans laquelle la logique d'utilisation d'une base de données pour faire de la persistance de classe est poussée à l'extrême, avec en prime une pointe de paranoïa mal placée.

A moins que ce cahier des charges ait été conçu pour un cas d'école, il n'est pas viable en production bien que réalisable.

Pourquoi?
A) Au niveau infrastructure
Cela oblige à surdimentionner les ressources, tant au niveau des espaces disques, que mémoire et des I/O.
Le coût d'infrastructure va donc être élevé pour un choix injustifié.

B) Au niveau applicatif
- De la BDD
Le choix de MySQL est un mauvais choix car pour MySQL une BD=un schéma ce qui n'est pas standard et qui va empêcher les jointures entre BD (contexte BD épaisse). Il faudrait pouvoir travailler au moins sur postgres de façon à faire un schema par client, ce qui serait beaucoup plus raisonnable et aussi plus sécuritaire. Je ne développe pas plus ici mais il y aurait énormément de choses à dire, et le but n'est pas de vous faire un cours magistral non plus.

- Au niveau du serveur tiers
Votre CDC se place donc dans un contexte ou le serveur tiers gère à la fois les accès serveur(s) et les accès applicatif. Cela oblige à coder en dur au niveau du serveur tiers les accès utilisateurs à l'applicatif ainsi que le mapping des identifiants utilisateurs avec l'identifiant applicatif BD respectif.
Le pool de connections serveur tiers/BDD risque d'être important selon le contexte de production et risque de générer également des coûts d'infrastructure inutiles.
De stocker tout cela au niveau serveur tiers, ne consolide pas la sécurité de l'applicatif mais bien au contraire l'expose davantage et rends la maintenance de gestion des accès plus ardue.

Voilà un résumé de l'essentiel.

j'espère avoir pu vous aider.

Jc.

[SQLpro]

Effectivement archi débile au plus haut point et suicidaire. Celui qui à pondu un tel cahier des charges est un ignare qui ferait mieux de se reconvertir en balayeur que de persister dans le métier de l'informatique.

Irréaliste en sus, car 180 000 base sur une même serveur, à raison par exemple de 10 tables par base, ce sera quelques 2 millions de fichiers ouverts donc pensez à prévoir 800 Go de RAM juste pour lire les descripteurs de fichiers....
En effet, en sus d'être l'un des plus mauvais SGBD MySQL à la manie imbécile (comme hélas PostGreSQL) de créer autant de fichiers (plus d'un d'ailleurs) pour chaque table créée !

A +

[fasyr]

Bonjour,

Merci de vos réponse et commentaires, en effet le schéma de bdd n'as pas été réfléchie mais malheureusement il est bien existant d'ou le fait de composer avec.
Nous nous retrouvons à l'heure actuelle avec un logiciel initial "A" qui fonctionne sous mysql est qui est déjà fonctionnel.Il permet une publication qui crée une base BaseDossier1 qui contient des données du logiciel "A" ceci dans le but de permettre un affichage d'information tournée web sur une base identifiable pour un dossier spécifique.

Nous ne somme jamais tombé (et bien sur par manque de réflexion en amont) sur la problématique d'un client qui voudrais potentiellement voir tout ces dossier du logiciel "A" publier sur le web (donc la création de x base de données BaseDossierx).

Le pire dans tout cela c'est que certain vue de la publication web ont besoin d'informations qui sont sur la base principale du logiciel "A" (donc une jointure base BaseDossierx et BaseLogicielA) et d'ou le fait qu'a l'heure actuelle nous somme sur un fonctionnement ou toutes les base (BaseClix et BaseLogicielA) sont sur le même serveur.

Mais la demande du client qui veut une publication de touts ses ne nous permet pas de fonctionner sur un seul serveur et la je cherche une solution (si il en existe) à partir de cet existant pour répartir les charge de ces différentes base sur plusieurs serveur mysql tout en maintenant les contraintes énoncées plus haut.

Voila Ou j'en suis, je ne cherche pas de solution miracle mais une solution première qui me permettrait de maintenir se fonctionnement dans l'attente de passer sur une conception différente mieux pensée


Merci a tous

[tse_jc]

Bonjour,

Que c'est bien triste de constater une fois de plus l'état de certaines applications en production...

Encore une fois, car on ne le répète jamais assez, une application métier n'est rien autre qu'un outil de gestion de données selon des règles et contraintes spécifiques, et non pas un outil dans lequel l'information est considéré comme la dernière roue du carrosse. Et un serveur objet n'est pas conçu pour gérer cela comme il se doit.

avec un logiciel initial "A" qui fonctionne sous mysql est qui est déjà fonctionnel

Je n'appele pas cela être fonctionnel, il faut bien le reconnaître.

Bref, le meilleur conseil que je puisse vous donner, c'est d'arrêter l'hémorragie et de redévelopper l'application en commençant par une maîtrise d'ouvrage qui se respecte (avec un MCD, etc...).
La bonne nouvelle c'est qu'en faisant ainsi vous devriez réduire la taille du code applicatif par 4.

Bonne continuation et surtout bonne chance!

++

[SQLpro]

J'adore ce genre d'architecture ou les gens s’enferrent dans leurs décision de la plus haute stupidité...
A terme le système merdera à un tel point que tous les clients seront insatisfait et vous serez obligé de changer dans l'urgence, avec selon toute probabilité la faillite de la boite.... si elle repose essentiellement sur cette application !

Mais continuez dans votre lancée... Cela permettra à des intervenants externes de vendre leurs service au prix fort pour vous venir en aide. Bref du pain béni pour les gens comme moi !

A +