Respuestas:
MongoDB es muy consistente de forma predeterminada: si escribe y luego lee, asumiendo que la escritura fue exitosa, siempre podrá leer el resultado de la escritura que acaba de leer. Esto se debe a que MongoDB es un sistema de un solo maestro y todas las lecturas van al primario de forma predeterminada. Si habilita opcionalmente la lectura de los secundarios, MongoDB eventualmente se vuelve consistente donde es posible leer resultados desactualizados.
MongoDB también obtiene alta disponibilidad a través de la conmutación por error automática en conjuntos de réplicas: http://www.mongodb.org/display/DOCS/Replica+Sets
Estoy de acuerdo con la publicación de Luccas. No puede simplemente 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 de un 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 systemsMongoDB es muy consistente cuando usa una sola conexión o el nivel de preocupación de escritura / lectura correcto (lo que le costará velocidad de ejecución ). Tan pronto como no cumpla con esas condiciones (especialmente cuando está leyendo desde una réplica secundaria), MongoDB se vuelve eventualmente consistente.
MongoDB obtiene alta disponibilidad a través de Replica-Sets . Tan pronto como la primaria deje de funcionar o deje de estar disponible, las secundarias determinarán una nueva primaria para que vuelva a estar disponible. Esto tiene una desventaja: todas las escrituras realizadas por el antiguo primario, pero no sincronizadas con los secundarios, se revertirán y se guardará en un archivo de reversión, tan pronto como se vuelva a conectar al conjunto (el antiguo primario es secundario ahora). Entonces, en este caso, se sacrifica cierta consistencia en aras de la disponibilidad.
Mediante el uso de dichos conjuntos de réplicas, MongoDB también logra la tolerancia de partición: siempre que 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 garantizar que dos redes separadas no puedan ambas elegir una nueva primaria. Cuando no hay suficientes secundarios conectados entre sí, aún puede leerlos (pero no se garantiza la coherencia), pero no escribir. El conjunto prácticamente no está disponible por motivos de coherencia.
Como apareció un nuevo artículo brillante y también algunos experimentos asombrosos 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 en la base de datos, pero la gente a menudo olvida que C en CAP significa consistencia atómica (linealizabilidad), por ejemplo. Y esto me causó mucho dolor de entender al intentar clasificar. Entonces, además de que MongoDB da una fuerte consistencia, eso no significa que sea C. De esta manera, si uno hace estas clasificaciones, recomiendo 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, observe el parámetro 'w = N', donde N es el número de réplicas en las que se deben guardar los datos.
No estoy seguro de la P de Mongo. Imagina la situación:
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.
Puede decir que es poco probable que suceda, sí, a menos que esté en la nube, donde es más común de lo que uno piensa.
Este ejemplo es la razón por la que tendría mucho cuidado antes de asignar cualquier letra a cualquier base de datos. Hay tantos escenarios y las implementaciones no son perfectas.
Si alguien sabe si este escenario se ha abordado en versiones posteriores de Mongo, ¡comente! (No he estado siguiendo todo lo que estaba pasando durante algún tiempo ..)
Mongodb nunca permite escribir en secundaria. Permite lecturas opcionales de secundaria pero no escrituras. Entonces, si su primaria falla, no puede escribir hasta que una secundaria vuelva a ser primaria. Así es como sacrificas la alta disponibilidad en el teorema de CAP. Al mantener sus lecturas solo desde la primaria, puede tener una gran consistencia.
MongoDB selecciona la consistencia sobre la disponibilidad siempre que haya una partición. Lo que significa es que cuando hay una partición (P), elige Consistencia (C) sobre Disponibilidad (A).
Para entender esto, entendamos cómo funciona MongoDB. Un conjunto de réplicas tiene un único nodo principal. La única forma "segura" de enviar datos es escribir en ese nodo y luego esperar a que esos datos se comprometan con la mayoría de los nodos del conjunto. (verá esa bandera para w = mayoría cuando envíe escrituras)
La partición puede ocurrir en dos escenarios de la siguiente manera:
Básicamente, cada vez que ocurre una partición y MongoDB necesita decidir qué hacer, elegirá Consistencia sobre Disponibilidad. Dejará de aceptar escrituras en el sistema hasta que crea que puede completar esas escrituras de forma segura.
Mongodb proporciona consistencia y tolerancia a la partición .
En el contexto de las bases de datos distribuidas (NoSQL), esto significa que siempre habrá un compromiso entre consistencia y disponibilidad. Esto se debe a que los sistemas distribuidos siempre son necesariamente tolerantes a las particiones (es decir, simplemente no sería una base de datos distribuida si no fuera tolerante a las particiones).
Consistencia : el sistema eventualmente se volverá consistente. Los datos se propagarán a todas partes, tarde o temprano, pero el sistema continuará recibiendo información y no verifica la consistencia de cada transacción antes de pasar a la siguiente.
Disponibilidad : de forma predeterminada, Mongo DB Client (controlador MongoDB) envía todas las solicitudes de lectura / escritura al nodo principal / líder. Hace que el sistema sea consistente pero no disponible debido a: Si un líder se desconecta del grupo, se necesitan unos segundos para elegir un nuevo líder. Por lo tanto, no está disponible para escrituras y lecturas en esa duración.