Où se situe mongodb dans le théorème CAP?


121

Partout où je regarde, je vois que MongoDB est CP. Mais quand je creuse, je vois que c'est finalement cohérent. Est-ce CP lorsque vous utilisez safe = true? Si tel est le cas, cela signifie-t-il que lorsque j'écris avec safe = true, toutes les répliques seront mises à jour avant d'obtenir le résultat?

Réponses:


104

MongoDB est fortement cohérent par défaut - si vous effectuez une écriture puis une lecture, en supposant que l'écriture a réussi, vous pourrez toujours lire le résultat de l'écriture que vous venez de lire. En effet, MongoDB est un système à maître unique et toutes les lectures vont au primaire par défaut. Si vous activez éventuellement la lecture à partir des secondaires, MongoDB devient finalement cohérent lorsqu'il est possible de lire des résultats obsolètes.

MongoDB obtient également une haute disponibilité grâce au basculement automatique dans les jeux de réplicas: http://www.mongodb.org/display/DOCS/Replica+Sets


13
Selon aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads, même si vous lisez à partir du nœud principal du jeu de répliques, vous pouvez obtenir des données périmées ou sales. Alors MongoDB est-il fort cohérent?
Mike Argyriou

3
Expériences impressionnantes de Kyle. Il chasse vraiment Mongo. Je me demande s'il existe des systèmes de production, par exemple utilisant MongoDB pour effectuer des transactions de paiement? Si c'est juste un site Web personnel, qui se soucie alors d'une cohérence forte.
xin

5
Pour mémoire, MongoDB v3.4 a réussi le test conçu par Kyle donc oui, MongoDB est fortement cohérent, même avec ReplicaSet et Sharding
Maxime Beugnet

2
Cette réponse peut être un peu trop simpliste, car MongoDB peut sacrifier la disponibilité de temps en temps, en fonction de la configuration. JoCa's mieux explique les situations dans lesquelles il se comporte CA / CP / AP
PaoloC

37

Je suis d'accord avec Luccas post. Vous ne pouvez pas simplement dire que MongoDB est CP / AP / CA, car il s'agit en fait d'un compromis entre C, A et P, en fonction de la configuration de la base de données / du pilote et du type de catastrophe : voici un récapitulatif visuel, et ci-dessous un explication plus détaillée.

    Scenario                   | Main Focus | Description
    ---------------------------|------------|------------------------------------
    No partition               |     CA     | The system is available 
                               |            | and provides strong consistency
    ---------------------------|------------|------------------------------------
    partition,                 |     AP     | Not synchronized writes 
    majority connected         |            | from the old primary are ignored                
    ---------------------------|------------|------------------------------------
    partition,                 |     CP     | only read access is provided
    majority not connected     |            | to avoid separated and inconsistent systems

Cohérence:

MongoDB est fortement cohérent lorsque vous utilisez une seule connexion ou le bon niveau de préoccupation en écriture / lecture ( ce qui vous coûtera en vitesse d'exécution ). Dès que vous ne remplissez pas ces conditions (en particulier lorsque vous lisez à partir d'une réplique secondaire), MongoDB devient finalement cohérent.

Disponibilité:

MongoDB obtient une haute disponibilité grâce aux jeux de réplicas . Dès que le primaire tombe en panne ou devient indisponible, les secondaires détermineront un nouveau primaire pour qu'il redevienne disponible. Il y a un inconvénient à cela: chaque écriture effectuée par l'ancien primaire, mais non synchronisée avec les secondaires sera restaurée et enregistrée dans un fichier de restauration, dès qu'elle se reconnectera à l'ensemble (l'ancien primaire est un secondaire maintenant). Donc, dans ce cas, une certaine cohérence est sacrifiée pour des raisons de disponibilité.

Tolérance de partition:

Grâce à l'utilisation desdits Replica-Sets, MongoDB atteint également la tolérance de partition: tant que plus de la moitié des serveurs d'un Replica-Set sont connectés les uns aux autres, un nouveau primaire peut être choisi . Pourquoi? Pour garantir que deux réseaux séparés ne peuvent pas choisir un nouveau principal. Lorsqu'il n'y a pas assez de secondaires connectés les uns aux autres, vous pouvez toujours lire à partir d'eux (mais la cohérence n'est pas assurée), mais pas écrire. L'ensemble est pratiquement indisponible par souci de cohérence.


Donc, si j'utilise le niveau de préoccupation d'écriture / lecture correct, cela signifie que toutes les écritures et lectures vont au primaire (si j'ai bien compris), alors que font exactement les secondaires? Asseyez-vous juste là en attente au cas où le primaire tomberait en panne?
tomer.z

@ tomer.z vous voudrez peut-être lire cette section du manuel: Vous pouvez utiliser des secondaires pour la lecture. Si vous utilisez le niveau de lecture «majoritaire», la lecture sera valide dès qu'une majorité des membres a reconnu la lecture. Il en va de même pour le niveau d'écriture «majoritaire». Si vous utilisez le niveau de préoccupation «majoritaire» pour les deux, vous disposez d'une base de données cohérente. Vous voudrez peut-être en savoir plus à ce sujet dans le manuel .
JoCa

18

Comme un nouvel article brillant est apparu ainsi que des expériences impressionnantes de Kyle dans ce domaine, vous devez être prudent lorsque vous étiquetez MongoDB et d'autres bases de données comme C ou A.

Bien sûr, CAP permet de localiser sans trop de mots ce que la base de données prévaut à son sujet, mais les gens oublient souvent que C dans CAP signifie cohérence atomique (linéarisation), par exemple. Et cela m'a causé beaucoup de peine à comprendre en essayant de classer. Donc, outre MongoDB donne une forte cohérence, cela ne signifie pas que c'est C. De cette façon, si l'on fait ces classifications, je recommande également de donner plus de détails sur la façon dont cela fonctionne réellement pour ne pas laisser de doutes.


10

Oui, c'est CP lors de l'utilisation safe=true. Cela signifie simplement que les données sont arrivées sur le disque maître. Si vous voulez vous assurer qu'il est également arrivé sur une réplique, examinez le paramètre «w = N» où N est le nombre de répliques sur lesquelles les données doivent être enregistrées.

voir ceci et cela pour plus d'informations.


3

Je ne suis pas sûr de P pour Mongo. Imaginez la situation:

  • Votre réplique est divisée en deux partitions.
  • Les écritures continuent des deux côtés alors que de nouveaux maîtres ont été élus
  • La partition est résolue - tous les serveurs sont à nouveau connectés
  • Ce qui se passe, c'est que le nouveau maître est élu - celui qui a le plus grand oplog, mais les données de l'autre maître sont rétablies à l'état commun avant la partition et elles sont vidées dans un fichier pour une récupération manuelle
  • tous les secondaires rattrapent le nouveau maître

Le problème ici est que la taille du fichier de vidage est limitée et si vous avez une partition pendant une longue période, vous pouvez perdre vos données pour toujours.

Vous pouvez dire que cela ne se produira probablement pas - oui, sauf dans le cloud où cela est plus courant qu'on ne le pense.

Cet exemple est pourquoi je ferais très attention avant d'attribuer une lettre à une base de données. Il y a tellement de scénarios et les implémentations ne sont pas parfaites.

Si quelqu'un sait si ce scénario a été abordé dans les versions ultérieures de Mongo, veuillez commenter! (Je n'ai pas suivi tout ce qui se passait depuis un certain temps ..)


2
Le protocole d'élection de MongoDB est conçu pour avoir (au plus) une seule primaire. Un primaire ne peut être élu (et maintenu) que par une majorité stricte des membres votants de l'ensemble de réplicas configuré (n / 2 +1). En cas de partition du réseau, une seule partition (avec la majorité des membres votants) peut élire un primaire; un primaire antérieur dans une partition minoritaire se retirera et deviendra un secondaire. C'est ainsi que les jeux de répliques ont toujours fonctionné. Dans le cas où un ancien serveur principal a accepté des écritures qui n'ont pas été répliquées, elles seront restaurées (enregistrées sur le disque) lorsque ce membre rejoindra le jeu de réplicas.
Stennie

2

Mongodb n'autorise jamais l'écriture en secondaire. Il autorise les lectures facultatives à partir du secondaire mais pas les écritures. Donc, si votre primaire tombe en panne, vous ne pouvez pas écrire jusqu'à ce qu'un secondaire redevienne primaire. C'est ainsi que vous sacrifiez la haute disponibilité dans le théorème CAP. En conservant vos lectures uniquement du primaire, vous pouvez avoir une forte cohérence.


2

MongoDB sélectionne la cohérence sur la disponibilité chaque fois qu'il y a une partition. Cela signifie que lorsqu'il y a une partition (P), elle choisit la cohérence (C) sur la disponibilité (A).

Pour comprendre cela, comprenons comment MongoDB fonctionne avec l'ensemble de réplicas. Un jeu de réplicas a un seul nœud principal. Le seul moyen «sûr» de valider des données est d'écrire sur ce nœud et d'attendre que ces données soient validées sur la majorité des nœuds de l'ensemble. (vous verrez cet indicateur pour w = majorité lors de l'envoi d'écritures)

La partition peut se produire dans deux scénarios comme suit:

  • Lorsque le nœud principal tombe en panne: le système devient indisponible jusqu'à ce qu'un nouveau nœud principal soit sélectionné.
  • Lorsque le nœud principal perd la connexion d'un trop grand nombre de nœuds secondaires: le système devient indisponible. D'autres secondaires essaieront d'élire un nouveau primaire et le primaire actuel se retirera.

Fondamentalement, chaque fois qu'une partition se produit et que MongoDB doit décider quoi faire, il choisit la cohérence plutôt que la disponibilité. Il cessera d'accepter les écritures sur le système jusqu'à ce qu'il pense pouvoir terminer ces écritures en toute sécurité.


«Il cessera d' accepter les écritures sur le système jusqu'à ce qu'il pense pouvoir terminer ces écritures en toute sécurité. » Et les lectures ? Resterait-il accessible en lecture pendant cette période?
Josh le

1

Mongodb offre une cohérence et une tolérance de partition .

Dans le contexte des bases de données distribuées (NoSQL), cela signifie qu'il y aura toujours un compromis entre cohérence et disponibilité. Cela est dû au fait que les systèmes distribués sont toujours nécessairement tolérants aux partitions (c'est-à-dire que ce ne serait tout simplement pas une base de données distribuée si elle n'était pas tolérante aux partitions.)

Cohérence - Le système deviendra finalement cohérent. Les données se propageront partout où elles le devraient tôt ou tard, mais le système continuera à recevoir des entrées et ne vérifie pas la cohérence de chaque transaction avant de passer à la suivante.

Disponibilité - Par défaut, Mongo DB Client (pilote MongoDB) envoie toutes les demandes de lecture / écriture au nœud principal / principal. Cela rend le système cohérent mais indisponible en raison de - Si un leader se déconnecte du cluster, il faut quelques secondes pour élire un nouveau leader. Donc, le rendant indisponible pour les écritures et les lectures pendant cette durée.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.