¿Balsa o no? La mejor solución para la coherencia de datos en bases de datos nativas de la nube
Imagen de portada
Este artículo ha sido escrito por Xiaofan Luan y transcrito por Angela Ni.
La replicación basada en el consenso es una estrategia ampliamente adoptada en muchas bases de datos distribuidas nativas de la nube. Sin embargo, tiene ciertas deficiencias y definitivamente no es la bala de plata.
Este artículo pretende explicar en primer lugar los conceptos de replicación, consistencia y consenso en una base de datos distribuida y nativa de la nube, después aclarar por qué los algoritmos basados en el consenso como Paxos y Raft no son la panacea y, por último, proponer una solución a la replicación basada en el consenso.
Ir a:
- Comprender la replicación, la consistencia y el consenso
- Replicación basada en el consenso
- Una estrategia de replicación de registros para bases de datos distribuidas y nativas de la nube
- Resumen
Comprender la replicación, la consistencia y el consenso
Antes de profundizar en los pros y contras de Paxos y Raft, y proponer la estrategia de replicación de logs más adecuada, necesitamos desmitificar los conceptos de replicación, consistencia y consenso.
Nótese que este artículo se centra principalmente en la sincronización de datos/logs incrementales. Por lo tanto, cuando se habla de replicación de datos/logs, sólo se hace referencia a la replicación de datos incrementales, no de datos históricos.
Replicación
La replicación es el proceso de hacer múltiples copias de datos y almacenarlas en diferentes discos, procesos, máquinas, clusters, etc, con el propósito de aumentar la fiabilidad de los datos y acelerar las consultas de datos. Dado que en la replicación los datos se copian y almacenan en múltiples ubicaciones, los datos son más fiables frente a la recuperación de fallos de disco, fallos de máquinas físicas o errores de clúster. Además, las réplicas múltiples de datos pueden aumentar el rendimiento de una base de datos distribuida al acelerar enormemente las consultas.
Existen varios modos de replicación, como la replicación síncrona/asíncrona, la replicación con consistencia fuerte/eventual, la replicación líder-seguidor/descentralizada. La elección del modo de replicación influye en la disponibilidad y la coherencia del sistema. Por lo tanto, tal y como se propone en el famoso teorema CAP, un arquitecto de sistemas debe elegir entre consistencia y disponibilidad cuando la partición de la red es inevitable.
Consistencia
En resumen, la consistencia en una base de datos distribuida se refiere a la propiedad que asegura que cada nodo o réplica tiene la misma visión de los datos cuando escribe o lee datos en un momento dado. Para una lista completa de niveles de consistencia, lee el documento aquí.
Para aclarar, aquí estamos hablando de consistencia como en el teorema CAP, no ACID (atomicidad, consistencia, aislamiento, durabilidad). La consistencia en el teorema CAP se refiere a que cada nodo del sistema tenga los mismos datos, mientras que la consistencia en ACID se refiere a que un único nodo aplique las mismas reglas en cada commit potencial.
Por lo general, las bases de datos OLTP (procesamiento de transacciones en línea) requieren una fuerte consistencia o linealidad para garantizar que:
- Cada lectura pueda acceder a los últimos datos insertados.
- Si se devuelve un nuevo valor después de una lectura, todas las lecturas siguientes, independientemente de que se realicen en el mismo cliente o en clientes diferentes, deben devolver el nuevo valor.
La esencia de la linealidad es garantizar la recencia de múltiples réplicas de datos: una vez que se escribe o se lee un nuevo valor, todas las lecturas posteriores pueden ver el nuevo valor hasta que éste se sobrescriba posteriormente. Un sistema distribuido que ofrezca linealidad puede ahorrar a los usuarios la molestia de vigilar múltiples réplicas y puede garantizar la atomicidad y el orden de cada operación.
Consenso
El concepto de consenso se introduce en los sistemas distribuidos porque los usuarios desean que los sistemas distribuidos funcionen del mismo modo que los sistemas autónomos.
Para simplificarlo, el consenso es un acuerdo general sobre un valor. Por ejemplo, Steve y Frank querían comer algo. Steve sugirió comer sándwiches. Frank acepta la sugerencia de Steve y ambos comen sándwiches. Han llegado a un consenso. Más concretamente, un valor (sándwiches) propuesto por uno de ellos es acordado por ambos, y ambos realizan acciones basadas en el valor. Del mismo modo, el consenso en un sistema distribuido significa que cuando un proceso propone un valor, todos los demás procesos del sistema lo aceptan y actúan en consecuencia.
Consenso
Replicación basada en el consenso
Los primeros algoritmos basados en el consenso se propusieron junto con la replicación con sello de vista en 1988. En 1989, Leslie Lamport propuso Paxos, un algoritmo basado en el consenso.
En los últimos años, hemos sido testigos de otro algoritmo basado en el consenso que ha prevalecido en la industria: Raft. Ha sido adoptado por muchas bases de datos NewSQL como CockroachDB, TiDB, OceanBase, etc.
En particular, un sistema distribuido no es necesariamente linealizable aunque adopte la replicación basada en el consenso. Sin embargo, la linealidad es un requisito previo para crear una base de datos distribuida ACID.
Al diseñar un sistema de base de datos, debe tenerse en cuenta el orden de confirmación de los registros y las máquinas de estado. También es necesario tomar precauciones adicionales para mantener el arrendamiento líder de Paxos o Raft y evitar una división del cerebro en caso de partición de la red.
Máquina de estado de replicación Raft
Ventajas e inconvenientes
De hecho, Raft, ZAB y el protocolo de registro basado en quórum de Aurora son variaciones de Paxos. La replicación basada en el consenso tiene las siguientes ventajas:
- Aunque la replicación basada en el consenso se centra más en la consistencia y la partición de la red en el teorema CAP, proporciona una disponibilidad relativamente mejor en comparación con la replicación tradicional líder-seguidor.
- Raft es un gran avance que ha simplificado enormemente los algoritmos basados en el consenso. Y hay muchas bibliotecas Raft de código abierto en GitHub (por ejemplo, sofa-jraft).
- El rendimiento de la replicación basada en el consenso puede satisfacer la mayoría de las aplicaciones y empresas. Con la cobertura de SSD de alto rendimiento y NIC (tarjeta de interfaz de red) de gigabyte, se alivia la carga de sincronizar múltiples réplicas, lo que convierte a los algoritmos Paxos y Raft en la corriente principal de la industria.
Una idea errónea es que la replicación basada en el consenso es la panacea para lograr la coherencia de los datos en una base de datos distribuida. Sin embargo, esto no es cierto. Los problemas de disponibilidad, complejidad y rendimiento a los que se enfrenta el algoritmo basado en el consenso impiden que sea la solución perfecta.
Disponibilidad comprometida El algoritmo optimizado Paxos o Raft tiene una fuerte dependencia de la réplica líder, que viene acompañada de una débil capacidad para luchar contra los fallos grises. En la replicación basada en el consenso, una nueva elección de la réplica líder no tendrá lugar hasta que el nodo líder no responda durante un largo periodo de tiempo. Por lo tanto, la replicación basada en consenso es incapaz de manejar situaciones en las que el nodo líder es lento o se produce un thrashing.
Alta complejidad Aunque ya existen muchos algoritmos extendidos basados en Paxos y Raft, la aparición de Multi-Raft y Parallel Ra ft requiere más consideraciones y pruebas sobre la sincronización entre registros y máquinas de estado.
Rendimiento comprometido En una era nativa de la nube, el almacenamiento local se sustituye por soluciones de almacenamiento compartido como EBS y S3 para garantizar la fiabilidad y coherencia de los datos. Como resultado, la replicación basada en el consenso ya no es una necesidad para los sistemas distribuidos. Es más, la replicación basada en consenso viene con el problema de la redundancia de datos, ya que tanto la solución como EBS tienen múltiples réplicas.
Para la replicación en múltiples centros de datos y múltiples nubes, la búsqueda de la coherencia compromete no sólo la disponibilidad, sino también la latencia, lo que se traduce en una disminución del rendimiento. Por lo tanto, la linealidad no es imprescindible para la tolerancia a desastres en múltiples centros de datos en la mayoría de las aplicaciones.
Una estrategia de replicación de logs para bases de datos distribuidas y nativas de la nube
Es innegable que los algoritmos basados en el consenso, como Raft y Paxos, siguen siendo los principales algoritmos adoptados por muchas bases de datos OLTP. Sin embargo, observando los ejemplos del protocolo PacificA, Socrates y Rockset, podemos ver que la tendencia está cambiando.
Hay dos principios fundamentales para una solución que pueda servir mejor a una base de datos distribuida y nativa de la nube.
1. La replicación como servicio
Se necesita un microservicio independiente dedicado a la sincronización de datos. El módulo de sincronización y el módulo de almacenamiento ya no deben estar estrechamente acoplados dentro del mismo proceso.
Por ejemplo, Sócrates desacopla el almacenamiento, el registro y la computación. Hay un servicio de registro dedicado (servicio XLog en el centro de la figura siguiente).
Arquitectura de Sócrates
El servicio XLog es un servicio individual. La persistencia de los datos se consigue con la ayuda de un almacenamiento de baja latencia. La zona de aterrizaje en Sócrates se encarga de mantener tres réplicas a una velocidad acelerada.
Servicio XLog de Sócrates
El nodo líder distribuye los logs a log broker de forma asíncrona, y descarga los datos a Xstore. La caché SSD local puede acelerar la lectura de datos. Una vez que la descarga de datos se realiza correctamente, los búferes de la zona de aterrizaje pueden limpiarse. Obviamente, todos los datos de registro se dividen en tres capas: zona de aterrizaje, SSD local y XStore.
2. Principio de la muñeca rusa
Una forma de diseñar un sistema es seguir el principio de la muñeca rusa: cada capa está completa y perfectamente adaptada a lo que hace para que otras capas puedan construirse sobre ella o a su alrededor.
Al diseñar una base de datos nativa de la nube, tenemos que aprovechar inteligentemente otros servicios de terceros para reducir la complejidad de la arquitectura del sistema.
Parece que con Paxos no podemos evitar el fallo de punto único. Sin embargo, aún podemos simplificar en gran medida la replicación de registros pasando la elección del líder a los servicios Raft o Paxos basados en Chubby, Zk y etcd.
Por ejemplo, la arquitectura de Rockset sigue el principio de la muñeca rusa y utiliza Kafka/Kineses para los registros distribuidos, S3 para el almacenamiento y una caché SSD local para mejorar el rendimiento de las consultas.
Arquitectura de Rockset
El enfoque Milvus
La consistencia ajustable en Milvus es, de hecho, similar a las lecturas seguidas en la replicación basada en el consenso. La función de lecturas seguidas se refiere al uso de réplicas seguidas para realizar tareas de lectura de datos bajo la premisa de una consistencia fuerte. El objetivo es mejorar el rendimiento del clúster y reducir la carga del líder. El mecanismo que subyace a la función de lectura de seguidores consiste en consultar el índice de confirmación del último registro y proporcionar un servicio de consulta hasta que todos los datos del índice de confirmación se apliquen a las máquinas de estado.
Sin embargo, el diseño de Milvus no adopta la estrategia de seguimiento. En otras palabras, Milvus no consulta el índice de confirmación cada vez que recibe una solicitud de consulta. En su lugar, Milvus adopta un mecanismo como la marca de agua en Flink, que notifica al nodo de consulta la ubicación del índice de commit a intervalos regulares. La razón de este mecanismo es que los usuarios de Milvus no suelen tener una gran demanda de consistencia de datos, y pueden aceptar un compromiso en la visibilidad de los datos para un mejor rendimiento del sistema.
Además, Milvus también adopta múltiples microservicios y separa el almacenamiento de la computación. En la arquitectura de Milvus, S3, MinIo y Azure Blob se utilizan para el almacenamiento.
Arquitectura Milvus
Resumen
En la actualidad, un número cada vez mayor de bases de datos nativas de la nube están haciendo de la replicación de logs un servicio individual. Al hacerlo, se puede reducir el coste de añadir réplicas de solo lectura y replicación heterogénea. El uso de múltiples microservicios permite una rápida utilización de la infraestructura madura basada en la nube, lo que es imposible para las bases de datos tradicionales. Un servicio de registro individual puede confiar en la replicación basada en el consenso, pero también puede seguir la estrategia de la muñeca rusa para adoptar varios protocolos de consistencia junto con Paxos o Raft para lograr la linealidad.
Referencias
- Lamport L. Paxos simplificado[J]. ACM SIGACT News (Distributed Computing Column) 32, 4 (Número entero 121, diciembre de 2001), 2001: 51-58.
- Ongaro D, Ousterhout J. En busca de un algoritmo de consenso comprensible[C]//2014 USENIX Annual Technical Conference (Usenix ATC 14). 2014: 305-319.
- Oki B M, Liskov B H. Replicación Viewstamped: A new primary copy method to support highly-available distributed systems[C]//Proceedings of the seventh annual ACM Symposium on Principles of distributed computing. 1988: 8-17.
- Lin W, Yang M, Zhang L, et al. PacificA: Replication in log-based distributed storage systems[J]. 2008.
- Verbitski A, Gupta A, Saha D, et al. Amazon aurora: On avoiding distributed consensus for i/os, commits, and membership changes[C]//Proceedings of the 2018 International Conference on Management of Data. 2018: 789-796.
- Antonopoulos P, Budovski A, Diaconu C, et al. Socrates: El nuevo servidor sql en la nube[C]//Proceedings of the 2019 International Conference on Management of Data. 2019: 1743-1756.
- Comprender la replicación, la consistencia y el consenso
- Replicación basada en el consenso
- Una estrategia de replicación de logs para bases de datos distribuidas y nativas de la nube
- Resumen
- Referencias
On This Page
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word