Casos de uso y mejores prácticas para transacciones distribuidas a través de N1QL

¿Couchbase admite transacciones?

¡Sí! Con 6.5, introdujimos el Transacción ACID en Couchbase a través de los SDK. El 1st La pregunta que nos hicieron en su momento los clientes que se enteraron fue:

¿Está disponible el soporte de transacciones a través de N1QL?

¡Sí! Con 7.0, ¡hemos empezado a soportar transacciones a través de N1QL también!Las transacciones N1QL son multi-todo. Multi-documentos que pueden abarcar múltiples colecciones de múltiples ámbitos dentro de múltiples buckets. Puede tener múltiples transacciones ejecutándose en un único nodo de consulta y puede tener múltiples nodos de consulta. NO hay coordinador central, eliminando así un único punto de fallo o contención y dando paso a una escalabilidad infinita.

¿Qué es N1QL? y ¿Por qué es tan importante para Couchbase?

Al igual que SQL es para RDBMS, ¡N1QL es para Couchbase!

N1QL es un lenguaje declarativo casi idéntico a SQL y se utiliza para insertar/recuperar y manipular los datos almacenados en forma de documentos JSON.Más información sobre N1QL aquí .

Si N1QL es como SQL, ¿por qué no tenía antes ACID?

N1QL siempre tuvo ACID dentro de un solo documento. Lo que no teníamos antes de la versión 7.0 era soporte para transacciones multi-documento a través de N1QL.

Bien, pensemos primero por qué mucha gente cree que necesita transacciones multidocumento. El primer principio del modelado relacional de datos es la normalización de los datos en todas las tablas. Esto significa que muchas operaciones comunes de bases de datos, como la creación de cuentas, requieren actualizaciones atómicas a través de muchas filas y columnas.

En Couchbase, el modelo de datos es fundamentalmente diferente. El modelo de documento anima a los usuarios a almacenar datos relacionados juntos en un único documento. N1QL siempre ha soportado transacciones ACID en un solo documento y, cuando se aprovecha el modelo de documento apropiadamente, muchas aplicaciones no necesitan garantías ACID a través de múltiples documentos. Como se muestra a continuación, los datos que necesitan ser almacenados en 3 tablas diferentes vinculadas por PK-FK, se almacenan en un único documento en Couchbase.  

Por ejemplo, añadir un artículo a la cesta de la compra no necesita transacciones en Couchbase, ya que sólo se actualiza un único documento.

Sin embargo, las transacciones no son sólo una casilla de verificación. Las transacciones, como todas las características de Couchbase, pretenden facilitar la vida de los desarrolladores. Las garantías ACID entre documentos simplifican la lógica de aplicación necesaria para satisfacer aplicaciones complejas.

¿Cuáles son los casos de uso de las transacciones multidocumento?:

Existen casos de uso en los que es necesario aplicar garantías ACID transaccionales a un conjunto de operaciones que abarcan múltiples documentos. Las aplicaciones de "sistema de registro" son la clase típica de carga de trabajo en la que resultan útiles las transacciones multidocumento. Algunos ejemplos son:

• Procesamiento de eventos de aplicación cuando los usuarios realizan acciones que si se repiten pueden causar diferentes resultados, por lo que tienen que tener todos éxito o todos fracaso. Por ejemplo, el típico cargo o abono bancario.
• Registro de acciones personalizadas de la aplicación -que no se pueden revertir ni siquiera en caso de fallo del sistema-, por ejemplo, cuando un usuario transfiere la propiedad de un coche o una casa, la escritura no debe tener éxito si el registro no lo es.
• Relaciones de muchos a muchos donde los datos encajan de forma natural en objetos definidos - por ejemplo, Clientes, pedidos de clientes, productos y fabricantes. Para calcular el total de un pedido de cliente, es necesario recopilar los valores de cada tabla y sumarlos para cada cliente.

Detalles sobre transacciones a través de N1QL en Couchbase:

Vamos a sumergirnos en las transacciones N1QL con una simple transacción, débito y crédito. Los selectos tienen que leer sus propias actualizaciones (RYOW)

INICIAR TRANSACCIÓN;

UPDATE cliente SET saldo = saldo - 100 WHERE cid = 4872;

UPDATE cliente SET saldo = saldo + 100 WHERE cid = 1924;

SELECT cid, name, balance from cliente where cid in [4872,1924];

COMPROMETERSE ;

Esta es la misma sintaxis que escribirías en MySQL. Esa es la belleza de N1QL.

No tienes que aprender un nuevo lenguaje para usar Couchbase si ya estás familiarizado con SQL.

En el ejemplo anterior,

Si ya está familiarizado con la arquitectura de Couchbase, entonces

• START TRANSACTION irá a un nodo de consulta. El nodo de consulta asignará un id de transacción único (txid) a esta transacción.

• A continuación viene la sentencia de actualización. El nodo de consulta mirará la cláusula where, seleccionará el índice apropiado que servirá a la consulta, encontrará el id del documento, enviará el id del documento al almacén de datos (KV) y recuperará el documento en el nodo de consulta y luego actualizará el saldo. Si esto no estuviera dentro de una transacción, se enviaría de vuelta al almacén de datos inmediatamente. Pero como está dentro de la transacción, este documento se almacenará en la caché del nodo de consulta. Esta caché se denomina tabla delta. Tenemos 1 tabla delta por transacción y por colección. Por eso necesitamos que todas las sentencias de una transacción lleguen al mismo nodo de consulta. Esta unión se hace con el txid proporcionado por START TRANSACTION.
• Con la siguiente actualización, lo mismo, el nodo Query mirará la cláusula where, seleccionará el índice apropiado que servirá a la consulta, encontrará el id del documento, pero ahora en lugar de ir directamente a KV para obtener el documento, ya que hay una tabla delta, primero mirará en la tabla delta si este documento ya existe en la tabla delta. En este caso, no existe, así que va a buscarlo a KV, actualiza el saldo y lo almacena en la tabla delta.
• A continuación viene la sentencia select al nodo query. Nuevamente el nodo de consulta mirará la cláusula where, seleccionará el índice apropiado que servirá a la consulta, encontrará el id del documento. Ahora buscará los ids de los documentos en la tabla delta, los encontrará allí y enviará los campos proyectados de vuelta al cliente.

• Hasta ahora hemos leído del almacén de datos pero nunca hemos escrito en él. Sólo hemos escrito en la caché del nodo de consulta. Y por lo tanto decimos que seguimos la concurrencia optimista. Múltiples transacciones podrían estar operando en estos mismos documentos al mismo tiempo.
• Ahora cuando la siguiente sentencia llegue al nodo Query "COMMIT", es cuando los documentos actualizados irán al nodo KV y utilizaremos el protocolo commit resaltado. aquí para confirmar los cambios. 
• En este punto, si hubiera varias transacciones actualizando los mismos documentos, una tendría éxito y las demás retrocederían y tendrían que volver a intentarlo.

Mejores prácticas para transacciones N1QL :

¿Cuándo se deben utilizar las transacciones N1QL?

1. Un ejemplo típico es el de un crédito de débito o una reserva aérea con varios tramos.
2. Si quieres asegurarte de que los cambios realizados no se revierten incluso en caso de caída del sistema, como la transferencia de la titularidad de una casa/coche.
3. Cuando la lógica requerida abarca datos que no pueden fusionarse en un único documento y requiere actualizaciones de varios documentos.
4. Normalmente, cargas de trabajo de muy corta duración que implican pequeños conjuntos de resultados, sin agregados importantes.
5. Cuando pueda necesitar modificar/leer los mismos documentos una y otra vez (con el apoyo de Read your own writes mediante el uso de tablas delta).

¿Qué debe evitar hacer al utilizar transacciones N1QL?

Incluso en un ejemplo tan sencillo como el anterior, probablemente pueda verlo:

1. La tabla Delta (que es por transacción/por colección) crecerá con cada mutación. Si tiene una transacción con muchas mutaciones, el uso de memoria aumentará. Así que la recomendación es limitar el número de mutaciones dentro de una transacción. Para cargas de tipo ETL, o actualizaciones masivas que necesiten garantías ACID hemos proporcionado otra opción de transacciones implícitas. Puedes leer sobre ellas aquíEl ajuste "memory-quota" en el servicio de consulta puede controlar la cantidad de memoria consumida por las tablas delta.
2. Utilice las transacciones sólo en documentos de menos de 10 MB de tamaño.
3. No incluya Operaciones DDL dentro de transacciones N1QL. Cualquier operación DDL dará lugar a un error.
4. Por defecto, el tiempo de espera es de 15s. Puede modificarse en función del medio que utilice para utilizar las transacciones N1QL (shell cbq, UI, Java SDK o REST API).
5. El servicio de consulta fue diseñado para proporcionar un alto rendimiento y baja latencia, los cuales pueden verse afectados por las transacciones. Utilice transacciones N1QL cuando sus casos de uso requieran transacciones.
6. Dado que utilizamos concurrencia optimista, tenemos que estar seguros de que la mayor parte de nuestra carga de trabajo es tal que múltiples transacciones no están modificando los mismos documentos al mismo tiempo. Porque en ese caso, una tendrá éxito y las otras retrocederán con errores "CAS mismatch" o "Write write conflict".
7. No deberíamos modificar los mismos documentos utilizando transacciones y no transacciones al mismo tiempo.

Entender cómo funcionan las transacciones utilizando el Simulador de transacciones

Más información sobre la ayuda a las transacciones a través de N1QL

https://www.couchbase.com/blog/transactions-n1ql-couchbase-distributed-nosql/

https://www.couchbase.com/blog/couchbase-transactions-with-n1ql/

https://docs.couchbase.com/java-sdk/current/howtos/distributed-acid-transactions-from-the-sdk.html#n1ql-queries