Hablando teóricamente (casos de uso ideales para sistemas débilmente consistentes):
La coherencia eventual permite una alta disponibilidad, incluso si la mayoría de los nodos no pueden comunicarse entre sí, por ejemplo, operaciones desconectadas. También permite preservar la baja latencia en muchos escenarios de falla. Sin embargo, no es particularmente fácil de tratar: en muchos casos, la disponibilidad / latencia son las cualidades más fáciles de “entregar”, ya que la posibilidad de un tiempo de espera es generalmente más fácil de manejar para un desarrollador de aplicaciones que la posibilidad de no atómica actualizaciones y conflictos de escritura-escritura. Dicho esto, en muchos casos, la alta disponibilidad y la baja latencia son requisitos críticos y no puede darse el lujo de “renunciar a ellos”. Como tal, los sistemas distribuidos read-any / write-any son particularmente adecuados para casos en los que:
- Se desea alta disponibilidad y baja latencia
- Donde las operaciones realizadas son conmutativas e idempotentes,
O
- Si no se pueden establecer relaciones causales entre valores, los conflictos de escritura-escritura se pueden conciliar semánticamente
“La conjetura de CALM” proporciona un enfoque interesante para cuantificar exactamente qué tipos de datos / operaciones en los datos son susceptibles de eventual consistencia, y dónde se requiere algún tipo de coordinación (por ejemplo, utilizando un mecanismo de compromiso distribuido): http: // databeta. wordpress.com/20…
- ¿Es importante tener experiencia en investigación específica de CS para admisiones a escuelas de posgrado de CS?
- ¿Por qué la gente dice que CS es más que programación o un lenguaje en particular?
- ¿Cuáles son algunas preguntas de investigación abiertas relacionadas con la realidad virtual?
- ¿Cuáles son los temas de investigación más interesantes en ciencias?
- ¿Qué áreas de la informática involucran más trabajo de hardware?
Aquí hay un argumento interesante contra el uso de relojes distribuidos / establecer causalidad (en oposición al enfoque de Bayou de usar vectores de versión para establecer causalidad): http://databeta.wordpress.com/20…
Hablando en la práctica (ejemplos del mundo real de sistemas débilmente consistentes):
DNS es el sistema consistente más grande y más antiguo (anterior a Bayou en 17 años), pero con algunas advertencias sobre las características de lectura / escritura y falta de resolución de conflictos (la zona con la SOA numéricamente más grande se transferirá y anulará la zona local) , si está permitido): técnicamente, el dominio de los registros se distribuye jerárquicamente, pero en la práctica esto también se viola (por ejemplo, Comcast lo redirecciona a una página de destino cuando escribe mal un nombre de dominio).
Los sistemas de control de versiones distribuidos, como git, son ejemplos populares e intuitivamente comprensibles de sistemas distribuidos “read-any / write-any”. Al igual que con una base de datos distribuida clásica, a veces es imposible establecer un orden causal entre las actualizaciones y la reconciliación manual (en el caso de un DVCS, una fusión) tiene que ocurrir.
En términos de sistemas inspirados explícitamente en Bayou, varias implementaciones de Amazon Dynamo Paper están creciendo en popularidad, mientras que Dynamo impulsa el carrito de compras de Amazon. Al igual que Bayou, los vectores de versión se usan para detectar conflictos de escritura-escritura y los procedimientos personalizados se pueden usar para conciliar valores que no se encuentran causalmente relacionados (en el documento de Amazon, se fusionan versiones conflictivas de un carrito de compras). Sin embargo, a diferencia de Bayou, la anti-entropía no se usa como técnicas de replicación principales: los protocolos de chismes se usan para replicar el estado blando, como el estado del detector de fallas, y el protocolo anti-entropía basado en el árbol hash se usa para sincronizar réplicas después de fallas de longitud media sin transferir todo el estado.
Dicho esto, muchos sistemas de tipo Dynamo se pueden ajustar para usar protocolos de quórum, lo que permite actualizaciones condicionales pseudoatómicas (bloqueo aproximadamente optimista) para aplicaciones como contadores.
Para leer más, sugiero “Replicación optimista” de Yasushi Saito, una excelente encuesta de técnicas de replicación débilmente consistentes: http://www.ysaito.com/survey.pdf
(Enchufe obligatorio / divulgación:
Soy miembro del Proyecto Voldemort, un almacén de datos distribuidos inspirado en Dynamo. Me gusta la consistencia eventual y la elegancia de sistemas como Dynamo y Bayou, pero es importante comprender sus limitaciones y compensaciones involucradas en su diseño.
También me apasionan todo tipo de sistemas distribuidos. Espero escribir más sobre este tema en mi blog: http://afeinberg.github.com/, discutiendo varias técnicas prácticas de replicación, desde las más consistentes, como la copia primaria, hasta las débilmente consistentes y las intermedias. )