{"id":36650,"date":"2019-10-31T22:12:54","date_gmt":"2019-10-31T19:12:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-v-globalah-intersystems-iris\/"},"modified":"2019-10-31T22:12:54","modified_gmt":"2019-10-31T19:12:54","slug":"tranzaktsii-v-globalah-intersystems-iris","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Transacciones en las globales de InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"TransaccionesLa base de datos InterSystems IRIS admite estructuras curiosas para el almacenamiento de datos: las globales. En esencia, son claves multinivel con diversas ventajas adicionales como transacciones, funciones r\u00e1pidas para navegar por \u00e1rboles de datos, bloqueos y su propio lenguaje ObjectScript.<\/p>\n

M\u00e1s sobre las globales en la serie de art\u00edculos \u00abLas globales: espadas en el almacenamiento de datos\u00bb:<\/p>\n

\u00c1rboles. Parte 1<\/a><\/noindex>
\n\u00c1rboles. Parte 2<\/a><\/noindex>
\nMatrices dispersas. Parte 3<\/a><\/noindex><\/p>\n

Me intrig\u00f3 c\u00f3mo se implementan las transacciones en las globales y qu\u00e9 caracter\u00edsticas tienen. Dado que se trata de una estructura de almacenamiento de datos completamente diferente de las tablas que todos conocemos, es mucho m\u00e1s de bajo nivel.
\n<\/a><\/noindex>
\nComo se sabe en la teor\u00eda de bases de datos relacionales, una buena implementaci\u00f3n de transacciones debe cumplir con los requisitos ACID<\/a><\/noindex>:<\/p>\n

A \u2014 At\u00f3mico.<\/b> Se registran todos los cambios realizados en la transacci\u00f3n o ning\u00fan cambio en absoluto.<\/p>\n

C \u2014 Consistencia.<\/b> Despu\u00e9s de completar la transacci\u00f3n, el estado l\u00f3gico de la base de datos debe ser internamente coherente. En gran medida, este requisito corresponde al programador, pero en el caso de bases de datos SQL, tambi\u00e9n se refiere a las claves externas.<\/p>\n

I \u2014 Aislado.<\/b> Las transacciones que se ejecutan en paralelo no deben influirse entre s\u00ed.<\/p>\n

D \u2014 Durable.<\/b> Despu\u00e9s de que una transacci\u00f3n se complete con \u00e9xito, los problemas en niveles inferiores (como un corte de energ\u00eda, por ejemplo) no deben afectar los datos modificados por la transacci\u00f3n.<\/p>\n

Las globales son estructuras de datos no relacionales. Fueron creadas para un funcionamiento extremadamente r\u00e1pido en hardware muy limitado. Vamos a analizar la implementaci\u00f3n de transacciones en las globales usando la imagen oficial de docker de IRIS<\/a><\/noindex>.<\/p>\n

Para soportar transacciones en IRIS, se utilizan los comandos: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomicidad<\/h2>\n

\nEs m\u00e1s f\u00e1cil verificar la atomicidad. Comprobamos desde la consola de la base de datos.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nLuego hacemos la salida:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nObtenemos:<\/p>\n
1 2 3<\/code><\/pre>\n
\nTodo en orden. Se cumple la atomicidad: todos los cambios se registraron.<\/p>\n
Complicaremos la tarea, introduciremos un error y veremos c\u00f3mo se guarda la transacci\u00f3n, parcialmente o no se guarda en absoluto.<\/p>\n
Verificamos de nuevo la atomicidad:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nDespu\u00e9s de lo cual forzaremos el contenedor a detenerse, lo iniciaremos y observaremos. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nEste comando es pr\u00e1cticamente equivalente a un apagado forzado, ya que env\u00eda la se\u00f1al de parada inmediata del proceso SIGKILL.<\/p>\n
\u00bfPodr\u00eda ser que la transacci\u00f3n se haya guardado parcialmente?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 No, no se guard\u00f3.<\/p>\n
Probemos el comando de reversi\u00f3n:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTROLLBACK\n\nWRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\nTampoco se guard\u00f3 nada.<\/p>\n
2. Consistencia<\/h2>\n
\nDado que en las bases de datos, los \u00edndices se realizan tambi\u00e9n sobre los globales (recordemos que un global es una estructura de almacenamiento de datos de bajo nivel, m\u00e1s que una tabla relacional), para cumplir con el requisito de consistencia, es necesario incluir el cambio de clave en la misma transacci\u00f3n que el cambio del global.<\/p>\n
Por ejemplo, tenemos el global ^person, donde almacenamos identidades, y usamos el NIF como clave.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nPara tener una b\u00fasqueda r\u00e1pida por apellido y nombre, creamos el \u00edndice ^index.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nPara que la base sea consistente, debemos agregar la identidad de esta manera:<\/p>\n
TSTART\n^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n^index('Kamenev', 'Sergey', 1234567) = 1\nTCOMMIT<\/code><\/pre>\n
\nPor lo tanto, al eliminar tambi\u00e9n debemos usar una transacci\u00f3n:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index('Kamenev', 'Sergey', 1234567)\nTCOMMIT<\/code><\/pre>\n
\nEn otras palabras, el cumplimiento del requisito de consistencia recae completamente en el programador. Pero cuando se trata de globales, esto es normal, debido a su naturaleza de bajo nivel.<\/p>\n
3. Aislamiento<\/h2>\n
\nAqu\u00ed es donde comienzan los problemas. Muchos usuarios trabajan simult\u00e1neamente en la misma base, modificando los mismos datos.<\/p>\n
La situaci\u00f3n es comparable a cuando muchos usuarios trabajan al mismo tiempo con el mismo repositorio de c\u00f3digo y tratan de enviar cambios a muchos archivos al mismo tiempo.<\/p>\n
La base de datos debe gestionar todo esto en tiempo real. Dado que en empresas serias incluso hay una persona dedicada a controlar las versiones (a fusionar ramas, resolver conflictos, etc.), y la base de datos debe hacerlo todo en tiempo real, se hace evidente la complejidad de la tarea y la necesidad de un dise\u00f1o correcto de la base de datos y del c\u00f3digo que la mantenga.<\/p>\n
Una base de datos no puede entender el significado de las acciones realizadas por los usuarios para evitar conflictos cuando trabajan con los mismos datos. Solo puede deshacer una transacci\u00f3n que contradice a otra o ejecutarlas de manera secuencial.<\/p>\n
Otro problema es que durante la ejecuci\u00f3n de una transacci\u00f3n (antes del commit), el estado de la base de datos puede ser inconsistente. Por lo tanto, es deseable que otras transacciones no tengan acceso a este estado inconsistente, lo que se logra en bases de datos relacionales de diversas maneras: creando instant\u00e1neas, mediante la multiversion de filas, etc.<\/p>\n
Cuando se ejecutan transacciones en paralelo, es importante que no interfieran entre s\u00ed. Esta es la propiedad de aislamiento.<\/p>\n
SQL define 4 niveles de aislamiento:<\/p>\n