qué - ¿Dónde se encuentra mongodb en el teorema CAP?
de qué se compone el teorema cap (6)
Donde sea que mire, veo que MongoDB es CP. Pero cuando indago veo que finalmente es consistente. ¿Es CP cuando usa seguro = verdadero? Si es así, ¿significa eso que cuando escribo con safe = true, todas las réplicas se actualizarán antes de obtener el resultado?
Como apareció un nuevo artículo brillante y también algunos aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads 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 demasiadas palabras lo que prevalece sobre la base de datos, pero a menudo la gente olvida que C en CAP significa consistencia atómica (linealizabilidad), por ejemplo. Y esto me causó mucho dolor para entender al tratar de clasificar. Por lo tanto, además de MongoDB da una gran coherencia, eso no significa que sea C. De esta manera, si uno hace estas clasificaciones, le recomendé también que le de más profundidad sobre cómo funciona en realidad para no dejar dudas.
Esto debería ayudar a responder la pregunta, junto con otros NoSQL y otros sistemas de almacenamiento persistentes.
Estoy de acuerdo con la publicación de Luccas. No se 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 base de datos / controlador y del 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 systems
Consistencia:
MongoDB es muy consistente cuando usa una sola conexión o el Nivel de preocupación de Write / lectura correcto (lo que le costará la velocidad de ejecución ). Tan pronto como no cumplas esas condiciones (especialmente cuando estás leyendo desde una réplica secundaria), MongoDB se vuelve finalmente consistente.
Disponibilidad:
MongoDB obtiene alta disponibilidad a través de Replica-Sets . Tan pronto como el primario se apaga o deja de estar disponible, los secundarios determinarán que un nuevo primario estará disponible nuevamente. Esto tiene una desventaja: cada escritura realizada por el primario anterior, pero no sincronizada con los secundarios, se retrotraerá y guardará en un archivo rollback, tan pronto como vuelva a conectarse al conjunto (el primario antiguo es secundario). ahora). Entonces, en este caso, se sacrifica cierta coherencia por el bien de la disponibilidad.
Tolerancia de partición:
Mediante el uso de dichas réplicas, MongoDB también logra la tolerancia de partición: siempre que más de la mitad de los servidores de un Replica-Set esté conectado entre sí, se puede elegir un nuevo primario . ¿Por qué? Para garantizar que dos redes separadas no puedan elegir una nueva primaria. Cuando no hay suficientes secundarios conectados entre sí, puede leer de ellos (pero no se garantiza la coherencia), pero no escribir. El conjunto no está disponible por razones de coherencia.
MongoDB es muy consistente por defecto: 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 maestro único y todas las lecturas van a la primaria de forma predeterminada. Si habilita opcionalmente la lectura de los secundarios, entonces MongoDB se vuelve consistente cuando es posible leer los resultados desactualizados.
MongoDB también obtiene alta disponibilidad a través de failover automático en conjuntos de réplicas: http://www.mongodb.org/display/DOCS/Replica+Sets
No estoy seguro de P para Mongo. Imagina la situación:
- Tu réplica se divide en dos particiones.
- Las escrituras continúan a ambos lados cuando nuevos maestros fueron elegidos
- La partición está resuelta: todos los servidores están conectados nuevamente
- Lo que sucede es que se elige un nuevo maestro, el que tiene el optograma más alto, pero los datos del otro maestro se revierten al estado común antes de la partición y se vuelcan a un archivo para la recuperación manual.
- todos los secundarios alcanzan al nuevo maestro
El problema aquí es que el tamaño del archivo de volcado es limitado y si tiene 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 pueda pensar.
Este ejemplo es por qué tendría mucho cuidado antes de asignar cualquier carta a cualquier base de datos. Hay tantos escenarios e implementaciones que no son perfectos.
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 sucediendo desde hace un tiempo ...)
Sí, es CP al usar safe=true . Esto simplemente significa que los datos llegaron al disco maestro. Si desea asegurarse de que también llegó en alguna réplica, busque en el parámetro ''w = N'' donde N es la cantidad de réplicas en las que se deben guardar los datos.