Las transacciones ACID están llegando a Apache Cassandra: He aquí por qué estamos emocionados

An extraordinary computer science breakthrough called Accord is bringing globally available, general-purpose ACID transactions to the next Cassandra release

Saquemos la mejor parte primero. Las transacciones ACID están llegando a Apache Cassandra.

Transacciones de propósito general disponibles globalmente que funcionan de la misma manera que lo hace Cassandra. Esto no es un truco con letra pequeña o la aplicación de técnicas antiguas.

Se debe a un extraordinario avance en informática llamado Accord de un equipo de Apple y la Universidad de Michigan. Ayudará a Cassandra a cambiar la forma en que pensamos en los datos al abrir nuevos casos de uso.

Esto es lo que esto significa para aquellos que no están familiarizados con los entresijos del proyecto Cassandra y sus características. Nada es más importante que la rapidez con la que puede poner una aplicación en producción. Pero los desarrolladores que quieren poner la escala, la resiliencia y el legendario soporte de múltiples centros de datos de Cassandra para trabajar en algo como las transacciones financieras tuvieron que codificar un montón de soluciones alternativas complicadas en sus aplicaciones. Las ventajas y desventajas frente al uso, digamos, de Oracle fueron significativas.

con acuerdo? Sin compensaciones. Cassandra ahora admitirá todo lo que lo ha hecho increíble mientras cambia el soporte de transacciones a la base de datos, lo que reduce significativamente la complejidad del código.

El ojo del observador

Un sistema de base de datos tiene funciones esenciales, como almacenar datos de manera confiable y estar disponible para consultas. La gestión de cambios en los datos no siempre es una función de la base de datos. En el caso de muchos sistemas NoSQL, la carga de la gestión de cambios se delega al usuario. El observador del cambio de datos es quien asigna la importancia de la exclusividad.

Supongamos que el punto es acumular datos tal como se dan. En ese caso, el observador debe saber que los datos se recibieron y almacenaron de forma duradera, por ejemplo, datos de cotizaciones bursátiles donde cada punto de datos es único y acumulativo. No hay necesidad de exclusividad.

En operaciones más sensibles, el observador de un cambio de datos debe sentir que es el único proceso que utiliza la base de datos. Es un concepto en informática llamado “aislamiento”; es la “I” en ACID (atomicidad, consistencia, aislamiento, durabilidad).

Un ejemplo clásico es una transferencia bancaria en la que se resta dinero de una cuenta bancaria y luego se suma a otra, precisamente en ese orden. El proceso de observación necesita exclusividad para evitar que otros procesos realicen cambios que puedan generar inconsistencias o sorpresas.

Las sorpresas incluyen permitir inadvertidamente una transferencia desde una cuenta que ha bajado a menos de $0.

El aislamiento garantiza que solo un proceso pueda realizar un cambio a la vez, y si dos compiten por los mismos datos, uno de ellos tendrá que esperar a que el otro se complete.

Abraza tu pereza

Los desarrolladores necesitan moverse rápidamente con un sistema en el que puedan confiar. Las transacciones ACID han sido el estándar de oro de la confianza dentro de los sistemas de bases de datos durante casi 50 años. Los desarrolladores trabajan a través de compensaciones basadas en requisitos, lo que a veces los lleva a trabajar con sistemas que no admiten transacciones ACID.

Con los sistemas NoSQL, los sesgos de compensación históricamente tendían a inclinarse hacia la escala y el tiempo de actividad mientras se sacrificaban las transacciones.

Llevar las transacciones ACID a Cassandra se ha tratado de reducir las compensaciones. Cassandra ya tiene una sólida reputación de escalado lineal mientras mantiene el tiempo de actividad en los peores escenarios.

Cassandra ha sido la elección cuando necesita una base de datos que aguante lo que Internet puede ofrecer. Como era de esperar, la necesidad de transacciones ha sido una fuente de conflicto de compensación para los desarrolladores.

¿Podemos obtener un consenso?

En los sistemas distribuidos, cada nodo miembro del clúster más grande puede actuar de forma independiente o necesita coordinarse con otros nodos. En una transacción en la que, "Oye, todos debemos estar de acuerdo en algo", los informáticos llaman a esto consenso, y el desarrollo de esos protocolos es un área de mejora continua.

Paxos ha sido un protocolo de consenso de larga data adoptado por Cassandra en 2013 para "transacciones ligeras".

Ligero porque garantiza que un solo cambio de datos de partición esté aislado en una transacción, pero más de una tabla o partición no es una opción. Además, Paxos requiere múltiples viajes de ida y vuelta para obtener un consenso, lo que crea mucha latencia adicional y letra pequeña sobre cuándo usar transacciones ligeras en su aplicación.

El protocolo Raft se desarrolló como la próxima generación para reemplazar a Paxos, y varios sistemas como Etcd, CockroachDB y DynamoDB lo adoptaron. Redujo los viajes de ida y vuelta al crear un líder electo.

La desventaja de Cassandra en este enfoque es que los líderes no abarcarán los centros de datos, por lo que se requieren varios líderes (consulte Spanner ).

Tener un líder electo también viola los principios de "no compartir nada" de Cassandra y agregaría nuevos requisitos para manejar el fracaso.

Si un nodo falla, se debe elegir un nuevo líder.

Otras bases de datos (FaunaDB y FoundationDB, por ejemplo) han seguido el camino de tratar de resolver el problema de múltiples líderes reduciéndolos a un solo líder global, como se describe en el artículo de Calvin .

Debido a que se crearon para otras bases de datos con diferentes requisitos, los enfoques utilizados en esos casos no cumplieron con los criterios que Cassandra espera con los modos de falla.

Cassandra asume las fallas como parte de la ejecución de un sistema distribuido extenso. Uno o más nodos que se desconectan no deberían causar una degradación rápida del rendimiento ni problemas de disponibilidad. Necesitábamos un enfoque diferente.

¿Hemos llegado a un acuerdo?

Podemos tener muchas opiniones sobre lo que es aceptable para el proyecto Cassandra. Nuestros criterios se basan en mantenernos fieles a las creencias fundamentales sobre cómo deben funcionar los sistemas distribuidos. Siempre se debe preservar el rendimiento y el escalado mientras se operan múltiples nodos en uno o más centros de datos. Podemos ser bastante exigentes, pero esto es lo que convierte a Cassandra en la elección de tantas organizaciones.

Las iteraciones anteriores de los protocolos de consenso resolvieron diferentes partes del problema, pero cada una presentó una compensación que violaría algunos de los valores de Cassandra. Se ha dicho que el próximo gran avance está a dos artículos del último. En este caso, el papel era Accord , y se necesitó un gran golpe para eliminar las compensaciones.

Accord aborda dos problemas que no se resuelven en los protocolos de consenso anteriores: ¿Cómo podemos tener un consenso disponible a nivel mundial y lograrlo en un viaje de ida y vuelta? El primer mecanismo novedoso es el búfer de reorden.

Suponiendo que se utilice hardware básico, las diferencias en los relojes entre nodos son inevitables. El búfer de reorden mide la diferencia entre nodos además de la latencia entre ellos. Cada réplica puede usar esta información para ordenar correctamente los datos de cada nodo y tener en cuenta las diferencias, lo que garantiza un consenso de ida y vuelta con un protocolo de marca de tiempo.

El otro mecanismo son los electorados de vía rápida. Los modos de falla pueden crear latencia al elegir un nuevo líder antes de reanudar. Los electores de ruta rápida utilizan características preexistentes en Cassandra con algunas implementaciones novedosas para mantener una ruta rápida sin líderes hacia el quórum bajo el mismo nivel de falla tolerado por Cassandra. Se pueden leer más detalles en la propuesta .

¿Como funciona?

El mayor impacto será en la productividad del desarrollador, así que veamos cómo se ve eso en la práctica. Considere el siguiente ejemplo de transferencia de cuenta bancaria que mencionamos anteriormente:

Primero está la nueva sintaxis que verá en Cassandra Query Language (CQL). Las transacciones están contenidas en una declaración BEGIN TRANSACTION y COMMIT TRANSACTION . Todo lo que se encuentre dentro de los marcadores de transacción ocurrirá de forma atómica, aislado de otros procesos. Transferiremos $20 de la cuenta de Alice a Bob en este ejemplo. ¡No hay nada más clásico que eso!

En la sección A, podemos seleccionar datos de un registro existente y asignar el resultado a una tupla (múltiples elementos almacenados en una sola variable). Dependiendo de cuántas columnas haya en la cláusula SELECT , puede almacenar uno o más valores en la tupla. Estos valores se utilizarán en la sección B para probar las condiciones antes de realizar cambios en los datos.

En este caso, haremos una prueba para ver si Alice tiene $20 en su cuenta antes de transferir a Bob. Si es así, entonces una UPDATE disminuye el saldo de la cuenta de Alice en $20 y luego incrementa el de Bob en $20. Si Alice tuviera menos de $20, entonces los cambios no ocurrirían.

Detrás de escena hay un conjunto serializado de comandos de base de datos que se ejecutan exclusivamente, como se ve desde el proceso de observación. En uno o más centros de datos, la transacción solo requirió un viaje de ida y vuelta para obtener el consenso, y si algún nodo estaba fuera de línea, la acción aún ocurriría si hubiera al menos un quórum de réplicas disponible.

Así es exactamente como le gusta trabajar a Cassandra, pero acabamos de mejorar nuestro juego con una transacción disponible a nivel mundial.

Que sigue

Accord y todo el trabajo que lo acompaña todavía está en progreso y está programado para ser incluido en el próximo lanzamiento de Cassandra. Dado que todo esto es de código abierto, aquellos de ustedes que no pueden esperar pueden clonar una copia de la rama cep-15-accord del repositorio de Cassandra y construir su propia copia.

Para el resto de ustedes, a medida que nos acerquemos al tiempo de lanzamiento, tendremos compilaciones disponibles para que las usen y las prueben. Será un cambio de juego para Cassandra, y estoy seguro de que querrás verlo por ti mismo.

Estoy más interesado en saber de la comunidad qué casos de uso encontrará con una transacción disponible a nivel mundial que se ejecuta a la velocidad y la resistencia que espera de Cassandra. ¿Es finalmente el momento de dejar de lado esas últimas cargas de trabajo de bases de datos relacionales?

También estamos ansiosos por escuchar sus comentarios sobre todos nuestros canales, incluido Apache Software Foundation Slack o la lista de correo del proyecto . Las características de un proyecto de código abierto están en constante evolución para satisfacer las necesidades de los usuarios. Es por eso que tiene un papel fundamental que desempeñar en la configuración de Apache Cassandra para el futuro.

Y manténgase atento a más casos de uso e información a medida que desarrollamos esta nueva y emocionante función. Puede esperar que haya varias charlas sobre esto en la cumbre digital Cassandra Forward que se realizará el 14 de marzo. No querrá perdérselas.

Por Patrick McFadin, DataStax

Patrick McFadin es coautor del libro de O'Reilly 'Managing Cloud Native Data on Kubernetes'. Actualmente trabaja en DataStax en relaciones con desarrolladores y como colaborador del proyecto Apache Cassandra. Patrick ha trabajado como evangelista jefe de Apache Cassandra (¡también es un committer recién nombrado de Cassandra!) y como consultor de DataStax, donde se divirtió mucho creando algunas de las implementaciones más grandes en producción.