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:
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
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
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.
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é.
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.
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.
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.
Je ne suis pas sûr de P pour Mongo. Imaginez la situation:
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 ..)
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.
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:
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é.
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.