{"id":9439,"date":"2020-10-14T12:45:47","date_gmt":"2020-10-14T19:45:47","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=9439"},"modified":"2025-06-13T18:44:03","modified_gmt":"2025-06-14T01:44:03","slug":"transactions-n1ql-couchbase-distributed-nosql","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/transactions-n1ql-couchbase-distributed-nosql\/","title":{"rendered":"Transacciones N1QL : El\u00e1sticas, Escalables y Distribuidas"},"content":{"rendered":"

SQL es el \u00fanico lenguaje del siglo XXII disponible actualmente para los desarrolladores.<\/span><\/p><\/blockquote>\n

RESUMEN<\/strong><\/p>\n

En los sistemas de bases de datos relacionales, SQL es m\u00e1s que un lenguaje de consulta declarativo. Incluye el lenguaje procedimental (T-SQL, PL\/SQL, etc.) y define las transacciones y su sem\u00e1ntica. SQL como lenguaje de consulta ha sido <\/span>irrazonablemente eficaz incluso en <\/span>Sistemas de bases de datos NoSQL<\/span><\/a>. 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\u00f3n. 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\u00f3n, y multi-DML-statement.<\/span><\/p>\n

N1QL Transactions est\u00e1 disponible con Couchbase 7.0 Beta. Puede descargarlo aqu\u00ed: https:\/\/www.couchbase.com\/downloads<\/a>. Consulte la documentaci\u00f3n aqu\u00ed<\/a>.<\/p>\n

INTRODUCCI\u00d3N<\/strong><\/p>\n

\"\"<\/a>N1QL<\/span><\/a> es<\/span>\u00a0un lenguaje declarativo para manipular JSON. Couchbase almacena todos los documentos en el servicio de datos. El servicio de consulta orquesta el <\/span>ejecuci\u00f3n de consultas<\/span><\/a> optimizar la consulta, crear un plan de ejecuci\u00f3n y, a continuaci\u00f3n, ejecutarla utilizando datos, indexaci\u00f3n y FTS. El sitio SDK de Couchbase<\/a> y el protocolo de interacci\u00f3n de consultas se construye v\u00eda REST sobre HTTP\/S. Las sentencias DML de N1QL incluyen SELECCIONE<\/a>, INSERTAR<\/a>, ACTUALIZACI\u00d3N<\/a>, UPSERT<\/a>, BORRAR<\/a>y FUSIONAR<\/a>.\u00a0\u00a0<\/span><\/p>\n

TRANSACCIONES N1QL<\/strong><\/p>\n

Aqu\u00ed hay un ejemplo de transacciones en RDBMS y Couchbase N1QL.<\/p>\n

\n\n\n\n\n\n\n
\n
Transacciones<\/strong><\/span><\/h6>\n<\/td>\n
\n
Base de datos MySQL (las declaraciones son iguales\/similares en Oracle, SQL Server, Informix y DB2)<\/span><\/h6>\n<\/td>\n
\n
Base de datos Couchbase (Cheshire-Cat)<\/strong><\/span><\/h6>\n<\/td>\n<\/tr>\n
\n
Insertar datos. Tuplas en MySQL, documentos JSON en Couchbase<\/h6>\n<\/td>\n
\n
INSERT INTO cliente(cid, nombre, saldo) VALUES(4872, \"Juan P\u00e9rez\", 724,23);<\/h6>\n
INSERT INTO cliente(cid, nombre, saldo) VALUES(1924, \"Bob Stanton\", 2735.48);<\/h6>\n<\/td>\n
\n
INSERT INTO cliente
\nVALUES(\"cx4872\", {\"cid\": 4872, \"name\": \"John Doe\", \"balance\":724.23});<\/h6>\n
INSERT INTO cliente
\nVALUES(\"cx1924\", {\"cid\": 1924, \"name\": \"Bob Stanton\", \"balance\":2735.48});<\/h6>\n<\/td>\n<\/tr>\n
\n
Transacci\u00f3n simple, d\u00e9bito y cr\u00e9dito. Las selecciones intermedias tienen que leer sus propias actualizaciones (RYOW)<\/h6>\n<\/td>\n
\n
INICIAR TRANSACCI\u00d3N;<\/strong><\/h6>\n
UPDATE cliente SET saldo = saldo + 100 WHERE cid = 4872;<\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
UPDATE customer SET balance = balance - 100 WHERE cid = 1924;<\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
COMPROMETERSE ;<\/strong><\/h6>\n<\/td>\n
\n
INICIAR TRANSACCI\u00d3N;<\/strong><\/h6>\n
UPDATE cliente SET saldo = saldo + 100 WHERE cid = 4872;<\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
UPDATE customer SET balance = balance - 100 WHERE cid = 1924;<\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
COMPROMETERSE ;<\/strong><\/h6>\n<\/td>\n<\/tr>\n
\n
La segunda transacci\u00f3n con rollback parcial.<\/h6>\n<\/td>\n
\n
INICIAR TRANSACCI\u00d3N;<\/strong><\/h6>\n
UPDATE cliente SET saldo = saldo + 100 WHERE cid = 4872;<\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
SAVEPOINT s1;<\/strong><\/h6>\n
UPDATE customer SET balance = balance - 100 WHERE cid = 1924;<\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
ROLLBACK TRABAJO A PUNTO GUARDADO s1;<\/strong><\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
COMPROMETERSE ;<\/strong><\/h6>\n<\/td>\n
\n
INICIAR TRANSACCI\u00d3N;<\/strong><\/h6>\n
UPDATE cliente SET saldo = saldo + 100 WHERE cid = 4872;<\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
SAVEPOINT s1;<\/strong><\/h6>\n
UPDATE customer SET balance = balance - 100 WHERE cid = 1924;<\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
ROLLBACK TRABAJO A PUNTO GUARDADO s1;<\/strong><\/h6>\n
SELECT cid, name, balance from cliente;<\/h6>\n
COMPROMETERSE ;<\/strong><\/h6>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Si no ve mucha diferencia, es porque no la hay.\u00a0<\/span><\/p><\/blockquote>\n

DECLARACIONES DE TRANSACCIONES N1QL<\/strong><\/p>\n

Transacciones N1QL un conjunto de transacciones que incluyen cualquiera de las sentencias DML en todos los formularios: sin restricciones<\/span>. La protecci\u00f3n transaccional se emite a partir de nuevas declaraciones: INICIO, COMMIT, ROLLBACK, SAVEPOINT<\/span>.<\/p>\n

INICIAR TRANSACCI\u00d3N (igual que INICIAR TRABAJO)<\/strong><\/h6>\n

Esta sentencia inicia una nueva transacci\u00f3n, asigna un nuevo ID de transacci\u00f3n, y devuelve el ID de transacci\u00f3n a la persona que llama. Hay dos reglas que los SDKs, herramientas (por ejemplo, CBQ shell) siguen para ejecutar con \u00e9xito el resto de la transacci\u00f3n.<\/p>\n

    \n
  1. Env\u00ede este ID de transacci\u00f3n como par\u00e1metro a cada sentencia subsiguiente dentro de la transacci\u00f3n. As\u00ed es como el servicio de consulta sabe que la sentencia debe ejecutarse como parte de una transacci\u00f3n concreta.<\/li>\n
  2. Couchbase puede tener m\u00faltiples nodos de servicio de consulta, pero una \u00fanica transacci\u00f3n se ejecuta en un \u00fanico nodo de consulta. Puedes iniciar una nueva transacci\u00f3n en CUALQUIER NODO DE CONSULTA. Sin embargo, el resto de las sentencias PARA ESA \u00daNICA TRANSACCI\u00d3N deben ser enviadas al MISMO nodo de consulta.<\/li>\n<\/ol>\n
    COMPROMETER TRANSACCI\u00d3N o COMPROMETER TRABAJO;<\/strong><\/h6>\n

    Esto confirma todos los cambios de la transacci\u00f3n en el almac\u00e9n de datos. Este es un commit distribuido de la transacci\u00f3n en el almac\u00e9n de datos clave-valor de Couchbase. El commit soporta todos los Durabilidad de Couchbase<\/a> opciones. Esto sigue siendo un sistema distribuido - al igual que la astronom\u00eda, las cosas raras ocurren a menudo. Ante cualquier fallo, la transacci\u00f3n completa se retrocede autom\u00e1ticamente y la aplicaci\u00f3n necesita reintentar la transacci\u00f3n. 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 CAS<\/a>Las transacciones N1QL tambi\u00e9n pueden fallar debido a conflictos de escritura. Implementamos una forma de concurrencia optimista<\/a> enfoque de las transacciones.<\/p>\n

    ROLLBACK TRANSACTION o ROLLBACK WORK;<\/strong><\/h6>\n

    En un rollback emitido por la aplicaci\u00f3n, todas las modificaciones realizadas dentro de la transacci\u00f3n son revertidas.<\/p>\n

    Como has visto en los ejemplos anteriores, N1QL tambi\u00e9n admite puntos de guardado<\/strong> y retrocesos a los puntos de guardado dentro de la transacci\u00f3n. Desde el punto de vista de la aplicaci\u00f3n, funcionan igual que sus hom\u00f3logos RDBMS.<\/p>\n

    FUNCIONES TRANSACCIONALES<\/strong><\/p>\n

    La transacci\u00f3n es algo m\u00e1s que las declaraciones: se trata de la sem\u00e1ntica y las garant\u00edas. De ah\u00ed el \u00c1CIDO<\/a> definici\u00f3n. Hablamos de atomicidad antes wrt a COMMIT. Hablemos un poco m\u00e1s sobre esto.<\/p>\n

    ATOMICIDAD\u00a0<\/strong>tanto para toda la transacci\u00f3n como para cada sentencia. Las sentencias DML retroceder\u00e1n at\u00f3micamente ante cualquier fallo, pero la transacci\u00f3n en s\u00ed est\u00e1 abierta y puede continuar. Un ejemplo de fallo es un conflicto de clave de documento en la inserci\u00f3n.<\/p>\n

    CONSISTENCIA<\/strong> asegura que las restricciones se aplican de forma consistente para cada sentencia. La \u00fanica restricci\u00f3n en Couchbase es la restricci\u00f3n \u00fanica 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\u00fan despu\u00e9s de que el INSERT es exitoso, la etapa de commit puede encontrarse con un conflicto de escritura porque alguna otra sesi\u00f3n pudo haber insertado entre el insert y el commit. Tendr\u00e1s que reintentar la transacci\u00f3n en tales fallos.<\/p>\n

    AISLAMIENTO<\/strong><\/p>\n

    Soportamos el nivel de aislamiento COMMITTED READ. Todos los datos que se leen y eval\u00faan son datos comprometidos en el \u00edndice y el almac\u00e9n de datos. Por defecto, utilizamos el estricto solicitud_plus<\/a> coherencia en las lecturas del \u00edndice. Esto significa que, para un predicado determinado, utilizamos los datos m\u00e1s recientes del \u00edndice para calificar los documentos a seleccionar\/actualizar\/borrar. A continuaci\u00f3n, vamos un paso m\u00e1s all\u00e1 para recuperar los documentos del almac\u00e9n KV y volver a aplicar los predicados para garantizar que se califica y actualiza la \u00faltima versi\u00f3n confirmada del documento.<\/p>\n

    Si el rendimiento no fuera una consideraci\u00f3n, todo el mundo habr\u00eda utilizado transacciones serializables ;-) Puedes cambiar la consistencia del escaneo a sin l\u00edmites<\/a> para mejorar el rendimiento de la exploraci\u00f3n de \u00edndices.<\/p>\n

    DURABILIDAD<\/strong><\/p>\n

    N1QL es compatible con todos los opciones de durabilidad<\/a> y funciones con el almac\u00e9n de datos Couchbase para garantizar la durabilidad en nuestra base de datos distribuida.<\/p>\n

    CONCURRENCIA<\/strong>\"\"<\/a>A grandes rasgos, las transacciones de bases de datos utilizan m\u00e9todos pesimistas u optimistas. control de concurrencia<\/a>. Las bases de datos tradicionales de nodo \u00fanico siguen el control de concurrencia pesimista para evitar conflictos. Este enfoque tambi\u00e9n 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.<\/p>\n

    Control de concurrencia optimista versiona cada unidad base de tupla (filas en rdbms, documentos en Couchbase), recuerda la versi\u00f3n que leen para modificar y comprueba si la versi\u00f3n ha cambiado durante la escritura. Si efectivamente hay un conflicto, hay que volver a intentar toda la transacci\u00f3n. La ventaja de este enfoque es que, en una aplicaci\u00f3n bien dise\u00f1ada, deber\u00eda haber pocos conflictos: no sacar\u00e1s dinero y transferir\u00e1s dinero entre cuentas en el mismo nanosegundo. En las raras ocasiones en que s\u00ed los haya, se tolera el reintento.<\/p>\n

    Concurrencia en el servicio de consulta N1QL<\/strong><\/h6>\n

    Couchbase N1QL usa control de concurrencia optimista. Cada transacci\u00f3n lee los documentos que necesita actualizar, los actualiza y guarda los documentos actualizados en su directorio privado. por transacci\u00f3n<\/strong> cach\u00e9. Cuando se emite una sentencia posterior, el servicio de consulta es consciente de los documentos actualizados dentro de las transacciones y utiliza esa versi\u00f3n en lugar de la versi\u00f3n anterior reflejada en el \u00edndice\/datos. As\u00ed es como se proporciona el soporte de LECTURA-TU-POSICI\u00d3N-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\u00edstica consistente y crucial de la transacci\u00f3n. Incluso mientras la aplicaci\u00f3n est\u00e1 realizando transacciones (realizando tanto lecturas como escrituras), dentro de la transacci\u00f3n estamos leyendo y almacenando en cach\u00e9 las actualizaciones hasta el momento del commit. Esta es la fase READ de la transacci\u00f3n, y debido a este enfoque, no hay coordinaci\u00f3n entre m\u00faltiples transacciones o m\u00faltiples nodos de consulta dentro de una transacci\u00f3n 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<\/a> nosotros lanzado en 6.5<\/a>.<\/p>\n

    La coordinaci\u00f3n es la perdici\u00f3n de los sistemas escalables - Peter Bailis<\/a><\/span><\/p><\/blockquote>\n