+ Répondre à la discussion
Affichage des résultats 1 à 7 sur 7
  1. #1
    Invité régulier
    Inscrit en
    septembre 2006
    Messages
    43
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 43
    Points : 9
    Points
    9

    Par défaut 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

  2. #2
    Modérateur
    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    août 2006
    Messages
    14 008
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : août 2006
    Messages : 14 008
    Points : 25 263
    Points
    25 263

    Par défaut

    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.
    Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Autoentrepreneur.
    Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework...
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 769
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 769
    Points : 30 507
    Points
    30 507

    Par défaut

    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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  4. #4
    Invité régulier
    Inscrit en
    septembre 2006
    Messages
    43
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 43
    Points : 9
    Points
    9

    Par défaut

    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.

  5. #5
    Expert Confirmé Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    février 2010
    Messages
    1 988
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2010
    Messages : 1 988
    Points : 3 093
    Points
    3 093

    Par défaut

    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.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 769
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 769
    Points : 30 507
    Points
    30 507

    Par défaut

    Citation Envoyé par StringBuilder Voir le message
    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...

    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 !


    - 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 +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  7. #7
    Invité régulier
    Inscrit en
    septembre 2006
    Messages
    43
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 43
    Points : 9
    Points
    9

    Par défaut

    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

+ Répondre à la discussion
Cette discussion est résolue.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •