Partout où je regarde, je vois que MongoDB est un PC. 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?
MongoDB est fortement cohérent par défaut - si vous écrivez puis que vous faites 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. Cela est dû au fait que MongoDB est un système à maître unique et que toutes les lectures sont transmises au système principal par défaut. Si vous activez éventuellement la lecture à partir des données secondaires, MongoDB devient finalement cohérent lorsqu'il est possible de lire des résultats obsolètes.
MongoDB bénéficie également de la haute disponibilité grâce au basculement automatique dans les jeux de réplicas: http://www.mongodb.org/display/DOCS/Replica+Sets
Cela devrait aider à répondre à la question, avec d'autres systèmes de stockage NoSQL et persistants.
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, qui dépend à la fois de la configuration de la base de données/du pilote et du type de sinistre. : voici un récapitulatif visuel et une explication plus détaillée ci-dessous.
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 correct Write / Niveau de préoccupation à lire ( Ce qui vous coûtera la 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 éventuellement cohérent.
MongoDB obtient une haute disponibilité via Replica-Sets . Dès que le primaire tombe en panne ou devient indisponible, les secondaires désignent un nouveau primaire pour qu'il soit à nouveau disponible. Cela présente un inconvénient: chaque écriture effectuée par l'ancien principal, mais non synchronisée sur les secondaires, sera annulée et enregistrée dans un fichier d'annulation, dès qu'elle se reconnecte à l'ensemble (L'ancien primaire est un secondaire maintenant). Donc, dans ce cas, une certaine cohérence est sacrifiée au profit de la disponibilité.
Grâce à l'utilisation desdits ensembles de répliques, MongoDB atteint également la tolérance de partition: tant que plus de la moitié des serveurs d'un ensemble de répliques sont connectés les uns aux autres, n nouveau principal peut être choisi . Pourquoi? Pour s'assurer que deux réseaux séparés ne peuvent pas tous les deux choisir un nouveau primaire. Lorsque pas assez de secondaires sont connectés les uns aux autres, vous pouvez toujours les lire (mais la cohérence n'est pas assurée), mais pas écrire. L'ensemble est pratiquement indisponible pour des raisons de cohérence.
En tant que nouvel article brillant est apparu et que quelques expériences impressionnantes de Kyle dans ce champ, vous devez être prudent en étiquetant MongoDB et d'autres bases de données, en tant que C ou A.
Bien sûr, CAP aide à cerner sans trop de mots ce que la base de données a de base, mais les gens oublient souvent que C dans CAP signifie cohérence atomique (linéarisation), par exemple. Et cela m'a fait beaucoup de peine à comprendre en essayant de classer. Donc, à part MongoDB qui donne une forte cohérence, cela ne veut pas dire que c'est C. De cette façon, si on fait cette classification, je recommande également de donner plus de profondeur à la façon dont cela fonctionne réellement pour ne pas laisser de doutes.
Oui, c’est CP quand vous utilisez safe=true
. Cela signifie simplement que les données ont été enregistrées sur le disque maître. Si vous voulez vous assurer qu'il est également arrivé sur un réplica, examinez le paramètre 'w = N' où N est le nombre de réplicas sur lesquels 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 que si vous avez une partition pendant longtemps, vous pouvez perdre vos données pour toujours.
Vous pouvez dire que cela ne se produira probablement pas - oui, à moins que ce soit dans le cloud où cela est plus courant qu'on ne le pense.
Cet exemple est la raison pour laquelle je ferais très attention avant d’attribuer une lettre à une base de données. Il y a tellement de scénarios et d'implémentations qui ne sont pas parfaites.
Si quelqu'un sait si ce scénario a été traité 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 au secondaire. Il permet des lectures facultatives à partir du secondaire mais pas des écritures. Donc, si votre primaire tombe en panne, vous ne pouvez pas écrire avant qu'une secondaire redevienne primaire. C'est ainsi que vous sacrifiez la haute disponibilité dans le théorème CAP. En gardant vos lectures uniquement à partir du primaire, vous pouvez obtenir une forte cohérence.