El CTO de Couchbase, Ravi Mayuram, anunció Transacciones Distribuidas Multi-documento ACID en Couchbase Server 6.5. Recomiendo encarecidamente leyendo el blog de Ravi que destaca cómo las transacciones de Couchbase son una unión innovadora de garantías ACID con escala, alta disponibilidad, rendimiento y flexibilidad.
En este blog, profundizaré en nuestra tecnología distribuida Transacciones ACID funcionalidad.
Sencillo pero potente
Primero veamos lo fácil que es escribir una transacción en Couchbase. Abres una transacción, haces algo de trabajo y envías (o fallas) con Atomicidad, Consistencia, Isolación y Durabilidad. Aprovechando el SDK y las APIs regulares de Couchbase, puedes utilizar las capacidades de la plataforma de programación subyacente. Aquí hay un fragmento de código que muestra un débito/crédito básico transfiriendo fondos de una cuenta a otra con una transacción ACID:
Hay muchas capacidades incorporadas para hacer la programación con transacciones en Couchbase sin fricciones:
- Confirmación o reversión automática con flexibilidad para hacerlo explícitamente.
- Reintentos automáticos para errores transitorios, como retrasos de durabilidad debidos a fallos de la red o conflictos de bloqueo.
- Duración configurable de una transacción. Los bloqueos se resuelven automáticamente, ya que una de las transacciones agota el tiempo de espera y libera sus recursos.
- Limpieza automática de transacciones huérfanas si el cliente se bloquea.
Si desea un tutorial rápido sobre programación con la API Java de transacciones y un ejemplo de código descargable, consulte Blog y vídeo de Graham Pople.
Garantías ACID
Las transacciones de Couchbase proporcionan Atomicidad, Consistencia, Aislamiento y Durabilidad como requieren las garantías ACID:
- Atomicidad y Durabilidad son propiedades binarias: se tienen o no se tienen.
- Aislamiento es un espectro con compensaciones. Bases de datos relacionales populares como Oracle, MySQL,SQL Server han elegido diferentes niveles de aislamiento por defecto y máximos.
- Coherencia tiene significados diferentes para el público del ACID tradicional y para el público de los sistemas distribuidos. La definición tradicional de ACID dice que una transacción debe llevar a la base de datos de un estado válido a otro. La definición de sistemas distribuidos derivada del teorema CAP dice que cada lectura debe recibir la última escritura, aunque esto empieza a sonar un poco como semántica de aislamiento.
Aquí hay un resumen de las garantías ACID proporcionadas por las transacciones en Couchbase Server 6.5.
| Atomicidad | Semántica "todo o nada" para actualizar múltiples documentos en múltiples shards en diferentes nodos. |
| Consistencia | Las réplicas son inmediatamente consistentes con la confirmación de la transacción.
GSI, FTS, XDCR son finalmente coherentes con el commit de la transacción (N1QL puede reforzar la consistencia en la lectura con request_plus) |
| Isolación | Lectura Aislamiento comprometido para todos los lectores concurrentes - lecturas transaccionales o no transaccionales |
| Durabilidad | 3 niveles de durabilidad disponibles para la protección de datos:
|
Sí, están distribuidos
Las transacciones ACID de Couchbase son multi-documento y multi-nodo - por lo que son verdaderamente distribuidas como puedes ver en la ilustración simplificada de la arquitectura de Couchbase de abajo. La ilustración muestra un cluster simple de Couchbase con 3 nodos y 9 vbuckets/shards con 2 réplicas (total 3 copias de datos). La transacción modifica dos documentos, Andy y Beth, con su copia activa en dos nodos separados. La finalización con éxito de la transacción garantizará que la copia activa de cada uno de los dos documentos así como la mayoría de sus copias totales (que en este caso significa 1 de 2 réplicas además de la activa) se actualizan con el nuevo valor. El fallo garantizará que el estado no cambia y es idéntico al anterior a la transacción.
Desglose de funciones
Mientras que el resumen de ACID proporciona una perspectiva de alto nivel, los siguientes detalles proporcionan una comprensión más profunda de la semántica:
Múltiples nodos, cubos y documentos
Una única transacción puede abarcar múltiples documentos, en múltiples buckets, en múltiples nodos. Como en Couchbase, un bucket corresponde a una base de datos, una transacción puede abarcar múltiples bases de datos en el mismo cluster de Couchbase. Esto, junto con la capacidad de Couchbase para realizar JOINs a través de buckets, da una enorme flexibilidad a la aplicación.
Los consumidores de DCP sólo pueden leer los datos comprometidos
Todas las lecturas realizadas de cualquier manera, incluyendo desde N1QL, XDCR, Analytics, Mobile, Eventing, Connectors sólo devolverán datos comprometidos. Nadie podrá leer datos no comprometidos o sucios. El protocolo Couchbase Data Change Protocol (DCP) asegura que ningún dato intermedio no comprometido sea leído por un consumidor.
Bloqueo y detección de conflictos
Los conflictos entre transacciones que intentan actualizar los mismos documentos se detectan y gestionan haciendo retroceder una de ellas y volviendo a intentarla (hasta que se agote el tiempo de espera de la transacción, que por defecto es de 15 s). Esto se hace mediante una combinación de métodos optimistas y cierre pesimista a nivel de documento.
Cualquier documento que quieras modificar en una transacción tiene que ser leído primero dentro de la transacción y todas las escrituras son automáticamente escrituras CAS (Check and Set). Por lo tanto, si una transacción lee datos que posteriormente son modificados por otra escritura transaccional (o no transaccional), en el momento de la escritura esta transacción detectará el conflicto CAS, retrocederá y volverá a intentarlo.
En la transacción de débito/crédito anterior, en la que se transfiere dinero de la cuenta de Beth a la cuenta de Andy, si la cuenta de Beth cambia después de que la transacción haya leído su cuenta pero antes de que la haya modificado, la transacción lo detectará, retrocederá y volverá a intentarlo.
Una vez modificado el documento en la transacción, ésta obtiene implícitamente un bloqueo de escritura sobre el documento que sólo se libera cuando finaliza la transacción. Si una segunda transacción intenta modificar un documento que ya está bloqueado por una transacción, esta última detectará el conflicto de escritura, hará un rollback y volverá a intentarlo hasta que finalice el tiempo de espera de la transacción.
Volviendo al ejemplo anterior de débito/crédito, supongamos una transacción en vuelo en la que la cuenta de Beth ha sido deducida pero la de Andy aún no ha sido actualizada. En este punto, el documento de la cuenta de Beth está bloqueado. Así que si otra transacción para transferir dinero de la cuenta de Beth a la cuenta de Bill se está intentando al mismo tiempo, se detectará el conflicto de escritura en Beth y se revertirá.
Durabilidad sincrónica
En Couchbase Server 6.5, tenemos una nueva implementación del protocolo de replicación que asegura que una mutación sea visible para los lectores sólo después de haber cumplido con sus criterios de replicación/persistencia y puede ser revertida si esos criterios no se cumplen. Este nuevo mecanismo de replicación está siendo sometido a exhaustivas pruebas internas en Jepsen. leer el blog de Korrigan para saber más.
La replicación síncrona proporciona una durabilidad ajustable que le permite elegir el nivel de protección contra fallos (caída de nodo, fallo de disco, fallos únicos o múltiples) que desea para cada escritura. Hay 3 niveles para elegir:
- mayoría - este nivel de durabilidad garantiza que la escritura se propague a la mayoría de las réplicas antes de que se devuelva (por ejemplo, si el clúster está configurado con 2 réplicas, se escribirá en la RAM de la activa y se propagará al menos a 1 réplica antes de devolver el éxito a la aplicación)
- persistToActive - este nivel asegura que la escritura se propaga en RAM a la mayoría de las réplicas y persiste en disco en el activo antes de devolver el éxito a la aplicación.
- persistToMajority - este nivel garantiza que la escritura se persiste en disco en la mayoría de los nodos antes de devolver el éxito a la aplicación.
Si falla la durabilidad (tiempo de espera, fallo de nodo, etc.), la escritura se revertirá automáticamente y se notificará el fallo al cliente.
Nota: Las nuevas escrituras síncronas de durabilidad son aplicables tanto a las transacciones como a las mutaciones de un solo documento.
Nota: Si no se especifica ningún nivel de durabilidad, entonces se gestiona de forma asíncrona, lo que eventualmente es duradero.
Las transacciones se superponen al nuevo mecanismo de replicación síncrona y, por defecto, establecen el nivel de durabilidad en 'mayoría'. Puede anular el valor predeterminado eligiendo un nivel de durabilidad diferente para cada transacción. persistToMajority proporciona la mayor protección de datos en caso de fallos múltiples.
Cubos efímeros
También se pueden utilizar transacciones y durabilidad síncrona en los buckets efímeros. Hay casos de uso de la caché que no necesitan persistencia, pero todavía quieren asegurarse de que los elementos de la caché se actualizan con garantías ACID.
Próximos pasos
El soporte de transacciones ACID multi-documento en Couchbase Server 6.5 es innovador y abre nuevos casos de uso para su Aplicaciones NoSQL. Nos encantaría recibir sus comentarios y sugerencias sobre las mejoras que necesita para las transacciones. Aquí tiene algunos recursos para empezar:
Descargar
Descargar Couchbase Server 6.5
Documentación
Documentación de Couchbase Transactions 6.5
Guía de Couchbase Transactions 6.5 para SDKs
Blogs
Couchbase lleva las transacciones ACID multidocumento distribuidas a NoSQL
Introducción a Couchbase Transactions Java API[Video]
Anuncio de Couchbase Server 6.5 - Novedades y mejoras
