Multiple BDD VS Multiple Schema VS Grosse BDD

Bonjour,

La question a dû être posée, mais malheureusement aucune ne répond à ma problématique.

Nous devons ré-écrire en interne une application pour nos 450 points de vente, nos utilisateurs se connectent sur nos serveurs Microsoft TSE en RDP,
chacun de ces points de vente est regroupé en région(40 régions).

Donc pour résumer 1500 users, répartis sur 450 points de ventes regroupés en 40 régions.

Nous hésitons aujourd'hui sur l'architecture de la base de données entre :

- Un seul serveur avec une grosse BDD
- Un seul serveur avec une BDD mais 40 schémas (40 régions)
- 40 serveurs avec 40 plus petites BDD

Aujourd’hui nous avons 40 serveurs Sybase, chacun des serveurs fait en moyenne 80 requêtes par seconde.

A votre avis quelle est la meilleure solution pour notre problématique et quelle BDD choisir ?

Merci Stéphane

Une seule BDD sur un seul serveur est la solution la plus simple. Surtout que, si je comprends bien, les 40 serveurs actuels ont la même architecture de données ?

Les SGBD sont faits pour traiter de gros volumes de données. Un seul schéma pour tous ; inutile de faire X fois le même schéma.

sans compter la multiplication des tables... 40 schémas avec les mêmes tables c'est stupide. En cas de modif de la structure d'une table il faudra se payer 40 ordres ALTER TABLE !!!!

En sus 40 serveur => 40 licences, 40 machines, 40 OS !!!

Avec une seule base vous pourrez vous payer le luxe d'une solution de haute dispo genre mirroring chez MS SQL Server pour moins cher que ne vous aurait couté la mise en œuvre, vu que chez MS la haute dispo n'ouvre pas droit à paiement de licence supplémentaires !!!!

A +

Merci pour vos réponse.

Effectivement nos 40 BDD actuels ont exactement la même structure.
Pour la maintenance des base nous avons un outils qui s'occupe de mettre à jour la structure sur les X base de données, avec rapport d'erreurs etc...

Je sais trés bien qu'aujourd'hui les serveurs BDD sont faite pour gerer des bases de xTo. Mon intérogations se porte sur l'acces (en lecture) à un même enregistrement par potentielement 400 users en même temps, il y aura t'il une grosse latence.

Aujourd'hui nos 40 serveurs supporte chacun d'eux en moyenne 80 req/sec ( insert, update, select), donc potentiellement 3200 req/sec avec une seul BDD.

Aujourd'hui il y a plein d'inconvenient avec 40 serveurs mais également plein d'avantages (Sauvegarde en qq minutes, remonter de sauvegarde en qq minutes, risque reduits).

J'aimerais sincerement trouver quelqu'un capable de m'assurer qu'une grosse BDD et mieux que 40 petites pour les utilisateurs finaux. Car il est clair que coté developpeurs 1 BDD c'est mieux, mais nous faisons des outils pour les utilisateurs et non pour nous.

Bref je recherche un expert BDD sans appriorie sur ORACLE / SQL SERVER / SYBASE / DB2.

Le problème du prix des licences n'est pas un reel problème.

Bonjour,

En ce qui concerne le partage des lectures, ça ne devrait pas poser trop de problèmes.
Même au contraire : un "gros" serveur sera dimensionné en conséquence, et de facto, aura plus de place en mémoire pour :
- Stocker les données de travail
- Stocker les plans d'exécution
- Stocker les index

De ce fait, là où 40 petits serveurs vont tous charger la même chose chacun de le côté, le gros serveur ne chargera la même chose qu'une seule fois. S'il est dimensionné ne serait-ce que 2 fois plus gros, alors il aura plus de place pour charger d'autres choses que les petits serveurs n'auront pas pu conserver en mémoire, faute de place.

Par conséquent, certaines requêtes ou traitements qui prennent du temps en ce moment pourrait bien être plus rapide sur le gros serveur, même s'il y a plus de monde qui les lance !

En revanche, attention aux locks.

Essayez de réduire au maximum :
- le volume de données mises à jours par les utilisateurs (genre quand un utilisateur modifie un client, éviter d'aller modifier l'ensemble des commandes liées)
- la durée des transactions (en effet, plus une transaction dure longtemps, plus le risque de tentative de lecture de données en cours de mise à jour est important). Évitez par exemple de poser un lock exclusif sur une table quand vous entrez dans un écran par exemple. Car même si c'est stipulé que vous faites un lock à la ligne, par défaut SQL Server fera un lock à la page, ce qui peut compter plusieurs dizaines de lignes

D'un point de vue fonctionnel, j'ai en revanche une question :
- Actuellement, chaque région travaille sur son serveur dans son coin. Les données sont-elles répliquées d'un serveur à l'autre (que ce soit le référentiel ou les données de travail) ?
En effet, si chaque région a son propre panel de données, alors tout mettre dans la même base signifie qu'il va falloir :
- Gérer correctement la séparation des données d'une région à l'autre, ce qui n'est peut-être pas le cas actuellement
- Gérer correctement les droits (non seulement il faut pouvoir filtrer, mais il faut peut-être empêcher un PDL du nord d'aller voir les stocks d'un PDL de la côte d'azur.

S'il y a vraiment une séparation des données, alors peut-être que multiplier les schema sera une chose à étudier : un schema par région. Sinon, ça va vous demander pas mal de travail pour gérer cette séparation.

Citation:

---

Envoyé par StringBuilder

Bonjour,

En ce qui concerne le partage des lectures, ça ne devrait pas poser trop de problèmes.
Même au contraire : un "gros" serveur sera dimensionné en conséquence, et de facto, aura plus de place en mémoire pour :
- Stocker les données de travail
- Stocker les plans d'exécution
- Stocker les index

De ce fait, là où 40 petits serveurs vont tous charger la même chose chacun de le côté, le gros serveur ne chargera la même chose qu'une seule fois. S'il est dimensionné ne serait-ce que 2 fois plus gros, alors il aura plus de place pour charger d'autres choses que les petits serveurs n'auront pas pu conserver en mémoire, faute de place.

Par conséquent, certaines requêtes ou traitements qui prennent du temps en ce moment pourrait bien être plus rapide sur le gros serveur, même s'il y a plus de monde qui les lance !

En revanche, attention aux locks.

---

C'est de loin le point le plus important...

Citation:

---

Essayez de réduire au maximum :
- le volume de données mises à jours par les utilisateurs (genre quand un utilisateur modifie un client, éviter d'aller modifier l'ensemble des commandes liées)

---

Pour cela il est très important d'avoir des petites tables en terme de nombre de colonnes (20 max, mais vaut mieux moins de 8..., voir article à ce sujet : http://blog.developpez.com/sqlpro/p1...mances_petites) et surtout bien les indexer. En effet et contrairement à une idée reçue, les index réduisent la granularité du verrouillage et la durée des transactions !

Citation:

---

- la durée des transactions (en effet, plus une transaction dure longtemps, plus le risque de tentative de lecture de données en cours de mise à jour est important). Évitez par exemple de poser un lock exclusif sur une table quand vous entrez dans un écran par exemple. Car même si c'est stipulé que vous faites un lock à la ligne, par défaut SQL Server fera un lock à la page, ce qui peut compter plusieurs dizaines de lignes

---

Ceci n'est plus vrai au sujet de SQL Server depuis la v2005 ou la tendance au verrouillage de ligne est forte, A CONDITION D'AVOIR LE BON INDEX !

A +

Merci à tous d'avoir répondu à mes intérogations et bien plus encore.
Le liens concernant la taille des tables en termes de colonnes m'à été tres utile.

Cordialement

Stéphane