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.

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 +

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. :lol:

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.

Citation:

---

Envoyé par SQLpro

(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)

---

8O

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.

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 +

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

Citation:

---

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...

Citation:

---

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...

Citation:

---

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 +