Para las bases de datos distribuidas, los modelos de consistencia son un tópico de gran importancia. Nos gustaría hurgar un poco más en profundidad en este tópico con una serie de artículos, discutiendo asuntos tales como qué modelo es correcto para un caso de uso en particular.
Empezaremos aquí con una introducción básica sobre este tema.
CAP
El teorema de CAP (Capability (Capacidad), Availability (Disponibilidad) y Partitions (Particiones)) plantea que uno puede sólo tener dos características al mismo tiempo de consistencia, disponibilidad y tolerancia a particiones de red. En sistemas distribuidos, el particionamiento de red es inevitable y debe ser torleado, así que el CAP esencial significa que no podemos tener tanto consistencia como disponibilidad al 100%.
Informalmente, deberíamos resumir el teorema de CAP como:
* Si la red se cae, tu base de datos no funcionará.
Sin embargo, hemos de afinar la definición de "no funcionará". Esto puede significar tanto caída (no disponible) como inconsistencia (datos viejos).
¿Qué queremos decir -más precisamente- con "consistencia"? El trabajo académico en este área se refiere a "una copia de serializabilidad" o "linearizabilidad". Si una serie de operaciones o transacciones son realizadas, éstas son aplicadas en un orden consistente. Una forma menos formal de pensar sobre compensación sería "¿Podría leer y manipular datos viejos/contaminados? ¿Puedo siempre escribir?"
Encarnaciones
Tenemos dos clases de arquitectura: una clase C (fuertemente consistente) y una clase A (alta disponibilidad con pérdida de consistencia). Consideremos algunos sistemas distribuidos del mundo real y dónde están clasificados.
Amazon Dynamo es un repositorio de datos distribuido, el cual implementa hashing consistente y que está en el grupo A. Provee consistencia eventual. Uno puede leer datos antiguos.
CouchDB es típicamente utilizada con replicación asíncrona maestro-maestro, y está en el grupo A. Provee consistencia eventual.
Un cluster MongoDB auto-fragmentación+replicación tiene un servidor maestro y un punto dado en el tiempo para cada fragmento (shard). Éste está en el grupo C. Los sistemas RDBMS tradicionales también tienen consistencia fuerte (como son típicamente utilizadas) - un cluster RDBMS síncrono, por ejemplo.
Cabe destacar que las configuraciones alternativas de estos productos a veces alteran su propiedades de consistencia (y rendimiento). Para nuestra discusión aquí, asumiremos que estos productos están configurados en su caso común, a menos que se indique otra cosa.
Disponibilidad para escritura, no disponibilidad para lectura, es la cuestión principal
Con la mayor parte de las bases de datos actuales, es fácil tener cualquier número de réplicas asíncronas distribuidas en el mundo. Si se particionan las redes, debemos tener entonces acceso a los datos esclavos locales. Cuando la replicación es asíncrona, estos datos son eventualmente consistentes, así que este resultado no es sorprendente - estamos ahora en la clase A de sistemas. Sin embargo, casi todos los diseños, incluso de la clase C, pueden añadir fácilmente capacidades de lectura asíncrona. Así, las decisiones de diseño crítico son sobre la capacidad de escritura.
Las compensaciones
* incluso la distribución de carga es más fácil en sistemas eventualmente consistentes
* el centro de soporte multi-datos es más fácil en sistemas eventualmente consistentes
* algunos problemas no son solucionables con sistemas eventualmente consistentes
* a veces el código es más fácil escribirlo en sistemas fuertemente consistentes
Discutiremos sobre los pros y contras en detalle en los artículos subsecuentes.
Fuente: http://blog.mongodb.org/post/475279604/on-distributed-consistency-part-1
