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

Question

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

• maître-maître

• maître-esclave

N'est-ce pas le maître de maître de plus approprié pour le web d'aujourd'hui, parce que c'est comme Git, chaque unité dispose de l'ensemble des données et si l'on descend, il n'a pas assez de matière.

Maître-esclave me rappelle de SVN (je n'aime pas) où vous avez une unité centrale qui gère la chose.

Questions:

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

2. Si vous voulez avoir une base de données locale dans votre téléphone mobile comme l'iPhone, lequel est le plus approprié?

3. Est le choix de l'un d'eux, un facteur crucial de considérer bien?

Answer 1

Alors que des recherches sur les différentes architectures des bases de données ainsi. J'ai compilé une bonne partie des informations qui pourraient être utiles à quelqu'un d'autre faire de la recherche à l'avenir. Je suis tombé sur

1. La Réplication Maître-Esclave
2. Maître-Maître De Réplication
3. MySQL Cluster

J'ai décidé de le régler à l'aide de MySQL Cluster pour mon cas d'utilisation. Mais s'il vous plaît voir ci-dessous les avantages et les inconvénients que j'ai compilé

1.La Réplication Maître-Esclave

Pros

  *Analytic applications can read from the slave(s) without impacting the master

  *Backups of the entire database of relatively no impact on the master

  *Slaves can be taken offline  and sync back to the master without any downtime

Cons

 *In the instance of a failure a slave has to be promoted to master to take over its place. No automatic failover

 *Downtime and possibly lost of data when a master fails

 *All writes also have to be made to the master in a master-slave design

 *Each additional slave add some load* to the master since the binary log have to be read and data copied to each slave

 *Application might have to be restarted

2.Maître-Maître De Réplication

Pros

  *Applications can read  from both masters

  *Distributes write load across both master nodes

  *Simple ,automatic and quick failover  

Cons

  *Loosely consistent   

  *Not as simple as master-slave to configure and deploy

3. MySQL Cluster

Le petit nouveau en ville basé sur MySQL cluster. Le cluster MySQL a été développé avec la haute disponibilité et évolutivité à l'esprit et est la solution idéale pour être utilisée pour les environnements qui nécessitent aucun temps d'arrêt, la haute avalability et évolutivité horizontale.

Voir le Cluster MySQL 101 pour plus d'informations

Pros

  *(High Avalability)no single point of failure

  *Very high throughput

  *99.99% uptime 

  *Auto-Sharding

  *Real-Time Responsiveness

  *On-Line Operations(Schema changes etc)

  *Distributed writes

Cons

   See [known limitations][1] 

Vous pouvez visiter mon Blog ventilation complète, y compris les diagrammes d'architecture qui va dans de plus amples détails sur les 3 mentionnés architectures.

Answer 2

Nous sommes en négociation hors avaiability, de la cohérence et de la complexité. Pour répondre à la dernière question: est-ce important? Oui, très! Les choix concernant la façon dont vos données seront gérées est absolument fondamental, et il n'y a pas de "Meilleure Pratique" en esquivant les décisions. Vous avez besoin de comprendre à vos exigences particulières.

Il y a une tension fondamentale:

Une copie: la cohérence est facile, mais si elle arrive à être vers le bas tout le monde est hors de l'eau, et si les gens sont à distance peut alors payer horribles les coûts de communication. Apporter des appareils portables, qui peuvent avoir besoin d'utiliser disconenected, dans l'image et une copie ne sera pas coupé.

Maître-Esclave: la cohérence n'est pas trop difficile, car chaque morceau de données a exactement un propriétaire de maître. Mais alors, que faites-vous si vous ne pouvez pas voir que le maître, une sorte de remises de travail est nécessaire.

Maître-Maître: eh bien, si vous pouvez le faire fonctionner, alors il semble offrir tout, pas de point de défaillance unique, tout le monde peut travailler tout le temps. L'ennui est-il très difficile de conserver la cohérence absolue. Voir l'article de wikipedia pour plus d'.

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

Avantages

• Si un maître d'échec, d'autres maîtres continuera à mettre à jour le la base de données.

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

Inconvénients

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

• Désireux de réplication systèmes sont complexes et introduire quelques la communication de la latence.

• Des questions telles que la résolution de conflits peuvent devenir insoluble qu' le nombre de nœuds impliqués augmente et le temps de latence diminue.