Teorema CAP: disponibilidad y tolerancia de partición
Mientras trato de entender la "Disponibilidad" (A) y la "Tolerancia de partición" (P) en CAP, me resultó difícil entender las explicaciones de varios artículos.
Tengo la sensación de que A y P pueden ir juntos (sé que este no es el caso, ¡y por eso no lo entiendo!).
Explicando en términos simples, ¿qué son A y P y la diferencia entre ellos?
La coherencia significa que los datos son los mismos en todo el clúster, por lo que puede leer o escribir desde/hacia cualquier nodo y obtener los mismos datos.
Disponibilidad significa la capacidad de acceder al clúster incluso si un nodo del clúster deja de funcionar.
La tolerancia a la partición significa que el clúster continúa funcionando incluso si hay una "partición" (interrupción de comunicación) entre dos nodos (ambos nodos están activos, pero no pueden comunicarse).
Para obtener disponibilidad y tolerancia de partición, debe renunciar a la coherencia. Considere si tiene dos nodos, X e Y, en una configuración maestro-maestro. Ahora, hay una interrupción entre la comunicación de red entre X e Y, por lo que no pueden sincronizar las actualizaciones. En este punto puedes:
A) Permitir que los nodos se desincronicen (perdiendo coherencia), o
B) Considere que el clúster está "inactivo" (perdiendo disponibilidad)
Todas las combinaciones disponibles son:
- CA : los datos son consistentes entre todos los nodos, siempre que todos los nodos estén en línea, y puede leer/escribir desde cualquier nodo y asegurarse de que los datos sean los mismos, pero si alguna vez desarrolla una partición entre nodos, los datos serán no está sincronizado (y no se volverá a sincronizar una vez que se resuelva la partición).
- CP : los datos son consistentes entre todos los nodos y mantienen la tolerancia de partición (evitando la desincronización de datos) al dejar de estar disponibles cuando un nodo deja de funcionar.
- AP : los nodos permanecen en línea incluso si no pueden comunicarse entre sí y resincronizarán los datos una vez que se resuelva la partición, pero no se garantiza que todos los nodos tengan los mismos datos (ya sea durante o después de la partición)
Debe tener en cuenta que los sistemas de CA prácticamente no existen (incluso si algunos sistemas afirman que sí).
Considerar a P en términos iguales a C y A es un poco erróneo; más bien, la noción de '2 de 3' entre C,A,P es engañosa. La forma sucinta en la que explicaría el teorema de CAP es: "En un almacén de datos distribuido, en el momento de la partición de la red, debe elegir Consistencia o Disponibilidad y no puede obtener ambas". Los sistemas NoSQL más nuevos están tratando de centrarse en la disponibilidad, mientras que las bases de datos ACID tradicionales se centraban más en la coherencia.
Realmente no se puede elegir CA, la partición de red no es algo que a nadie le gustaría tener, es simplemente una realidad indeseable de un sistema distribuido, las redes pueden fallar. La pregunta es qué compensación elige para su aplicación cuando eso sucede. Este artículo del hombre que formuló ese término por primera vez parece explicar esto muy claramente.
Así es como hablo de CAP, en particular con respecto a P.
CA solo es posible si está de acuerdo con una base de datos monolítica de un solo servidor (tal vez con replicación, pero todos los datos en un "bloque de falla"; no se considera que los servidores fallen parcialmente).
Si su problema requiere escalamiento horizontal, distribución y múltiples servidores, pueden ocurrir particiones de red. Ya estás necesitando P. Pocos de los problemas que abordo son susceptibles de paradigmas de servidor único siempre (o, como dijo Stonebraker, "lo distribuido es lo que está en juego"). Si puede encontrar un problema de CA, soluciones como un RDBMS tradicional sin escalamiento horizontal brindan muchos beneficios.
Para mí, es raro: así que pasamos a discutir AP vs CP.
Sólo eliges entre operación AP y CP cuando tienes una partición. Si la red y el hardware funcionan correctamente, obtendrás tu pastel y te lo comerás también.
Analicemos la distinción AP / CP.
AP: cuando hay una partición de red, deja que las partes independientes funcionen libremente.
CP: cuando hay una partición de red, cierra los nodos o no permite lecturas y escrituras para que haya fallas deterministas.
Me gustan las arquitecturas que pueden hacer ambas cosas, porque algunos problemas son AP y otros CP, y algunas bases de datos pueden hacer ambas cosas. Entre las soluciones CP y AP también hay sutilezas.
Por ejemplo, en un conjunto de datos AP, tiene la posibilidad de realizar lecturas inconsistentes y generar conflictos de escritura; estos son dos modos AP posibles diferentes. ¿Se puede configurar su sistema para AP con alta disponibilidad de lectura pero no permite conflictos de escritura? ¿O su sistema AP puede aceptar conflictos de escritura, con un sistema de resolución sólido y flexible? ¿Necesitará ambos eventualmente o puede elegir un sistema que solo haga uno?
En un sistema CP, ¿cuánta indisponibilidad se obtiene con particiones pequeñas (servidor único), si corresponde? Una mayor replicación puede aumentar la indisponibilidad en un sistema CP, ¿cómo maneja el sistema esas compensaciones?
Todas estas son preguntas que deben hacerse con CP vs AP.
Una gran lectura en esta área en este momento es la publicación "12 años después" de Brewer. Creo que esto hace avanzar el debate sobre la PAC con claridad y lo recomiendo encarecidamente.
http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
Consistencia:
Se garantiza que una lectura devolverá la escritura más reciente (como ACID) para un cliente determinado. Si llega alguna solicitud durante ese tiempo, debe esperar hasta que se complete la sincronización de datos en los nodos.
Disponibilidad:
cada nodo (si no falla) siempre ejecuta consultas y siempre debe responder a las solicitudes. No importa si devuelve la última copia o no.
Tolerancia de partición:
El sistema seguirá funcionando cuando se produzcan particiones de la red.
Con respecto a AP , la disponibilidad (siempre accesible) puede existir con ( Cassendra ) o sin tolerancia de partición ( RDBMS ).
fuente de la foto
