{"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\/pt\/blog\/administrirovanie\/tranzaktsii-v-globalah-intersystems-iris","title":{"rendered":"Transa\u00e7\u00f5es em globais InterSystems IRIS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Transa\u00e7\u00f5esO SGBD InterSystems IRIS suporta estruturas curiosas para armazenamento de dados \u2014 globais. Essencialmente, s\u00e3o chaves em m\u00faltiplos n\u00edveis com diversas funcionalidades adicionais, como transa\u00e7\u00f5es, fun\u00e7\u00f5es r\u00e1pidas para navega\u00e7\u00e3o em \u00e1rvores de dados, bloqueios e sua pr\u00f3pria linguagem ObjectScript.<\/p>\n

Saiba mais sobre globais na s\u00e9rie de artigos \"Globais \u2014 espadas m\u00e1gicas para armazenamento de dados\":<\/p>\n

\u00c1rvores. Parte 1<\/a><\/noindex>
\n\u00c1rvores. Parte 2<\/a><\/noindex>
\nMatrizes esparsas. Parte 3<\/a><\/noindex><\/p>\n

Fiquei curioso sobre como as transa\u00e7\u00f5es s\u00e3o implementadas em globais, quais s\u00e3o suas particularidades. Afinal, trata-se de uma estrutura totalmente diferente para armazenamento de dados em compara\u00e7\u00e3o com as tabelas habituais. \u00c9 muito mais de baixo n\u00edvel.
\n<\/a><\/noindex>
\nComo \u00e9 sabido na teoria de bancos de dados relacionais, uma boa implementa\u00e7\u00e3o de transa\u00e7\u00f5es deve satisfazer os requisitos ACID<\/a><\/noindex>:<\/p>\n

A \u2014 Atomicidade.<\/b> Todas as altera\u00e7\u00f5es feitas na transa\u00e7\u00e3o s\u00e3o registradas ou nenhuma delas \u00e9.<\/p>\n

C \u2014 Consist\u00eancia.<\/b> Ap\u00f3s a conclus\u00e3o da transa\u00e7\u00e3o, o estado l\u00f3gico do BD deve ser internamente consistente. Em grande parte, esse requisito diz respeito ao programador, mas, no caso de bancos de dados SQL, tamb\u00e9m se relaciona a chaves externas.<\/p>\n

I \u2014 Isolamento.<\/b> Transa\u00e7\u00f5es executadas em paralelo n\u00e3o devem influenciar umas \u00e0s outras.<\/p>\n

D \u2014 Durabilidade.<\/b> Ap\u00f3s a conclus\u00e3o bem-sucedida da transa\u00e7\u00e3o, problemas em n\u00edveis inferiores (como uma falha de energia) n\u00e3o devem afetar os dados alterados pela transa\u00e7\u00e3o.<\/p>\n

Globais s\u00e3o estruturas de dados n\u00e3o relacionais. Elas foram criadas para operar em alta velocidade em hardware muito limitado. Vamos examinar a implementa\u00e7\u00e3o de transa\u00e7\u00f5es em globais usando a imagem docker oficial do IRIS<\/a><\/noindex>.<\/p>\n

Para suportar transa\u00e7\u00f5es no IRIS, s\u00e3o utilizados os comandos: TSTART<\/a><\/noindex>, TCOMMIT<\/a><\/noindex>, TROLLBACK<\/a><\/noindex>.<\/p>\n

1. Atomicidade<\/h2>\n

\n\u00c9 mais f\u00e1cil verificar a atomicidade. Vamos testar pelo console do banco de dados.<\/p>\n

Kill ^a\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3\nTCOMMIT<\/code><\/pre>\n
\nDepois, faremos a seguinte verifica\u00e7\u00e3o:<\/p>\n
Write ^a(1), \u201c \u201d, ^a(2), \u201c \u201d, ^a(3)<\/code><\/pre>\n
\nReceberemos:<\/p>\n
1 2 3<\/code><\/pre>\n
\nTudo em ordem. Atomicidade cumprida: todas as altera\u00e7\u00f5es foram gravadas.<\/p>\n
Vamos complicar a situa\u00e7\u00e3o, introduzindo um erro e vendo como a transa\u00e7\u00e3o ser\u00e1 mantida, parcialmente ou n\u00e3o.<\/p>\n
Mais uma vez, vamos verificar a atomicidade:<\/p>\n
Kill ^A\nTSTART\nSet ^a(1) = 1\nSet ^a(2) = 2\nSet ^a(3) = 3<\/code><\/pre>\n
\nEm seguida, pararemos o cont\u00eainer for\u00e7osamente, reiniciaremos e veremos. <\/p>\n
docker kill my-iris<\/code><\/pre>\n
\nEste comando \u00e9 praticamente equivalente a uma interrup\u00e7\u00e3o for\u00e7ada de energia, pois envia um sinal de parada imediata do processo SIGKILL.<\/p>\n
Pode ser que a transa\u00e7\u00e3o tenha sido salva parcialmente?<\/p>\n
WRITE ^a(1), ^a(2), ^a(3)\n^\n ^a(1)<\/code><\/pre>\n
\n \u2014 N\u00e3o, n\u00e3o foi salva.<\/p>\n
Testaremos o comando de revers\u00e3o:<\/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
\nNada foi salvo tamb\u00e9m.<\/p>\n
2. Consist\u00eancia<\/h2>\n
\nComo nas bases de dados globais as chaves tamb\u00e9m s\u00e3o feitas em globais (lembro que global \u00e9 uma estrutura de n\u00edvel inferior para armazenamento de dados, comparado a uma tabela relacional), para atender \u00e0 exig\u00eancia de consist\u00eancia, a modifica\u00e7\u00e3o da chave deve ser inclu\u00edda na mesma transa\u00e7\u00e3o que a modifica\u00e7\u00e3o do global.<\/p>\n
Por exemplo, temos o global ^person, onde armazenamos personalidades e usamos o CPF como chave.<\/p>\n
^person(1234567, 'firstname') = 'Sergey'\n^person(1234567, 'lastname') = 'Kamenev'\n^person(1234567, 'phone') = '+74995555555\n...<\/code><\/pre>\n
\nPara ter uma busca r\u00e1pida pelo sobrenome e nome, criamos a chave ^index.<\/p>\n
^index('Kamenev', 'Sergey', 1234567) = 1<\/code><\/pre>\n
\nPara que o banco esteja consistente, devemos adicionar a personalidade da seguinte forma:<\/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
\nPortanto, ao excluir, tamb\u00e9m devemos usar uma transa\u00e7\u00e3o:<\/p>\n
TSTART\nKill ^person(1234567)\nZKill ^index('Kamenev', 'Sergey', 1234567)\nTCOMMIT<\/code><\/pre>\n
\nEm outras palavras, o cumprimento da exig\u00eancia de consist\u00eancia recai completamente sobre os ombros do programador. Mas quando se trata de globais, isso \u00e9 normal, devido \u00e0 sua natureza de n\u00edvel inferior.<\/p>\n
3. Isolamento<\/h2>\n
\nAqui come\u00e7am as complica\u00e7\u00f5es. Muitos usu\u00e1rios trabalham simultaneamente em um mesmo banco de dados, alterando os mesmos dados.<\/p>\n
A situa\u00e7\u00e3o \u00e9 compar\u00e1vel a muitos usu\u00e1rios trabalhando simultaneamente em um mesmo reposit\u00f3rio de c\u00f3digo e tentando commitar mudan\u00e7as em muitos arquivos ao mesmo tempo.<\/p>\n
O banco de dados deve lidar com tudo isso em tempo real. Considerando que em empresas s\u00e9rias h\u00e1 at\u00e9 uma pessoa espec\u00edfica respons\u00e1vel pelo controle de vers\u00f5es (por fus\u00f5es de branches, resolu\u00e7\u00e3o de conflitos etc.), e que o BD deve fazer tudo isso em tempo real, a complexidade da tarefa e a corre\u00e7\u00e3o do design do banco de dados e do c\u00f3digo que o suporta tornam-se evidentes.<\/p>\n
O banco de dados n\u00e3o consegue entender o significado das a\u00e7\u00f5es executadas pelos usu\u00e1rios para evitar conflitos ao trabalharem com os mesmos dados. Ele pode apenas desfazer uma transa\u00e7\u00e3o que contradiz outra ou execut\u00e1-las de forma sequencial.<\/p>\n
Outro problema \u00e9 que, durante a execu\u00e7\u00e3o da transa\u00e7\u00e3o (antes do commit), o estado do banco pode estar inconsistente, por isso \u00e9 desej\u00e1vel que outras transa\u00e7\u00f5es n\u00e3o tenham acesso a esse estado inconsistente do banco de dados, o que \u00e9 alcan\u00e7ado em bancos de dados relacionais de v\u00e1rias maneiras: cria\u00e7\u00e3o de snapshots, multiversionamento de linhas, etc.<\/p>\n
Durante a execu\u00e7\u00e3o paralela de transa\u00e7\u00f5es, \u00e9 importante que elas n\u00e3o interfiram uma na outra. Essa \u00e9 a propriedade de isolamento.<\/p>\n
O SQL define 4 n\u00edveis de isolamento:<\/p>\n