{"id":10953,"date":"2021-03-23T01:24:55","date_gmt":"2021-03-23T08:24:55","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=10953"},"modified":"2024-01-26T19:17:43","modified_gmt":"2024-01-27T03:17:43","slug":"distributed-multi-document-acid-transactions","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/es\/distributed-multi-document-acid-transactions\/","title":{"rendered":"C\u00f3mo implementamos las transacciones ACID multidocumento distribuidas en Couchbase"},"content":{"rendered":"

Transacciones ACID<\/a> son imprescindibles cuando se tienen requisitos estrictos de coherencia de datos en la aplicaci\u00f3n. Los costes de ejecutar transacciones en sistemas distribuidos pueden crear r\u00e1pidamente cuellos de botella a escala. En este art\u00edculo, te daremos una visi\u00f3n general de algunos de los retos a los que se enfrentan las bases de datos NoSQL y NewSQL. Luego, profundizaremos en c\u00f3mo Couchbase implement\u00f3 un modelo de transacciones distribuidas escalable sin coordinaci\u00f3n central y sin punto \u00fanico de fallo. Adem\u00e1s, tambi\u00e9n dar\u00e9 una breve visi\u00f3n general de c\u00f3mo se ve el soporte para transacciones en N1QL en Couchbase 7.0.<\/span><\/p>\n

Se han omitido algunos detalles menores en aras de la simplicidad.<\/span><\/p>\n

 <\/p>\n

Transacciones relacionales vs NewSQL vs NoSQL<\/span><\/h2>\n

Antes de empezar a explicar c\u00f3mo Couchbase implement\u00f3 el soporte para transacciones, necesito explicar primero las caracter\u00edsticas inherentes de la atomicidad en bases de datos relacionales y NoSQL (usando modelos de datos semi-estructurados como JSON):<\/span><\/p>\n

 <\/p>\n

Atomicidad en RDBMS<\/span><\/h3>\n

Supongamos que necesita guardar un nuevo usuario en la base de datos. Naturalmente, como tiene muchas otras tablas asociadas, insertar un usuario tambi\u00e9n requerir\u00e1 inserciones en muchas otras tablas:<\/span><\/p>\n

\"Transactions<\/p>\n

Dado que el modelo relacional te obliga a almacenar todo en \"cajas\" y a dividir tus datos en peque\u00f1os trozos, a\u00f1adir un nuevo usuario siempre debe ejecutarse dentro de un contexto transaccional. De lo contrario, si una de tus inserciones falla, tu usuario acabar\u00e1 a medias. Observe c\u00f3mo un RDBMS depende en gran medida de las transacciones, ya que las aplicaciones son mucho m\u00e1s complejas que cuando se dise\u00f1\u00f3 originalmente el modelo relacional all\u00e1 por los a\u00f1os setenta.<\/span><\/p>\n

Por suerte, como estas bases de datos est\u00e1n dise\u00f1adas para ejecutarse en un \u00fanico nodo, puede utilizar un coordinador de transacciones central para consignar los datos de una vez sin que ello afecte al rendimiento. <\/span><\/p>\n

 <\/p>\n

Atomicidad en NewSQL<\/span><\/h3>\n

En el lado NewSQL (relacional distribuida), las cosas son un poco m\u00e1s complicadas. Como la mayor\u00eda de estas bases de datos reutilizan el modelo relacional, los datos de tu entidad (o <\/span>ra\u00edz agregada<\/span><\/a>) tiende a repartirse entre varios nodos.<\/span><\/p>\n

\"atomicity<\/p>\n

En la imagen de arriba, si necesitamos cargar el usuario en memoria, primero tendr\u00edamos que obtener el usuario del Servidor 1, luego cargar la asociaci\u00f3n entre usuarios y roles en el Servidor 2 y finalmente cargar el rol de destino desde el Servidor 3. Esta simple operaci\u00f3n requiere que los datos viajen al menos dos veces por la red, lo que en \u00faltima instancia limitar\u00e1 su rendimiento de lectura. En un escenario real, un usuario tiene muchas m\u00e1s tablas asociadas a \u00e9l. Esta es la raz\u00f3n por la que la relacional distribuida todav\u00eda no es pr\u00e1ctica cuando se necesita leer\/escribir lo m\u00e1s r\u00e1pido posible.<\/span><\/p>\n

Puedes intentar minimizar los problemas anteriores limitando el tama\u00f1o de tu cl\u00faster, confiando mucho en los \u00edndices para rastrear todas las relaciones, o mediante algunas t\u00e9cnicas de fragmentaci\u00f3n para mantener todos los datos relacionados en el mismo nodo (lo cual es dif\u00edcil de implementar en la pr\u00e1ctica). Los dos \u00faltimos enfoques, aunque est\u00e9n bien implementados, consumir\u00e1n importantes recursos de la base de datos para ser gestionados adecuadamente.<\/span><\/p>\n

Las transacciones ACID en bases de datos NewSQL requieren m\u00e1s coordinaci\u00f3n que en NoSQL, ya que los datos relacionados con una entidad se dividen en m\u00faltiples tablas que pueden vivir en diferentes nodos. El modelo relacional, tal y como lo utilizamos hoy en d\u00eda, requiere transacciones para la mayor\u00eda de las escrituras, actualizaciones y eliminaciones en cascada. La coordinaci\u00f3n adicional que requiere la arquitectura NewSQL tiene el coste de reducir el rendimiento de las aplicaciones que requieren operaciones de baja latencia.<\/span><\/p>\n

 <\/p>\n

Atomicidad en las bases de datos de documentos<\/span><\/h3>\n

El uso de datos semiestructurados como JSON puede reducir dr\u00e1sticamente el n\u00famero de \"uniones entre nodos\" y, por tanto, mejorar el rendimiento de lectura y escritura sin necesidad de recurrir en exceso a la indexaci\u00f3n. Esta fue una de las principales conclusiones del estudio <\/span>Papel Dynamo<\/span><\/a> (publicado por primera vez hace ~13 a\u00f1os) que fue el<\/span> catalizador para crear las bases de datos NoSQL tal y como las conocemos hoy.<\/span><\/p>\n

Otra caracter\u00edstica interesante de un modelo de datos semiestructurado es que es menos transaccional, ya que podr\u00edan caber todos los datos del usuario en un solo documento:<\/span><\/p>\n

\"atomicity<\/p>\n

Como se puede ver en la imagen superior, las preferencias y roles de los usuarios caben f\u00e1cilmente dentro de un \"Documento de Usuario\", por lo que no es necesaria una transacci\u00f3n para insertar o actualizar un usuario ya que la operaci\u00f3n es at\u00f3mica. O insertamos el documento o falla toda la operaci\u00f3n. Lo mismo es v\u00e1lido para muchos otros casos de uso comunes: carros de la compra, productos, estructuras de \u00e1rbol, y <\/span>ra\u00edces agregadas <\/span><\/a>en general.<\/span><\/p>\n

En la mayor\u00eda de las aplicaciones que utilizan bases de datos de documentos, 90% de las operaciones transaccionales corresponder\u00e1n a esta categor\u00eda de documento \u00fanico. Pero... \u00bfqu\u00e9 pasa con los otros 10%? Bueno, para esas necesitaremos soporte transaccional multi-documento, que ha sido a\u00f1adido en Couchbase desde la versi\u00f3n 6.5 y es el foco principal de este art\u00edculo.<\/span><\/p>\n

Aqu\u00ed tienes una presentaci\u00f3n sobre transacciones que se realiz\u00f3 en Couchbase Connect 2020. Matt Ingenthron te da una explicaci\u00f3n de cu\u00e1ndo y por qu\u00e9 podr\u00edas necesitar transacciones ACID multi-documento:<\/span><\/p>\n

Vea la versi\u00f3n completa en <\/span>https:\/\/www.youtube.com\/watch?v=2fsZVe2cT3M&ab_channel=Couchbase<\/span><\/a><\/h6>\n

 <\/p>\n

Transcripci\u00f3n del v\u00eddeo<\/span><\/h3>\n
\nHaga clic para leer la transcripci\u00f3n completa.<\/summary>\n

Vamos a hablar de c\u00f3mo se aplica esto a un ejemplo ficticio, pero tal vez algo realista, de un modelo de documento para un sistema Couchbase. As\u00ed que hemos recaudado algo de dinero, y vamos a construir un juego de rol multijugador masivo en l\u00ednea (un MMORPG), con jugadores y monstruos. As\u00ed que necesitamos un modelo de datos.\u00a0<\/span><\/p>\n

Vamos a tener jugadores que luchan contra monstruos y, a continuaci\u00f3n, sobre la base de esa lucha, ganar o perder, van a. Si ganan, van a conseguir un arma, si pierden, eh, pierden algunos puntos de golpe para que nadie pueda morir. Siempre se puede volver a la vida, siempre se puede encontrar otro d\u00eda. Pero sus jugadores luchar contra monstruos, y tenemos nuestra versi\u00f3n 1.0 construido. \u00a1Genial! Bien, conseguimos nuestra financiaci\u00f3n, conseguimos nuestra 1.0 construida.<\/span><\/p>\n

El problema es que nos olvidamos de la parte multijugador masivo. No hay juego colaborativo. No puedo tener m\u00faltiples jugadores luchando contra el mismo monstruo. As\u00ed que tengo que arreglar eso, \u00bfverdad? As\u00ed que vamos a lanzar una nueva versi\u00f3n. As\u00ed que los jugadores van a seguir luchando contra monstruos y ganando armas.<\/span><\/p>\n

As\u00ed que lanzamos nuestra versi\u00f3n 2.0, y en la versi\u00f3n 2.0 los jugadores pueden luchar juntos contra los monstruos. Puedo coordinar con mis amigos, podr\u00edamos ir a buscar un monstruo, y podemos matar a ese monstruo.\u00a0<\/span><\/p>\n

Pero dejamos un error ah\u00ed. Es posible que varios jugadores asesten el golpe mortal y la raz\u00f3n de que eso sea un problema es que los jugadores del juego se dan cuenta. En lugar de luchar contra un monstruo juntos hasta la muerte, lo que hacen es, ellos, en este mundo multijugador masivo, luchar hasta casi la muerte, y luego un grupo de jugadores se reunir\u00e1n, y todos ellos asestar\u00e1n el golpe mortal o muchos asestar\u00e1n el golpe mortal al mismo tiempo.\u00a0<\/span><\/p>\n

El problema es que ganan objetos, ganan m\u00faltiples objetos, y como los objetos tienen rareza, y si no tienes una cierta cantidad de rareza para un objeto, el juego no es muy interesante. Este error ha permitido que existan demasiados objetos en el mundo, y los jugadores se pasan el tiempo pirateando el juego, y luego se aburren y lo abandonan. Tenemos que mantener la jugabilidad interesante.<\/span><\/p>\n

As\u00ed que pensemos en esto. \u00bfC\u00f3mo podemos arreglarlo? Creo que lo que tendremos que hacer es probablemente introducir un arreglo. Seguiremos permitiendo que jugadores y monstruos, varios jugadores luchen contra un monstruo. Pero lo que vamos a hacer es tomar uno de esos trucos que tenemos, vamos a tomar <\/span>Couchbase CAS <\/span><\/a>Operaciones.<\/span><\/p>\n

Con el <\/span>Operaci\u00f3n CAS<\/span><\/a> lo que ocurre es que ahora varios jugadores est\u00e1n luchando contra ese monstruo, reduciendo sus puntos de vida hasta que llega a cero. Pero s\u00f3lo uno de esos jugadores ser\u00e1 capaz de asestar el golpe mortal a ese monstruo y ganar un objeto.<\/span><\/p>\n

As\u00ed que la forma en que esto funciona es si dos jugadores est\u00e1n tratando de dar ese golpe mortal, la aplicaci\u00f3n <\/span>servidor que est\u00e1 manejando la solicitud va a tratar de modificar el documento. Tiene que recoger una peque\u00f1a pieza de informaci\u00f3n opaca que llamamos el<\/span> CAS (siglas de Check And Set)<\/span><\/a>y eso significa que si ese opaque no coincide, entonces los documentos ya han sido modificados, por lo que hay que reintentar esa operaci\u00f3n. En el escenario de que dos actores dentro del sistema est\u00e1n tratando de agarrar ese documento al mismo tiempo, lo que queremos es que uno tenga \u00e9xito y otro falle, y el CAS nos dar\u00e1 eso de una manera muy eficiente.<\/span><\/p>\n

Sacamos ese truco, introducimos operaciones CAS, se arregla el fallo, la jugabilidad es ahora mucho m\u00e1s interesante y la 2.1 lo hace realmente bien, as\u00ed que estupendo.<\/span><\/p>\n

As\u00ed que ahora vamos a intentar un , eh, queremos seguir adelante, queremos hacer las cosas m\u00e1s interesantes. Imagina ahora que introduzco otra caracter\u00edstica: \"Los jugadores pueden seguir luchando juntos contra los monstruos, pero tienen que hacerlo fuera de la ciudad. As\u00ed que tienen que estar fuera de la muralla de la ciudad donde est\u00e1n los jugadores, y si entran en la ciudad, har\u00e1n comercio en un bizarro\"<\/span><\/p>\n

Esto funciona muy bien al principio, pero luego los jugadores se dan cuenta de algo.<\/span><\/p>\n

As\u00ed que imagina jugador1, tengo que recuperar el documento para jugador1. Luego tengo que recuperar el documento para el jugador2. Luego tengo que mover la espada del jugador1 al jugador2, eso es muy f\u00e1cil de hacer en la l\u00f3gica de la aplicaci\u00f3n, y luego voy a almacenar ese cambio de nuevo al sistema con la operaci\u00f3n CAS, y luego voy a almacenar el otro cambio de nuevo, \u00bfverdad? Suena como que va a ser grande. Excepto que hay un error.<\/span><\/p>\n

El error aqu\u00ed es que mis jugadores pueden empezar un intercambio y luego desconectarse, y entonces los objetos que podr\u00edamos querer que fueran raros no van a ser raros. Pueden ser duplicados dentro del sistema.<\/span><\/p>\n

En los juegos de rol multijugador masivos en l\u00ednea, se llama \"Dup Bug\". Si vas a Google y buscas \"Dup Bug\", encontrar\u00e1s un mont\u00f3n de escenarios.<\/span><\/p>\n

Aqu\u00ed hay uno de hace s\u00f3lo un par de semanas, donde Final Fantasy Crystal Chronicles en Switch tuvo que ser parcheado debido a un bug Dup. Y luego hab\u00eda uno s\u00f3lo unos d\u00edas antes de que, esto es de un blog donde un blogger juego mostrando a la gente c\u00f3mo utilizar este glitch dup para recuperar... para obtener art\u00edculos adicionales dentro del juego.<\/span><\/p>\n

As\u00ed que tenemos que arreglar este fallo. \u00bfC\u00f3mo vamos a hacerlo? Bueno, vamos a echar mano de nuestra bolsa de trucos de Couchbase.<\/span><\/p>\n

Vamos a introducir las transacciones Couchbase. El modo de juego es casi exactamente el mismo. Pero, \u00bfqu\u00e9 vamos a hacer con las transacciones Couchbase? Y esta es la diapositiva donde voy a hablar un poco sobre el c\u00f3digo.<\/span><\/p>\n<\/details>\n

 <\/p>\n

Transacciones ACID distribuidas multidocumento en Couchbase<\/span><\/h2>\n

 <\/p>\n

Ahora que entiendes c\u00f3mo se comportan las transacciones en diferentes modelos de datos, es hora de profundizar en c\u00f3mo lo hemos implementado en Couchbase y qu\u00e9 nos llev\u00f3 a tomar nuestras decisiones de dise\u00f1o. En primer lugar, vamos a repasar la sintaxis:<\/span><\/p>\n

transactions.run((ctx) -> {\r\n        \/\/ get the account documents for userA and UserB \t\r\n        TransactionJsonDocument userA = ctx.getOrError(collection, \"userA\");\r\n        JsonObject userAContent = userA.contentAsObject();\r\n        int userABalance = userAContent.getInt(\"account_balance\");\r\n        TransactionJsonDocument userB = ctx.getOrError(collection, \"Beth\"); \r\n        JsonObject userBContent = userB.contentAsObject();\r\n        int userBBalance = userBContent.getInt(\"account_balance\");\r\n\r\n        \/\/ if userB has sufficient funds, make the transfer\r\n        if (userBBalance > transferAmount) {\r\n                userAContent.put(\"account_balance\", userABalance + transferAmount);\r\n                ctx.replace(userA, userAContent);\r\n                userBContent.put(\"account_balance\", userBBalance - transferAmount);\r\n                ctx.replace(userB, userBContent);\r\n        }\r\n        else throw new InsufficientFunds();  \r\n});<\/pre>\n
El ejemplo Java anterior es el ejemplo cl\u00e1sico de c\u00f3mo transferir dinero entre dos clientes.  Observe que hemos decidido utilizar un <\/span>funci\u00f3n lambda<\/span><\/a> para expresar la transacci\u00f3n. El manejo adecuado de errores puede ser un reto en este escenario y envolver tu transacci\u00f3n con una funci\u00f3n an\u00f3nima permite al SDK Java de Couchbase hacer ese trabajo por ti (es decir, reintentar si algo falla).<\/span><\/p>\n
Cuando lanzamos por primera vez el soporte para transacciones, intent\u00e1bamos evitar la verborrea. As\u00ed era la sintaxis de transacciones de un competidor:<\/span><\/p>\n
\"\"<\/p>\n
\u00daltimamente, parece que el manejo de transacciones dentro de funciones lambda se est\u00e1 convirtiendo en la norma para las bases de datos NoSQL.<\/span><\/p>\n
Para aquellos que esperaban que fuera similar a la sintaxis relacional para las transacciones (por ejemplo, comandos SQL BEGIN\/COMMIT\/ROLLBACK), sigue leyendo: \u00a1tambi\u00e9n puedes ejecutar transacciones a trav\u00e9s de N1QL! Ahora, vamos a tratar de entender lo que est\u00e1 sucediendo bajo el cap\u00f3.<\/span><\/p>\n
 <\/p>\n
Revisi\u00f3n de la arquitectura de Couchbase<\/span><\/h3>\n
Para aquellos que no est\u00e9n familiarizados con la arquitectura de Couchbase, necesito explicar r\u00e1pidamente 4 conceptos importantes antes de seguir adelante:<\/span><\/p>\n