Où se situe le mongodb dans le théorème de la PAC?

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 quand vous utilisez safe = true? Si oui, 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 et 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. C’est parce que MongoDB est un système à un seul maître et que toutes les lectures vont au principal par défaut. Si vous activez éventuellement la lecture à partir des secondaires, MongoDB devient finalement cohérent là où il est possible de lire les 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

Cela devrait aider à répondre à la question, avec d’autres NoSQL et autres systèmes de stockage persistants.

entrer la description de l'image ici

Je suis d’accord avec le poste de Lucques. 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 firebase database / du pilote et du type de sinistre . 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 très cohérent lorsque vous utilisez une seule connexion ou le niveau de préoccupation d’ écriture / lecture correct ( ce qui vous coûtera la vitesse d’exécution ). Dès que vous ne rencontrez pas ces conditions (en particulier lorsque vous lisez une réplique secondaire), MongoDB devient finalement cohérent.

Disponibilité:

MongoDB obtient une haute disponibilité grâce aux Replica-Sets . Dès que le primaire tombe en panne ou devient indisponible, les secondaires déterminent un nouveau primaire qui sera à nouveau disponible. Cela présente un inconvénient: chaque écriture qui a été effectuée par l’ancien primaire, mais non synchronisée avec les secondaires, sera annulée et enregistrée dans un fichier de restauration dès qu’elle se reconnectera à l’ensemble (l’ancien primaire est secondaire). à présent). Donc, dans ce cas, une certaine cohérence est sacrifiée pour des raisons de disponibilité.

Tolérance de partition:

Grâce à l’utilisation de ces 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, un nouveau primaire peut être choisi . Pourquoi? Pour garantir que deux réseaux séparés ne peuvent pas tous deux choisir un nouveau serveur principal. Lorsque le nombre de secondaires connectés est insuffisant, vous pouvez toujours en lire (mais la cohérence n’est pas assurée), mais pas en écriture. L’ensemble est pratiquement indisponible pour des raisons de cohérence.

Comme un nouvel article génial a été présenté et que Kyle a également fait d’ expériences formidables dans ce domaine, vous devriez faire attention en étiquetant MongoDB et d’autres bases de données, comme C ou A.

Bien sûr, le PAC aide à retracer, sans trop de mots, ce qui prévaut dans la firebase database, mais les gens oublient souvent que C dans CAP signifie, par exemple, la cohérence atomique (linéarisation). Et cela m’a causé beaucoup de peine à comprendre en essayant de classer. Donc, outre que MongoDB donne une forte cohérence, cela ne veut pas dire que c’est C. De cette façon, si on fait ces classifications, j’ai recommandé de donner plus de profondeur à la façon dont cela fonctionne pour ne pas laisser de doute.

Oui, c’est CP lorsqu’on utilise safe=true . Cela signifie simplement que les données ont été transférées sur le disque maître. Si vous voulez vous assurer qu’il arrive également sur certaines répliques, 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 ceci pour plus d’informations.

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

  • Votre réplique est divisée en deux partitions.
  • Les écrits continuent des deux côtés alors que de nouveaux maîtres étaient élus
  • La partition est résolue – tous les serveurs sont à nouveau connectés
  • Qu’est-ce qui se passe est que le nouveau maître est élu – celui qui a la plus haute oplog, mais les données de l’autre maître devient à l’état commun avant la partition et il est sauvegardé 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 depuis longtemps, vous pouvez perdre vos données pour toujours.

Vous pouvez dire qu’il est peu probable que cela se produise – oui, sauf dans le nuage où il est plus courant qu’on ne le pense.

Cet exemple explique pourquoi je serais très prudent avant d’atsortingbuer une lettre à une firebase database. Il y a tellement de scénarios et d’implémentations qui ne sont pas parfaits.

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 ..)