Separação dos dados transacionais x históricos

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (3)  (0)

Veja neste artigo a importância e como fazer uma distribuição dos dados a fim de garantir acessos heterogêneos feitos pelas aplicações.

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.

imagem.JPG
 

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

 

 

 

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?