> En plus, dans 2 ans, si cela rame, il suffit de rajouter un serveur (et de virer la machine la plus ancienne).
Certes, mais attention, la réplic va permettre sans effort :
1- La haute disponibilité tout les accès (lectures et écritures) (le service ne s'interrompt pas si un serveur est en carafe ou en maintenance).
2- La "scalabilité" horizontale des lectures (on ajoute un serveur et hop, le système encaisse plus de selects).
En revanche il ne suffit pas d'ajouter des serveurs pour "scaler" les écritures, car tout les serveurs d'un même cluster doivent recevoir et appliquer toutes les requêtes en écriture (par opposition à la lecture qui peut-être dispatchée entre les machines), que ce soit directement depuis l'applicatif ou depuis un autre serveur du cluster via la réplication.
Pour pouvoir répartir horizontalement les écritures, il faut faire des modifications généralement complexes et couteuses dans le code applicatif afin d'implémenter une forme de partitionnement horizontal/sharding (découper les tables et les assigner à des groupes/clusters de SGBD distincts, et se passer des jointures entre ces données distinctes, gérer les accès aux divers clusters selon le type de données ou les clefs de partitionnement, etc).
Arrivé à ce point, et tant qu'à faire, il peut devenir plus intéressant d'envisager une solution plus moderne (et hype ;) de key-value store ou similaire, naturellement distribué (à la CoucheDB, Tokyo Cabinet et consorts).
[^] # Re: réplication master/master
Posté par herodiade . En réponse au journal Performance MYSQL. Évalué à 1.
Certes, mais attention, la réplic va permettre sans effort :
1- La haute disponibilité tout les accès (lectures et écritures) (le service ne s'interrompt pas si un serveur est en carafe ou en maintenance).
2- La "scalabilité" horizontale des lectures (on ajoute un serveur et hop, le système encaisse plus de selects).
En revanche il ne suffit pas d'ajouter des serveurs pour "scaler" les écritures, car tout les serveurs d'un même cluster doivent recevoir et appliquer toutes les requêtes en écriture (par opposition à la lecture qui peut-être dispatchée entre les machines), que ce soit directement depuis l'applicatif ou depuis un autre serveur du cluster via la réplication.
Pour pouvoir répartir horizontalement les écritures, il faut faire des modifications généralement complexes et couteuses dans le code applicatif afin d'implémenter une forme de partitionnement horizontal/sharding (découper les tables et les assigner à des groupes/clusters de SGBD distincts, et se passer des jointures entre ces données distinctes, gérer les accès aux divers clusters selon le type de données ou les clefs de partitionnement, etc).
Arrivé à ce point, et tant qu'à faire, il peut devenir plus intéressant d'envisager une solution plus moderne (et hype ;) de key-value store ou similaire, naturellement distribué (à la CoucheDB, Tokyo Cabinet et consorts).