Ya están disponibles las transacciones ACID distribuidas y multidocumento en Couchbase como parte del lenguaje de consulta N1QL.
Presentación de Couchbase Transacciones ACID en su v6.5 con los SDK de Couchbase, y ahora se ha ampliado al servicio de consulta N1QL de Couchbase en la versión 7.0.
Couchbase proporciona soporte para transacciones ACID multi-documento para su plataforma de base de datos distribuida que es escalable horizontalmente y también soporta alta disponibilidad. Esta función está disponible para los desarrolladores de aplicaciones a través del SDK y las API de Couchbase. Las API permiten a los desarrolladores realizar modificaciones de forma segura en los documentos de la base de datos dentro de una transacción y, a continuación, confirmar o revertir todos los cambios en la transacción en función de la lógica de la aplicación.
Las transacciones de Couchbase funcionan en todas partes: a través de nodos, documentos, buckets, Scopes y Collections. El proceso de transacciones asegura que sólo los datos comprometidos son legibles por otros procesos, y maneja automáticamente el bloqueo y la detección de conflictos.
La versión 7.0 amplía el soporte de transacciones distribuidas a el lenguaje de consulta N1QL.
Para los usuarios de bases de datos relacionales (RDBMS), esta mejora de N1QL proporciona construcciones transaccionales familiares, como por ejemplo INICIAR TRANSACCIÓN
, GUARDAR PUNTO
, ROLLBACK
y COMPROMETERSE
. Las transacciones N1QL también soportan todos los lenguajes de manipulación de datos (DML), lo que está en línea con otras implementaciones RDBMS.
Ventajas de las transacciones N1QL
Las principales ventajas de incorporar el soporte de transacciones distribuidas al lenguaje de consulta N1QL son:
- Un entorno más seguro para la manipulación de datos ad hoc, que permite a los desarrolladores y administradores de bases de datos modificar los datos y verificar su corrección antes de consignar los cambios en la base de datos.
- Una forma sencilla de conceptualizar el proceso que permite a los desarrolladores validar la lógica antes de incrustar las operaciones en el código de la aplicación.
- La funcionalidad completa del lenguaje de manipulación de datos N1QL (seleccionar/insertar/actualizar/borrar/fusionar), que permite realizar operaciones en varios documentos a la vez.
- Compatibilidad total con el SDK de Couchbase, lo que permite a las aplicaciones incluir tanto el servicio de datos como la API de consulta N1QL en la misma transacción.
Las transacciones N1QL permiten que todo lo anterior tenga lugar. Al mismo tiempo, las transacciones N1QL mantienen la integridad de los datos al garantizar que los cambios incompletos se aíslan y no se consignan en la base de datos hasta que se completa la transacción o en caso de cualquier fallo imprevisto del sistema.
Transacciones ACID de Couchbase con N1QL
La función de transacciones N1QL se creó sobre el actual marco de transacciones ACID de Couchbase y, por lo tanto, ofrecía las mismas ventajas que las transacciones ACID de Couchbase. garantías de conformidad total con ACID.
Atomicidad | La semántica de "todo o nada" para la actualización de varios documentos en varios fragmentos o nodos se extiende ahora a la atomicidad a nivel de declaración. Por ejemplo, un ACTUALIZACIÓN que califica 100 documentos debe lograr actualizar todos los documentos o retroceder. No se realizarán actualizaciones parciales. |
Coherencia | El marco de transacciones de Couchbase proporciona el nivel más alto de consistencia para el Servicio de Datos, es decir, las réplicas son inmediatamente consistentes con el commit de la transacción.
Para N1QL no transaccional, la opción de consistencia de escaneo sigue siendo la misma que antes: admite |
Aislamiento | N1QL Aislamiento admite LEER COMPROMETIDO para todos los lectores, independientemente de si la lectura está en una transacción o no. |
Durabilidad | Mientras que el marco de transacciones de Couchbase soporta los tres niveles de durabilidad, las transacciones N1QL a través de no-SDK (WebUI/cbq/RestAPI) serán por defecto "Mayoría".
Consulte la documentación de Couchbase para más detalles sobre la durabilidad. |
Escalabilidad horizontal y transacciones N1QL
Como con cualquier servicio en Couchbase, la escalabilidad horizontal es un requisito clave.
Todo el procesamiento de las transacciones N1QL se inicia en el Servicio de Consulta, y la escalabilidad horizontal se logra a través de lo siguiente:
No hay gestión centralizada de las transacciones: Todas las tareas de transacción y los gastos generales se realizan y mantienen dentro del Servicio de Consulta. En efecto, la gestión de las transacciones se distribuye a través de diferentes servicios de consulta, y por lo tanto no tiene un punto central de fallo.
Volumen y tamaño de las transacciones: El tamaño de la transacción, que actualmente sólo está limitado por los recursos de que dispone el Servicio de Consulta, se escala en función de la complejidad de la transacción. Así, la transacción puede ampliarse rápidamente con nodos adicionales del Servicio de Consulta.
El diagrama anterior pone de relieve los siguientes puntos:
- Las consultas N1QL no transaccionales se sirven mediante cualquier de los Servicios de Consulta disponibles. El Servicio de consulta seleccionado por el SDK viene determinado por el
ns_servidor
y, por lo general, se utiliza un sistema de rotación cíclica. - Para una transacción N1QL ejecutada bajo el contexto de transacción que proporcionan las librerías Couchbase Transactions, todas las operaciones DML subsiguientes (identificadas con
txid
) se dirigen al mismo nodo de consulta, hasta que la transacción se consigna o se revierte. Esto está disponible en Java SDK 1.1.3 - Los SDK gestionan automáticamente la afinidad entre nodos SDK y Query.
- Las transacciones de Couchbase soportan operaciones DML tanto de valor-clave como del Servicio de Consulta a través de la librería de transacciones Java de Couchbase. También puedes acceder a otros servicios, como Full-Text Search y Analytics, con solicitudes de consistencia de escaneo que honran el commit bajo la transacción.
Dónde puede utilizar las transacciones N1QL
La función de transacciones N1QL es compatible en cualquier lugar donde se utilice una consulta N1QL.
El principal requisito es que txid
devuelto por la función INICIAR TRANSACCIÓN
se utiliza con todos los DML N1QL posteriores si forman parte de la transacción. Lo mismo ocurre con el comando final COMPROMETERSE
o ROLLBACK
.
Si está utilizando Query Workbench y cbq shell, pasando txid
se gestiona de forma transparente. No necesitas realizar ninguna acción explícita.
Concha CBQ
Aquí hay un ejemplo de una transacción N1QL usando cbq shell:
1 2 3 4 5 6 7 8 |
cbq> \SET -consulta_contexto "default:`viaje-muestra`._default" cbq> INICIO TRANSACCIÓN; cbq> SELECCIONE CONTAR(*) DESDE aeropuerto DONDE ciudad=Stanted; cbq> ACTUALIZACIÓN aeropuerto SET ciudad=Londres DONDE faa=STN; cbq> GUARDAR PUNTO s1; cbq> BORRAR DESDE aeropuerto DONDE ciudad=Londres Y faa != STN; cbq> ROLLBACK TRANSACCIÓN A GUARDAR PUNTO s1; cbq> COMPROMETERSE TRANSACCIÓN; |
API REST DE N1QL
Una vez que se inicia una transacción, el shell cbq establece una sesión con un servicio de consulta específico y garantiza que todos los DML N1QL posteriores se envíen con la etiqueta txid
(devuelto con TRANSACCIÓN
) al mismo Servicio de Consulta.
Con la API REST, debe proporcionar el valor de la variable txid
con los DML posteriores. Por ejemplo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
>rizo -u Administrador:contraseña http://localhost:8093/query/service -H "Content-Type: application/json" -d '{"statement": "START TRANSACTION", "pretty":true, "txtimeout": "2m", "scan_consistency": "request_plus", "durability_level": "majority", "durability_timeout": "2s"}'. { "requestID": "34d585a7-3c4a-4f0e-8cd3-d3ffa7df0bb3", "firma": "json", "resultados": [ { "txid": "d81d9b4a-b758-4f98-b007-87ba262d3a51" } ], "status": "éxito", "métricas": { "tiempo transcurrido": "4.196083ms", "executionTime": "4.12112ms", "resultCount": 1, "resultSize": 62, "serviceLoad": 0 } } >rizo -u Administrador:contraseña http://localhost:8093/query/service -H 'Content-Type: application/json' -d ' {"declaración":"Declaración SQL", "bonita":verdadero,"txid":"d81d9b4a-b758-4f98-b007-87ba262d3a51"}' |
Ajuste implícito de la transacción
Como parte de las transacciones N1QL, también está la configuración implícita de la transacción: tximplicit
.
En pocas palabras, cuando esto se establece en true, todos los DMLs N1QL subsiguientes se ejecutan como si estuvieran envueltos entre un INICIAR TRANSACCIÓN
y un COMPROMETER TRANSACCIÓN
. Esta configuración significa que puede utilizar todas las mejoras de N1QL que forman parte de la función de transacciones N1QL.
Durabilidad
N1QL no transaccional no soporta actualmente ningún ajuste para la durabilidad. Todas las mutaciones a través de N1QL utilizan durabilidad=ninguna
. Con tximplicit
establecido, el DML N1QL obtiene la durabilidad
Implicaciones: Este tximplicit
le permite establecer indirectamente la durabilidad, pero debe esperar una latencia adicional.
Consistencia de la exploración
La consistencia de escaneo N1QL no transaccional se establece en el SDK a cualquier nivel requerido por la aplicación. (Para más información, consulte la documentación sobre rendimiento y coherencia..)
Sin embargo, con tximplicit
establecido, el DML se ejecuta con consistencia de barrido como solicitud_plus
.
Implicaciones: Con esta configuración, la latencia de la consulta puede aumentar. Esto se debe a que el DML debe asegurarse de que los índices dependientes se actualizan con la misma fecha y hora que la consulta.
Uso de los recursos
El servicio de consulta necesita recursos de memoria para procesar la consulta, especialmente para las operaciones de agregación y ordenación.
Para los DML no transaccionales, todas las mutaciones tienen efecto inmediato. Para los DML transaccionales, todas las mutaciones dentro de una transacción se mantienen localmente en el servicio de consulta hasta el momento de la confirmación. Por esta razón, el uso de recursos de memoria es mucho mayor para el tramo transaccional.
Implicaciones: Las mutaciones de las transacciones N1QL aumentan el uso de memoria.
Directrices sobre cuándo (y cuándo no) utilizar transacciones N1QL
Con la introducción de las transacciones N1QL, es importante tener en cuenta algunas directrices sobre cuándo (y cuándo no) utilizar esta nueva capacidad en su aplicación.
La regla general es utilice las transacciones N1QL sólo cuando sea necesario. El servicio de consultas de Couchbase está diseñado para proporcionar un alto rendimiento y una baja latencia, que se ven afectados por las transacciones. Esto se debe a los requisitos y costes subsiguientes en términos de durabilidad, consistencia de escaneo y uso de recursos.
También debe reducir el tamaño de las transacciones en cuanto al número de documentos y operaciones afectados por las mutaciones. Y, por último, no recomendamos utilizar transacciones N1QL para casos de uso de mutaciones de gran volumen.
Más recursos sobre las transacciones N1QL