Architecture de base de données maître-maître vs maître-esclave?

J'ai entendu parler de deux types d'architectures de base de données.

• maître-maître

• Maître d'esclave

Le maître-maître n'est-il pas plus adapté au web d'aujourd'hui car c'est comme Git, chaque unité a l'ensemble des données et si l'une d'entre elles tombe en panne, cela n'a pas vraiment d'importance.

Le maître-esclave me rappelle SVN (que je n'aime pas) où vous avez une unité centrale qui gère les choses.

Des questions:

1. Quels sont les avantages et les inconvénients de chacun?

2. Si vous souhaitez avoir une base de données locale dans votre téléphone mobile comme l'iPhone, laquelle est la plus appropriée?

3. Le choix de l'un de ces éléments est-il un facteur critique à considérer à fond?

Nous négocions disponibilité, cohérence et complexité. Pour répondre d'abord à la dernière question: est-ce important? Oui beaucoup! Les choix concernant la façon dont vos données doivent être gérées sont absolument fondamentaux, et il n'y a pas de «meilleure pratique» pour éviter les décisions. Vous devez comprendre vos besoins particuliers.

Il y a une tension fondamentale:

Une copie: la cohérence est facile, mais si elle est en panne, tout le monde est hors de l'eau, et si les gens sont éloignés, ils peuvent payer des frais de communication horribles. Apportez des appareils portables, qui peuvent devoir fonctionner déconnectés, dans l'image et une copie ne la coupera pas.

Master Slave: la cohérence n'est pas trop difficile car chaque élément de données a exactement un maître propriétaire. Mais alors que faites-vous si vous ne pouvez pas voir ce maître, une sorte de travail reporté est nécessaire.

Master-Master: eh bien si vous pouvez le faire fonctionner, il semble tout offrir, pas de point de défaillance unique, tout le monde peut travailler tout le temps. Le problème avec ceci est qu'il est très difficile de préserver une cohérence absolue. Consultez l' article de wikipedia pour en savoir plus.

Wikipédia semble avoir un bon résumé des avantages et des inconvénients

Avantages

• Si un maître échoue, les autres maîtres continueront à mettre à jour la base de données.

• Les maîtres peuvent être situés dans plusieurs sites physiques, c'est-à-dire répartis sur le réseau.

Désavantages

• La plupart des systèmes de réplication multi-maîtres ne sont que faiblement cohérents, c'est-à-dire paresseux et asynchrones, violant les propriétés ACID.

• Les systèmes de réplication désireux sont complexes et introduisent une certaine latence de communication.

• Des problèmes tels que la résolution de conflits peuvent devenir insolubles à mesure que le nombre de nœuds impliqués augmente et que la latence requise diminue.

Tout en recherchant également les différentes architectures de bases de données. J'ai compilé un bon nombre d'informations qui pourraient être pertinentes pour quelqu'un d'autre effectuant des recherches à l'avenir. Je suis tombé sur

1. Réplication maître-esclave
2. Réplication maître-maître
3. Cluster MySQL

J'ai décidé de me contenter d'utiliser MySQL Cluster pour mon cas d'utilisation. Cependant, veuillez voir ci-dessous les différents avantages et inconvénients que j'ai compilés

1. Réplication maître-esclave

Avantages

• Les applications analytiques peuvent lire à partir du ou des esclaves sans impact sur le maître
• Sauvegardes de l'ensemble de la base de données sans impact sur le maître
• Les esclaves peuvent être mis hors ligne et synchronisés avec le maître sans aucun temps d'arrêt

Les inconvénients

• En cas d'échec, un esclave doit être promu maître pour prendre sa place. Pas de basculement automatique
• Temps d'arrêt et éventuellement perte de données en cas de défaillance d'un maître
• Toutes les écritures doivent également être effectuées sur le maître dans une conception maître-esclave
• Chaque esclave supplémentaire ajoute une certaine charge au maître car le journal binaire doit être lu et les données copiées sur chaque esclave
• L'application devra peut-être être redémarrée

2. Réplication maître-maître

Avantages

• Les applications peuvent lire à partir des deux maîtres
• Répartit la charge d'écriture sur les deux nœuds maîtres
• Basculement simple, automatique et rapide

Les inconvénients

• Lâchement cohérent
• Pas aussi simple qu'un maître-esclave à configurer et à déployer

3. Cluster MySQL

Le petit nouveau de la ville basé sur la conception de cluster MySQL. Le cluster MySQL a été développé dans un souci de haute disponibilité et d'évolutivité et constitue la solution idéale à utiliser pour les environnements qui ne nécessitent aucun temps d'arrêt, une disponibilité élevée et une évolutivité horizontale.

Voir MySQL Cluster 101 pour plus d'informations

Avantages

• (Haute disponibilité) Pas de point de défaillance unique
• Débit très élevé
• 99,99% de disponibilité
• Partage automatique
• Réactivité en temps réel
• Opérations en ligne (changements de schéma, etc.)
• Écritures distribuées

Les inconvénients

• Voir les limitations connues

Vous pouvez visiter pour mon blog la ventilation complète, y compris les diagrammes d'architecture qui vont dans plus de détails sur les 3 architectures mentionnées.