Separação dos dados transacionais x históricos
por Sálvio Padlipskas
Olá amigos(as) !
Dias atrás em 28/11/2006 – sábado, estávamos no evento InterCon2006 falando sobre a importância de manter o bom desempenho em termos de acesso feito ao banco de dados. Um dos temas mais excitantes e que agradou a toda comunidade que estava presente, foi a “separação dos dados transacionais x históricos”.
Nesse artigo iremos abordar a importância e como fazer uma distribuição dos dados a fim de garantir acessos heterogêneos feitos pelas aplicações, garantindo a cada tipo de usuário um desempenho proporcional a sua complexidade.
A justificativa
O principal motivo para que seja aplicada essa técnica é o trafegar a informação de forma objetiva, evitando realizar muitas leituras dos blocos de dados, que é a unidade básica de leitura do banco de dados. Essa técnica é o mapa do tesouro para aplicações críticas como leilões on-line ou bolsa de valores, ou para aquelas que trabalhem com alta disponibilidade ou com grande volume de dados.
O resultado é simples : Garantir o bom desempenho, pois o banco de dados irá acessar um menor número de blocos de dados, diminuindo assim o tempo para processar a consulta.
Outras justificativas seriam: Menor tempo de backup e restore do banco de dados transacional, diminuição do tempo de recuperação do banco de dados entre outros.
Como fazer ?
De forma bem simplificada, os passos a seguir devem ser executados :
1) Separar fisicamente os banco de dados em duas ou mais máquinas
2) Duplicar o banco de dados (com linhas e suas respectivas interações com outros databases)
3) Criar um mecanismo de sincronismo entre os banco de dados, de acordo com a criticidade e o objetivo da aplicação
Uma ressalva. Até aqui os dados estão “duplicados”, porém com sincronismo. Isso quer dizer que se criarmos um usuário HISTÓRICO e fazer com que ele acesse o banco de dados de histórico descrito no item 2 apenas apontamos para a base histórico.
Para ajustar os dados transacionais, seguimos em frente :
4) Eliminar as linhas de histórico do banco de dados transacional. Essa fase é uma fase extremamente crítica e um profissional especializado como um AD (Administrador de Dados), é de vital importância para garantir que a definição do que é informação histórico e o que é informação transacional deve ser cumprida de forma a alcançar a definição feita pela empresa.
Nesse momento em nossas mãos temos 2 usuários : o usuário comum que acessa o dado transacional e o usuário HISTÒRICO, que é acessado pelas pessoas que necessitam da informação em maior granularidade, exigindo uma grande massa de dados.
Os dados também estão sincronizados, então temos 2 bancos de dados distribuídos, porém com volume de dados diferentes. O banco de dados transacional comporta apenas as informações de uso diário e que não geram estatísticas, porém guardar a informação mais atualizada e indispensável para o banco de dados de histórico, que contém toda a granularidade da informação em termos de volume de dados.
5) Modificar a aplicação, dividindo o acesso da aplicação de acordo com o tipo de usuário. Os usuários transacionais não mais poderão extrair informações históricas. Porém os usuários históricos podem extrair informações atuais e históricas. Aqui será necessário criar privilégios com menus dinâmicos de acesso, fazendo a distribuição necessária.
6) Por fim, monitorar com freqüência os ambientes e coletar métricas com os usuários e os próprios recursos que o ambiente proporciona.
7) Sair para comemorar (e pode me convidar que estarei lá para sorrir também), pois o sucesso com certeza será alcançado
Pontos Positivos
ü Custo com o hardware transacional fica estacionado, pois ele irá conter somente as informações necessárias para que a aplicação atinja seu objetivo.
ü Tempo de retorno dos dados no acesso à informação
ü Satisfação do usuário
Pontos Negativos
ü Custo com um novo hardware para a base de dados históricos
ü Complexidade em manter o sincronismo entre os bancos de dados
ü Aumento da complexidade da aplicação
ü Ajuste na aplicação (código fonte)
Bem amigos(as), perante o exposto devemos analisar detalhadamente os pontos críticos e os possíveis pontos de falhas e tomar a decisão de implementar ou não a técnica. Essa técnica é altamente recomendada para novas aplicações que sendo geridas da fase de modelagem de dados e novas especificações.
Todo esse esforço é recompensado pela velocidade no tráfego de dados feito entre a aplicação e o banco de dados. Garantir que sua aplicação seja executada na maravilhosa web por milhares de pessoas satisfeitas em termos de desempenho no acesso à informação pode fazer a diferença entre a prosperidade e a ruína.
Então mãos à obra !
[ ] ´s
Salvio Padlipskas
