Consistencia eventual

Question

Estoy en las primeras etapas de diseño de una aplicación que debe ser altamente disponible y escalable. Quiero utilizar un modelo de datos de coherencia eventual para esto por una serie de razones. Sé y entiendo por qué esta es una elección arquitectónica impopular para muchas soluciones, pero es importante en mi caso.

Estoy buscando consejos reales, mejores prácticas y errores a tener en cuenta cuando se trata de bases de datos distribuidas/de documentos. Y en particular las áreas relacionadas con las aplicaciones de comercio electrónico (estilo carrito de compras) que tradicionalmente son más fáciles de armar con una base de datos relacional.

Entiendo que usar este tipo de DB es un reto, pero bueno, Google y E-bay los usan para que no sean tan difíciles ;-) Cualquier consejo sería apreciado.

Answer 1

¡Cómo se logra una alta disponibilidad y escalabilidad usando bases de datos relacionales es bien conocido y hay un vasto cuerpo de conocimiento sobre cómo hacer esto!

Google es un caso especial que no se aplica a la mayoría de los sitios, volúmenes de consultas muy grandes, cantidades muy grandes de datos y, lo que es más importante, no hay acuerdos de nivel de servicio con la mayoría de sus usuarios. No hay una respuesta correcta para una búsqueda web, solo mejores respuestas, para el usuario promedio Google es lo suficientemente bueno, si Google pierde una página vital de una lista de búsqueda que usted como usuario no puede quejarse.

E-Bay es un caso bastante diferente, de alguna manera han persuadido a los usuarios y clientes a aceptar un servicio deficiente a cambio de precios teóricamente más bajos, bien pero no es una opción para todas las empresas.

Answer 2

Si quiere tener un Sistema distribuido (esa consistencia eventual) necesita personas, construir, mantener y operarlo.

He encontrado que hay tres clases de personas que tienen problemas muy pequeños con "La consistencia eventual":

• Las personas con una sólida formación en sistemas distribuidos. Han aprendido sobre Eventual Consistency Byzantine Failures y cosas por el estilo. Si comprende que Paxos no se trata de vacaciones, probablemente sea una de ellas.
• Personas con experiencia en programación de redes. Pueden pasar por alto los antecedentes teóricos, pero tienen una comprensión intuitiva de la asincronía y el paradigma "no global clock & counters". Si posee al menos 8 libros por Richard Stevens, probablemente sea uno de ellos.
• Codificadores muy experimentados que tenían poca exposición a RDBMS. Me vienen a la mente chicos de Kernel, personas de informática científica y la industria del juego.

En general, estas personas son muy buscadas en el mercado de trabajo. Por ejemplo, aproximadamente el 75% de los académicos en sistemas distribuidos se van para las instituciones que ejecutan sistemas distribuidos grandes, de diseño propio, p. las bolsas de valores.

Todo se volvió algo más simple con ofertas como Hardoop, SimpleDB y CouchDB, pero sigue siendo un gran desafío crear algo sobre tecnología de sistemas distribuidos.

Por otro lado RDBMS son una muy buena pieza de ingeniería. Son bien entendidos y la experiencia en ellos está disponible en el mercado de trabajo. Hay muchas herramientas decentes, oportunidades de educación y muchos expertos altamente calificados están disponibles para alquilar por hora. Así que piense dos veces que no puede seguir con un enfoque de RDBMS, quizás junto con algún engaño inteligente. Usualmente señalo a los estudiantes al Lifejournal architecture.

Para bases de datos distribuidas hay mucha menos experiencia. Esa es exactamente la razón por la que has encontrado tan pocos consejos hasta ahora.

Si está decidido a usar "Consistencia eventual", creo que además de las herramientas inmaduras, el principal desafío es la mentalidad de todos los involucrados. ¿Sus usuarios de API (codificadores) y usuarios de aplicaciones (sus empleados y sus clientes) están dispuestos y son capaces de aceptar la incoherencia? ¿Puedes esconderlo de ciertas clases de usuarios? No estamos acostumbrados a esa mentalidad de que las computadoras son inconsistentes. Algo está en stock o no. "Quizás" no es una respuesta que esperan los usuarios.

También tenga en cuenta que "eventual" puede significar un tiempo muy largo para los diseñadores de algoritmos. ¿Por cuánto tiempo puede aceptar la inconsistencia?

Para una aplicación de carrito de la compra es posible que desee distribuir verdaderamente: utilice el navegador de clientes como almacén de datos. Al finalizar la compra, puede enviar el carro al sistema de procesamiento por lotes del lado del servidor. Esto significa que para el catálogo necesita leer solo alta disponibilidad (más fácil) y la presentación del carro es una interfaz muy estrecha sin necesidad de transacciones. Más tarde, el procesamiento de la orden no tiene requisitos de tiempo real (Blandos) y, por lo tanto, es más fácil.

BTW: La última vez que revisé la arquitectura de E-Bay, tenían un gran tamaño en RDBMS, pero puede haber cambiado desde entonces. (Edit: sí cambio - ver comentarios)

Answer 3

Todos los sistemas basados ​​en modelos de computación distribuida se basan en CAP y BASE. Aquí la principal preocupación es: si nuestro sistema proporciona disponibilidad y tolerancia de partición, no podemos tener una verdadera coherencia, pero podemos tener una coherencia final.

La idea detrás de la coherencia final es que cada nodo siempre está disponible para atender las solicitudes. Como compensación, las modificaciones de datos se propagan en segundo plano a otros nodos. Esto significa que en cualquier momento el sistema puede ser inconsistente, pero los datos aún son en gran parte precisos.

Fuente: http://www.techspritz.com/eventual-consistency-and-base-model/

Answer 4

La única solución a su problema es decidir cuál de los equilibrios en el CAP theorem son adecuados para usted, a continuación, comenzar a implementarlo.

mdorseif tiene un gran punto. Hay muchas configuraciones de hasta qué punto intercambias consistencia, disponibilidad y particionamiento. Tienes dos opciones principales.

1. ir a la ruta de un sistema distribuido de la casa (se necesita mucha experiencia e investigación)
2. Veterinario y experimentar con una serie de bases de datos distribuidas para decidir lo que puede manejar sus requisitos como escala.

Esto es probablemente una simplificación excesiva. Una tubería real preparada para la producción es un ecosistema. Al menos te llevará por el camino correcto.

Appnexus es una plataforma publicitaria que usa hbase para una alta disponibilidad y consistencia eventual. Hablan mucho sobre esto here.

Un article en http://highscaleability.com describe cómo el New York Times implementado RabbitMQ junto Cassandra través de una WAN para tolerancia a fallos y alta disponibilidad.

MongoDB ofrece una gran flexibilidad para equilibrar la coherencia con la disponibilidad con su implementación de problemas de escritura. Tienen un excelente documentation que resalta exactamente cómo implementarlo con todos los errores (incluido el particionamiento). Implementan el two-phase commit para mantener el estado en toda la red (en sus servidores de configuración).

Google tiene un gran documento sobre este tema, su proyecto photon implementa un sistema altamente escalable y altamente confiable con el paxos algoritm at the heart of it junto con algunas otras técnicas. También es muy consistente (con una latencia de extremo a extremo de aproximadamente 10 s) y tolerante a fallas, lo que hace frente a fallas regionales.