DevSecOps

23 mar, 2015

Seu sistema vai lidar com transações?

Publicidade

Sabe aquelas aulas da faculdade que você acabou matando por achar que seriam chatas? É possível que uma delas tenha sido a que apresentou o conceito de transação, um assunto tão importante no universo da Tecnologia de Informação que merece três verbetes na Wikipedia (veja aqui).

Talvez você tenha pensado “mas eu estou estudando para ser programador; por que haveria de me importar com transações”?

Naquela época você poderia estar preocupado exclusivamente com o que imaginava ser a vida de programador: linguagens, metodologias e técnicas de programação… Mas eu, sinceramente, espero que você já tenha percebido que quem investe em tecnologia vê as aplicações e sistemas como meios para se coletar dados. E são estes dados que justificam o investimento em tecnologia.

E para um sem-número de sistemas, transações significam dados íntegros. Sistemas comerciais e financeiros, por exemplo, não existiriam sem transações. É por isso que são tão importantes para as empresas.

Pessoalmente, eu não ficaria nem um pouco satisfeito em fazer uma transferência bancária da minha conta corrente para a poupança se o dinheiro desaparecesse no meio do processo por razões banais, como perda de conexão, falha energia, falha de hardware etc. Eu, como cliente, direi que isso não é problema meu: é o banco que tem que se preocupar com estas questões. É por isso que o banco investe em sistemas que tratam de transações. A transferência (no caso, uma transação) está completa quando for executada 100%. Do contrário, ela volta à estaca zero e é inteiramente desfeita.

Um pouco de história

Nos anos 1950, o mercado americano de aviação crescia rapidamente e um dos principais problemas deste crescimento era a dificuldade de controlar a venda de passagens aéreas. Tudo era feito manualmente e frequentemente aconteciam problemas de duplicidade de reservas de assentos: dois clientes recebendo confirmações de reserva do mesmo assento no mesmo voo. Ao mesmo tempo, a computação estava passando por grandes avanços. O lançamento de uma nova unidade de armazenamento em fita magnética, por exemplo, foi uma revolução no mundo de TI (saiba mais aqui).

A combinação destes dois fatores deu início à criação do primeiro sistema transacional online, que tinha um nome bem complicado: Ambiente de Pesquisa de Negócios Semi -Automatizado, ou SABRE na sigla em inglês. Tratava-se de um sistema transacional para agendamento e venda de passagens aéreas, criado pela American Airlines com ajuda da IBM. Com este sistema, clientes podiam comprar passagens de ida-volta entre Los Angeles e Nova York, por exemplo, tendo a certeza que os assentos reservados não seriam vendidos a nenhuma outra pessoa.

Hoje são milhões de sistemas transacionais que suportam os negócios de empresas do mundo inteiro. Mas o SABRE foi o primeiro deles e é o mais famoso de todos.

Um pouco de teoria

Enquanto os sistemas transacionais se popularizavam, aumentava também a concorrência entre as operações reconhecidas como parte de uma unidade de trabalho, ou seja, uma transação.

Em consequência, o conceito de transação foi evoluindo ao longo dos anos. Até que no fim dos anos 1970, Jim Gray, pesquisador da IBM, definiu as propriedades essenciais para uma transação: atomicidade, consistência, isolamento e durabilidade, que juntas formam a famosa sigla ACID. A ideia do ACID é garantir que as transações sejam executadas com precisão mesmo em ambientes de alta concorrência (leia-se: milhares de transações acontecendo ao mesmo tempo).

Sendo assim, ou todo bloco de operações da transação é executado e então a transação recebe um “COMMIT”, ou então todas as operações executadas até o momento da falha são desfeitas (o “ROLLBACK”). Isso garante a atomicidade da transação (o A do ACID).

Ao mesmo tempo, por completar todas as operações ou então desfazer o que ficou pela metade e restaurar os dados a um estado válido, garante a consistência da transação.

Não importa quantas outras transações tentem alterar os mesmos registros. A primeira transação que afetar aquele registro tem prioridade. E as demais ficam “bloqueadas”, aguardando em fila a liberação do recurso. Os bloqueios garantem o isolamento da transação, ou seja, uma transação não interfere na outra.

E a durabilidade é garantida pelo SGBD ao apresentar os mesmos dados até que uma nova transação os afete. Não importa se o caiu a energia, ou se o serviço do SGBD foi parado. Quando o SGBD voltar ao ar, os mesmos dados estarão lá.

Um pouco de bom-senso

Hoje o mercado ainda é dominado pelos SGBDs relacionais, que são excelentes para lidarem com transações. No entanto, estes SGBDs apresentam problemas quando são adaptados para funcionar com aplicações que usam dados desestruturados.

Atualmente, temos um sem número de SGBDs e grande parte deles se destina a sistemas que não são transacionais. Estes SGBDs especiais são muito bons para diversas aplicações específicas, mostrando resultados muito melhores do que aqueles obtidos com tecnologias tradicionais. Se sua aplicação trabalha com dados desestruturados e não transacionais, muito provavelmente será melhor optar por um SGBD especializado do que um SGBD relacional.

Mas o bom senso sugere que a recíproca também é verdadeira. Para sistemas transacionais, dificilmente você vai errar optando por um SGBD relacional.

No fim das contas, não importa o tamanho da empresa, ela sempre vai precisar de um SGBD para tratar de transações e provavelmente um ou mais SGBDs especiais para lidarem com outros tipos de aplicação. E eu digo isso por razões muito simples:

  1. Não existe empresa sem comércio;
  2. Não existe comércio sem transações;
  3. Em se tratando de transações, hoje ninguém supera os SGBDs relacionais.

Até a próxima!