¿Dónde está mongodb en el teorema de la TAPA?

Esto debería ayudar a responder la pregunta, junto con otros NoSQL y otros sistemas de almacenamiento persistente.

Estoy de acuerdo con Luccas post. No se puede decir que MongoDB es CP/AP/CA, porque en realidad es una compensación entre C, A y P, dependiendo de la configuración de la base de datos/controlador y el tipo de desastre: aquí hay un resumen visual, y debajo una explicación más detallada.

    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

Consistencia:

MongoDB es muy consistente cuando se utiliza una sola conexión o la escritura correcta/Leer Nivel de Preocupación (Lo que le costará velocidad de ejecución ). Como tan pronto como usted no cumple con esas condiciones (especialmente cuando está leyendo de una réplica secundaria) MongoDB se vuelve Eventualmente Consistente.

Disponibilidad:

MongoDB obtiene alta disponibilidad a través de Replica-Sets . Tan pronto como la primaria caiga o no esté disponible, las secundarias determinarán que una nueva primaria vuelva a estar disponible. Hay una desventaja en esto: Cada escritura que fue realizada por el antiguo primario, pero no sincronizada con el los secundarios se revertirán y se guardarán en un archivo de reversión, tan pronto como se vuelva a conectar al conjunto(el antiguo primario ahora es secundario). Así que en este caso se sacrifica cierta consistencia en aras de la disponibilidad.

Tolerancia de partición:

A través del uso de dichos Conjuntos de Réplicas MongoDB también logra la tolerancia de partición: Mientras más de la mitad de los servidores de un Conjunto de Réplicas estén conectados entre sí, se puede elegir un nuevo primario. ¿Por qué? Para asegurar dos las redes separadas no pueden elegir una nueva primaria. Cuando no hay suficientes secundarios conectados entre sí, aún puede leer de ellos (pero no se garantiza la consistencia), pero no escribir. El conjunto prácticamente no está disponible en aras de la consistencia.

Como un brillante nuevo artículo apareció y también algunos impresionantes experimentos de Kyle en este campo, debe tener cuidado al etiquetar MongoDB, y otras bases de datos, como C o A.

Por supuesto, CAP ayuda a rastrear sin muchas palabras lo que prevalece sobre la base de datos, pero la gente a menudo olvida que C en CAP significa consistencia atómica (linealización), por ejemplo. Y esto me causó mucho dolor para entender al tratar de clasificar. Así, además de MongoDB dar fuerte consistencia, eso no quiere decir que sea C. De esta manera, si uno hace estas clasificaciones, recomendé también dar más profundidad en cómo funciona realmente para no dejar dudas.

Sí, es CP cuando se usa safe=true. Esto simplemente significa que los datos llegaron al disco maestro. Si desea asegurarse de que también llegó a alguna réplica, busque en el parámetro' w=N ' donde N es el número de réplicas en las que se deben guardar los datos.

Ver thisy this para más información.

No estoy seguro acerca de P para Mongo. Imagine la situación:

• Su réplica se divide en dos particiones.
• Escribe continuar a ambos lados como nuevos maestros fueron elegidos
• Se ha resuelto la partición-ahora todos los servidores están conectados de nuevo
• Lo que sucede es que se elige un nuevo maestro, el que tiene el oplog más alto, pero los datos del otro maestro se revierten al estado común antes de la partición y se vierten en un archivo para la recuperación manual
• todos los secundarios se ponen al día con el nuevo maestro

El problema aquí es que el tamaño del archivo de volcado es limitado y si tuvo una partición durante mucho tiempo puede perder sus datos para siempre.

Se puede decir que es poco probable que suceda - sí, a menos que en la nube donde es más común de lo que uno puede pensar.

Este ejemplo es por lo que sería muy cuidadoso antes de asignar cualquier letra a cualquier base de datos. Hay tantos escenarios e implementaciones que no son perfectas.

Si alguien sabe si este escenario ha sido abordado en versiones posteriores de Mongo por favor, comente! (No he estado siguiendo todo lo que estaba pasando por algún tiempo..)