IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Autres SGBD Discussion :

Multiple BDD VS Multiple Schema VS Grosse BDD


Sujet :

Autres SGBD

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 43
    Points : 34
    Points
    34
    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
    16 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    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 : 16 792
    Points : 34 013
    Points
    34 013
    Billets dans le blog
    14
    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 Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « 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 bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    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
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 43
    Points : 34
    Points
    34
    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 éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 144
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    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 : 4 144
    Points : 7 388
    Points
    7 388
    Billets dans le blog
    1
    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.
    On ne jouit bien que de ce qu’on partage.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    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
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  7. #7
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Septembre 2006
    Messages
    43
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2006
    Messages : 43
    Points : 34
    Points
    34
    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.

Discussions similaires

  1. [Conception] Traitement des doublons (grosse BDD)
    Par masseur dans le forum PHP & Base de données
    Réponses: 5
    Dernier message: 05/07/2007, 09h59
  2. Multiplication d'une heure récupérée dans la bdd
    Par cyberdevelopment dans le forum Langage
    Réponses: 10
    Dernier message: 18/04/2007, 10h18
  3. Sauvegarde très grosse bdd
    Par creezeer dans le forum Administration
    Réponses: 7
    Dernier message: 27/07/2006, 17h24
  4. Comment peut-on dire : une bdd est petite, moyenne ou grosse
    Par Pierrinot dans le forum Décisions SGBD
    Réponses: 5
    Dernier message: 20/10/2004, 09h40
  5. Remplir une grosse BdD ??
    Par MagicManu dans le forum Outils
    Réponses: 2
    Dernier message: 15/06/2004, 16h01

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo