SQL es el único lenguaje del siglo XXII disponible actualmente para los desarrolladores.
RESUMEN
En los sistemas de bases de datos relacionales, SQL es más que un lenguaje de consulta declarativo. Incluye el lenguaje procedimental (T-SQL, PL/SQL, etc.) y define las transacciones y su semántica. SQL como lenguaje de consulta ha sido irrazonablemente eficaz incluso en Sistemas de bases de datos NoSQL. Sin embargo, pocos sistemas de bases de datos NoSQL soportan transacciones. Los que las soportan vienen con una larga lista de limitaciones y/o son incapaces de soportar operaciones SQL dentro de la transacción. Introducimos y explicamos las transacciones en Couchbase N1QL: SQL para JSON. Las transacciones N1QL son multi-todo: multi-documento, multi-bucket, multi-alcance, multi-colección, y multi-DML-statement.
N1QL Transactions está disponible con Couchbase 7.0 Beta. Puede descargarlo aquí: https://www.couchbase.com/downloads. Consulte la documentación aquí.
INTRODUCCIÓN
N1QL es un lenguaje declarativo para manipular JSON. Couchbase almacena todos los documentos en el servicio de datos. El servicio de consulta orquesta el ejecución de consultas optimizar la consulta, crear un plan de ejecución y, a continuación, ejecutarla utilizando datos, indexación y FTS. El sitio SDK de Couchbase y el protocolo de interacción de consultas se construye vía REST sobre HTTP/S. Las sentencias DML de N1QL incluyen SELECCIONE, INSERTAR, ACTUALIZACIÓN, UPSERT, BORRARy FUSIONAR.
TRANSACCIONES N1QL
Aquí hay un ejemplo de transacciones en RDBMS y Couchbase N1QL.
Transacciones |
Base de datos MySQL (las declaraciones son iguales/similares en Oracle, SQL Server, Informix y DB2) |
Base de datos Couchbase (Cheshire-Cat) |
Insertar datos. Tuplas en MySQL, documentos JSON en Couchbase |
INSERT INTO cliente(cid, nombre, saldo) VALUES(4872, "Juan Pérez", 724,23);INSERT INTO cliente(cid, nombre, saldo) VALUES(1924, "Bob Stanton", 2735.48); |
INSERT INTO cliente
|
Transacción simple, débito y crédito. Las selecciones intermedias tienen que leer sus propias actualizaciones (RYOW) |
INICIAR TRANSACCIÓN;UPDATE cliente SET saldo = saldo + 100 WHERE cid = 4872;SELECT cid, name, balance from cliente;UPDATE customer SET balance = balance - 100 WHERE cid = 1924;SELECT cid, name, balance from cliente;COMPROMETERSE ; |
INICIAR TRANSACCIÓN;UPDATE cliente SET saldo = saldo + 100 WHERE cid = 4872;SELECT cid, name, balance from cliente;UPDATE customer SET balance = balance - 100 WHERE cid = 1924;SELECT cid, name, balance from cliente;COMPROMETERSE ; |
La segunda transacción con rollback parcial. |
INICIAR TRANSACCIÓN;UPDATE cliente SET saldo = saldo + 100 WHERE cid = 4872;SELECT cid, name, balance from cliente;SAVEPOINT s1;UPDATE customer SET balance = balance - 100 WHERE cid = 1924;SELECT cid, name, balance from cliente;ROLLBACK TRABAJO A PUNTO GUARDADO s1;SELECT cid, name, balance from cliente;COMPROMETERSE ; |
INICIAR TRANSACCIÓN;UPDATE cliente SET saldo = saldo + 100 WHERE cid = 4872;SELECT cid, name, balance from cliente;SAVEPOINT s1;UPDATE customer SET balance = balance - 100 WHERE cid = 1924;SELECT cid, name, balance from cliente;ROLLBACK TRABAJO A PUNTO GUARDADO s1;SELECT cid, name, balance from cliente;COMPROMETERSE ; |
Si no ve mucha diferencia, es porque no la hay.
DECLARACIONES DE TRANSACCIONES N1QL
Transacciones N1QL un conjunto de transacciones que incluyen cualquiera de las sentencias DML en todos los formularios: sin restricciones. La protección transaccional se emite a partir de nuevas declaraciones: INICIO, COMMIT, ROLLBACK, SAVEPOINT.
INICIAR TRANSACCIÓN (igual que INICIAR TRABAJO)
Esta sentencia inicia una nueva transacción, asigna un nuevo ID de transacción, y devuelve el ID de transacción a la persona que llama. Hay dos reglas que los SDKs, herramientas (por ejemplo, CBQ shell) siguen para ejecutar con éxito el resto de la transacción.
- Envíe este ID de transacción como parámetro a cada sentencia subsiguiente dentro de la transacción. Así es como el servicio de consulta sabe que la sentencia debe ejecutarse como parte de una transacción concreta.
- Couchbase puede tener múltiples nodos de servicio de consulta, pero una única transacción se ejecuta en un único nodo de consulta. Puedes iniciar una nueva transacción en CUALQUIER NODO DE CONSULTA. Sin embargo, el resto de las sentencias PARA ESA ÚNICA TRANSACCIÓN deben ser enviadas al MISMO nodo de consulta.
COMPROMETER TRANSACCIÓN o COMPROMETER TRABAJO;
Esto confirma todos los cambios de la transacción en el almacén de datos. Este es un commit distribuido de la transacción en el almacén de datos clave-valor de Couchbase. El commit soporta todos los Durabilidad de Couchbase opciones. Esto sigue siendo un sistema distribuido - al igual que la astronomía, las cosas raras ocurren a menudo. Ante cualquier fallo, la transacción completa se retrocede automáticamente y la aplicación necesita reintentar la transacción. Los fallos pueden ocurrir por varias razones: fallo de red, fallo de nodo, nodo sobrecargado, y conflicto de escritura. Al igual que los WRITEs directos de Couchbase son optimistas y los fallos pueden ocurrir debido a escrituras concurrentes resultando en Conflictos CASLas transacciones N1QL también pueden fallar debido a conflictos de escritura. Implementamos una forma de concurrencia optimista enfoque de las transacciones.
ROLLBACK TRANSACTION o ROLLBACK WORK;
En un rollback emitido por la aplicación, todas las modificaciones realizadas dentro de la transacción son revertidas.
Como has visto en los ejemplos anteriores, N1QL también admite puntos de guardado y retrocesos a los puntos de guardado dentro de la transacción. Desde el punto de vista de la aplicación, funcionan igual que sus homólogos RDBMS.
FUNCIONES TRANSACCIONALES
La transacción es algo más que las declaraciones: se trata de la semántica y las garantías. De ahí el ÁCIDO definición. Hablamos de atomicidad antes wrt a COMMIT. Hablemos un poco más sobre esto.
ATOMICIDAD tanto para toda la transacción como para cada sentencia. Las sentencias DML retrocederán atómicamente ante cualquier fallo, pero la transacción en sí está abierta y puede continuar. Un ejemplo de fallo es un conflicto de clave de documento en la inserción.
CONSISTENCIA asegura que las restricciones se aplican de forma consistente para cada sentencia. La única restricción en Couchbase es la restricción única en la clave de documento. N1QL comprueba la preexistencia de cada una de las claves insertadas y retrocede la sentencia ante cualquier conflicto. Recuerda que usamos control de concurrencia optimista. Esto significa que, aún después de que el INSERT es exitoso, la etapa de commit puede encontrarse con un conflicto de escritura porque alguna otra sesión pudo haber insertado entre el insert y el commit. Tendrás que reintentar la transacción en tales fallos.
AISLAMIENTO
Soportamos el nivel de aislamiento COMMITTED READ. Todos los datos que se leen y evalúan son datos comprometidos en el índice y el almacén de datos. Por defecto, utilizamos el estricto solicitud_plus coherencia en las lecturas del índice. Esto significa que, para un predicado determinado, utilizamos los datos más recientes del índice para calificar los documentos a seleccionar/actualizar/borrar. A continuación, vamos un paso más allá para recuperar los documentos del almacén KV y volver a aplicar los predicados para garantizar que se califica y actualiza la última versión confirmada del documento.
Si el rendimiento no fuera una consideración, todo el mundo habría utilizado transacciones serializables ;-) Puedes cambiar la consistencia del escaneo a sin límites para mejorar el rendimiento de la exploración de índices.
DURABILIDAD
N1QL es compatible con todos los opciones de durabilidad y funciones con el almacén de datos Couchbase para garantizar la durabilidad en nuestra base de datos distribuida.
CONCURRENCIA
A grandes rasgos, las transacciones de bases de datos utilizan métodos pesimistas u optimistas. control de concurrencia. Las bases de datos tradicionales de nodo único siguen el control de concurrencia pesimista para evitar conflictos. Este enfoque también se aplica a algunas de las implementaciones multinodo como Oracle RAC, DB2 Sysplex. Las implementaciones multinodo son posibles, pero requieren un costoso Infiniband, hardware personalizado, etc.
Control de concurrencia optimista versiona cada unidad base de tupla (filas en rdbms, documentos en Couchbase), recuerda la versión que leen para modificar y comprueba si la versión ha cambiado durante la escritura. Si efectivamente hay un conflicto, hay que volver a intentar toda la transacción. La ventaja de este enfoque es que, en una aplicación bien diseñada, debería haber pocos conflictos: no sacarás dinero y transferirás dinero entre cuentas en el mismo nanosegundo. En las raras ocasiones en que sí los haya, se tolera el reintento.
Concurrencia en el servicio de consulta N1QL
Couchbase N1QL usa control de concurrencia optimista. Cada transacción lee los documentos que necesita actualizar, los actualiza y guarda los documentos actualizados en su directorio privado. por transacción caché. Cuando se emite una sentencia posterior, el servicio de consulta es consciente de los documentos actualizados dentro de las transacciones y utiliza esa versión en lugar de la versión anterior reflejada en el índice/datos. Así es como se proporciona el soporte de LECTURA-TU-POSICIÓN-ESCRITURA. Esto se modela para que todas las sentencias DML, todas las operaciones (select, join, project, aggregate, nest, unnesst, etc) obtengan este beneficio RYOW proporcionando una característica consistente y crucial de la transacción. Incluso mientras la aplicación está realizando transacciones (realizando tanto lecturas como escrituras), dentro de la transacción estamos leyendo y almacenando en caché las actualizaciones hasta el momento del commit. Esta es la fase READ de la transacción, y debido a este enfoque, no hay coordinación entre múltiples transacciones o múltiples nodos de consulta dentro de una transacción hasta el commit (fase WRITE). Esto asegura el rendimiento y la escalabilidad de las transacciones distribuidas en Couchbase. Y, antes de que preguntes, todo esto funciona concurrentemente con Transacciones distribuidas Couchbase nosotros lanzado en 6.5.
La coordinación es la perdición de los sistemas escalables - Peter Bailis
PRÓXIMOS PASOS
Acabamos de anunciar que Couchbase 7.0 Beta estará en Noviembre de 2020. Permanezca atento a los detalles.
Este es un breve resumen de lo que viene con Couchbase Transactions. En la próxima serie de artículos, profundizaremos en la implementación, uso, soporte SDK, Lambda Transactions, soporte Spring, etc, y más.
AGRADECIMIENTOS
Estoy feliz de anunciar las transacciones N1QL aquí. Este es el resultado de un intenso trabajo y colaboración en Couchbase query, SDK, y los equipos de QE para diseñar e implementar. Gracias.
