1. #1
    Membre habitué Avatar de bluemartini
    Profil pro
    Inscrit en
    avril 2006
    Messages
    154
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2006
    Messages : 154
    Points : 168
    Points
    168

    Par défaut Réplication seule ou MySQL Cluster?

    Bonjour,

    depuis peu je me lance dans un projet qui se résume à utiliser des bases de données un peu énormes (~2 To pour commencer)
    Le but est de proposer une architecture qui soit au maximum disponible car elle va être utilisée par la suite par un nombre important d'utilisateurs, avec des requêtes se composant sur quelques centaines de milliers de lignes chacunes. Ces bases soont assez bien pensées, avec pas mal d'indexs et de clés primaires.
    L'idée au départ a été de me tourner vers MySQL Cluster. Le budget n'étant pas non plus extensible à volonté (40000€ environ), il est inconcevable que je me tourne vers des noeuds demandant chacuns 128Go de RAM ...
    J'ai vu aussi la solution d'utiliser tout bêtement un système de réplication maître-plusieurs esclaves. Etant donné que la majeure partie du temps l'activité sera de la consultation et non pas de la lecture, cette solution me semble fiable.
    Cependant, je suis un peu novice pour ces considérations, et je commence à éplucher pas mal de docs.
    Ma question est la suivante : auriez vous une "méthodologie" à me conseiller? des ouvrages de qualité? Des avis éclairés? une expérience déjà passée?

    Merci beaucoup.

  2. #2
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 334
    Points : 40 140
    Points
    40 140
    Billets dans le blog
    1

    Par défaut

    Commencez par répondre à la question suivante :
    voulez-vous faire une solution de haute disponibilité ou bien simplement absorber la charge d'un grand nombre d'utilisateurs ?
    Si réponse 1 alors vous pouvez étudier la réplication (complexe et forte administration à prévoir) ou bien le mirroring (mais je ne pense pas que MySQL sache le faire, il faudra une solution externe genre double take), solution beaucoup plus simple, mais coût élevé du module de mise en miroir.
    SI réponse 2, donnez nous le nombre des utilisateurs prévus. Si c'est inférieur à 30 000 utilisateurs simultané, orientez vous vers des SGBDR plus sérieux, genre Oracle ou SQL Server. EN effet, même si les licences sont chères, cela vous évitera de payer de nombreuses machines pour une solution de SGBDR soit disant gratuite (MySQL contrairement à une légende n'est pas gratuit puisqu'il impose soit de payer en monnaie sonnante et trébuchante, soit en livrant son code à l'éditeur MySQL AB récemment racheté par SUN).

    Sachez enfin qu'il existe des solutions autres que MySQL qui intègrent le mirroring de bases de données comme par exemple SQL Server (aucun surcout de licence).

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  3. #3
    Membre habitué Avatar de bluemartini
    Profil pro
    Inscrit en
    avril 2006
    Messages
    154
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2006
    Messages : 154
    Points : 168
    Points
    168

    Par défaut

    Merci de ta réponse.
    Effectivement, j'avais la possibilité d'utiliser des systèmes tels que DB2. Le problème est que je n'ai pas le choix, car l'ensemble des applis développées dans mon entreprise tournent sous ...MySQL.

    Le nombre de requêtes simultanées va se situer en deçà de 30000. Je table plutôt sur quelques centaines. Comme actuellement les serveurs dédiés à chaque application donnent des temps de réponse de plusieurs dizaines de seconde par requêtes (et que la volonté ici est la "simultanéité"), le système de morcellement de MySQL Cluster m'intéressait beaucoup.

  4. #4
    Provisoirement toléré Avatar de Maximilian
    Profil pro
    Inscrit en
    juin 2003
    Messages
    2 622
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2003
    Messages : 2 622
    Points : 2 970
    Points
    2 970

    Par défaut

    Citation Envoyé par SQLpro Voir le message
    (MySQL contrairement à une légende n'est pas gratuit puisqu'il impose soit de payer en monnaie sonnante et trébuchante, soit en livrant son code à l'éditeur MySQL AB récemment racheté par SUN)


    Heu ce n'est pas tout à fait ça, en fait MySQL propose un système de double licence : soit payante (MySQL Enterprise), soit GPL (ce qui "contamine" l'application utilisant MySQL ou ses pilotes, l'obligeant à être GPL elle aussi).

    Par ailleurs l'utilisation de MySQL en tant que serveur de base de données d'un site Web n'est à priori pas soumise aux règles de cette double licence.
    Pensez au bouton

  5. #5
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 334
    Points : 40 140
    Points
    40 140
    Billets dans le blog
    1

    Par défaut

    Bluemartini, la question fondamentale est : qu'est ce qu'un cluster va m'apporter par rapport à mes attentes...
    Voulez-vous du fail over ? C'est à dire une solution de continuité de service (une machine tombe en panne et une autre prends le relais)
    ou bien voulez-vous assumer une charge plus importante ? C'est à dire prévoir une "scalabilité" ? (dans ce cas il faut commencer par faire du scale up avant de faire du scale out).

    S'il s'agit de plusieurs bases indépendantes, alors plusieurs serveurs peuvent coopérer.

    Bref votre demande confond un peu tout et manque de précision...

    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

  6. #6
    Membre habitué Avatar de bluemartini
    Profil pro
    Inscrit en
    avril 2006
    Messages
    154
    Détails du profil
    Informations personnelles :
    Âge : 37
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : avril 2006
    Messages : 154
    Points : 168
    Points
    168

    Par défaut

    Merci pour ta réponse,

    Je m'excuse de ce manque de clarté de ma part. Je trouve difficile de faire figurer dans un post toutes les considérations qui m'ont amenées à étudier les deux systèmes.

    Le but étant de fournir un service constant, le fail over est une notion très importante pour moi. Mais si j'utilise un système de réplication, je me trouve aussi dans l'obligation d'utiliser un load balancer, qui me permettra de gérer aussi le fail over.
    En fait, le système le plus gourmand en "ressources" est un système de visualisation qui affiche des informations contenues sur des centaines de milliers de lignes. Ceci amène à considérer l'affichage de plusieurs dizaines de graphes contenant chacuns plusieurs millions de points en abscisse. Ces informations sont dispersées à travers plusieurs bases de données, avec chacunes plusieurs dizaines de tables.Cet affichage doit être rapide car il ne sert en rien de résultat mais plutôt de moyen de recherche. Il faut donc s'attendre à beaucoup de rafraichissement avec de nouvelles conditions. Il faut considérer un nombre d'utilisateur de l'ordre d'une centaine en simultané au maximum.
    Pour l'instant il m'est difficile de chiffrer le volume que va représenter l'ensemble des clés primaires, car je n'ai pas à disposition la totalité de ces bases. Les écritures vont représenter moins du 5% du temps d'exploitation.
    Donc, je pense que l'accent est à mettre sur la disponibilité des machines et la rapidité d'accès aux données.
    La solution du cluster me plaisait bien dans le sens où on peut gérer la disponibilité de chaque table à travers les noeuds, et proposer de ce fait une parallélisation des requêtes. Ce qui me dérange, c'est le fait de ne pas savoir quel volume en mémoire RAM cette solution va demander.
    C'est pourquoi j'étudie aussi la solution de réplication, en mettant le paquet sur la rapidité de chaque serveur. Ce qui me permettrait d'avoir au moins une meilleure disponibilité.

    Encore merci pour vos réponses

  7. #7
    Rédacteur
    Avatar de SQLpro
    Homme Profil pro
    Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Inscrit en
    mai 2002
    Messages
    17 334
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert SGBDR & SQL, spécialiste Microsoft SQL Server
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 17 334
    Points : 40 140
    Points
    40 140
    Billets dans le blog
    1

    Par défaut

    Le but étant de fournir un service constant, le fail over est une notion très importante pour moi. Mais si j'utilise un système de réplication, je me trouve aussi dans l'obligation d'utiliser un load balancer, qui me permettra de gérer aussi le fail over.
    La réplication est adaptée à la répartition de charge, pas à la solution de continuité. En effet, l'intérêt principal de la réplication est de permettre de répliquer une partie des données (partitionnement vertical ou horizontal ou les deux) et non toute une base. La réplication d'une base complète est stupide car elle consomme énormément de process alors que d'autres techniques existent. Autrement dit on plombe les serveurs pour des tâches inappropriées...
    Vous pouvez donc répartir la charge en partitionnant différents serveur par domaines fonctionnels et ne conserver que quelques tables partagées...


    En fait, le système le plus gourmand en "ressources" est un système de visualisation qui affiche des informations contenues sur des centaines de milliers de lignes. Ceci amène à considérer l'affichage de plusieurs dizaines de graphes contenant chacuns plusieurs millions de points en abscisse. Ces informations sont dispersées à travers plusieurs bases de données, avec chacunes plusieurs dizaines de tables.Cet affichage doit être rapide car il ne sert en rien de résultat mais plutôt de moyen de recherche.
    La question est, les données extraites doivent-elles être scalaires ou doivent elles être agrégées ? Si c'est scalaire (c'est à dire autant de données que de ligne) il n'y a pas d'autre possibilité que de dimensionner de grands serveurs. Si ces données sont agrégées (par exemple SUM, COUNT, AVG...) alors il est possible dans certains SGBDR d'utiliser des vues indexées (automatiques dans SQL Server) ou des vues matérialisées (manuelles dans Oracle, DB2). En fait les calculs sont préstockées au fil de l'eau (version automatique) ou calculées par batch (version manuelle). Ceci permet des temps de réponse fulgurants (division par plus de 1000 par rapport aux versions scalaires).
    C'est par exemple ce que nous avons utilisé sur homelidays.com et qui permet de donner en permanence le nombre d'offre de location vacance libre sur un pannel de plusieurs centaines de milliers combiné par des plages de période à l'infini... Observez les temps de réponse à l'usage...

    La solution du cluster me plaisait bien dans le sens où on peut gérer la disponibilité de chaque table à travers les noeuds, et proposer de ce fait une parallélisation des requêtes
    A moins que vous ne fassiez deux requêtes distinctes un système de cluster ne parallélisera pas sur deux UC différente une même requête !

    Bref je pense que vous vous orientez vers de mauvaises solutions, qui plus est couteuses, pas tellement en terme de de licence, mais surtout en terme d'administration et conception.
    Sachez que le salaire d'un dba c'est bien plus qu'une simple licence !!!
    Et qu'il vaut mieux utiliser une solution adaptée plutôt que d'utiliser un SGBDR qui ne correspond pas aux volumes et fonctionnalités attendues.


    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...
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Discussions similaires

  1. REPLICATION => MYSQL CLUSTER
    Par overider dans le forum SQL Procédural
    Réponses: 1
    Dernier message: 06/09/2009, 02h31
  2. Mysql-Replication et UPDATE / Mysql-Cluster et Lock
    Par X_Cli dans le forum Requêtes
    Réponses: 6
    Dernier message: 17/01/2008, 21h00
  3. MySQL Cluster redondé
    Par zerros dans le forum Administration
    Réponses: 0
    Dernier message: 09/12/2007, 00h58
  4. réplication bi-directionnelle MySql <->MS SQL
    Par cosminutza dans le forum SQL Procédural
    Réponses: 4
    Dernier message: 13/09/2005, 16h19
  5. Réplication Postgresql Master -> Mysql Slave
    Par livingdead dans le forum PostgreSQL
    Réponses: 6
    Dernier message: 11/02/2005, 16h29

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