Bom dia pessoal!
Gostaria de compartilhar com vocês uma experiência que tenho passado nas últimas semanas.
Aqui na empresa tenho desenvolvido um projeto que tem objetivo de reduzir a carga de um aplicativo de 1h40min para cerca de 15 minutos. Pois bem: estou conseguindo.
O que tenho feito?
Após analisar o processo de carga do aplicativo, identificamos que o nosso principal problema é o volume de dados e a granularidade dos mesmos; nossos usuários querem analisar as informações nos detalhes, e querem analisar o histórico das informações (por definição interna trabalhamos "somente" com os dados de vendas e faturamento desde 2012).
Como essa barreira não poderia ser quebrada, passamos a atacar o problema onde ainda tínhamos controle: a carga e preparação dos dados.
A partir dessa definição, iniciamos um trabalho de reescrita das cargas dos dados do banco de dados (Oracle), além de outras otimizações nos processos, conforme abaixo:
Estrutura da leitura de dados
- Anteriormente, tínhamos dois processos de leitura: um QVW que lia os dados do banco de dados e gerava um QVD, e outro processo que lia o QVD gerado e criava novos QVDs, quebrando a informação por ano. Também eram realizadas formatações de campos numéricos e outras "perfumarias" com os dados.
- No novo processo, eliminamos a primeira leitura e agora temos somente um QVW que lê os dados e somente aplica regras de conversão de indicadores, através da função ApplyMap. Também foi implementado um controle que permite a geração completa ou incremental dos dados, através da função EXISTS. Outro ganho foi a geração das informações por mês e ano, o que levou a arquivos menores e, por consequência, leituras mais rápidas.
Geração dos QVDs
Os arquivos QVDs agora são criados com as mais diversas chaves para ligação. Como a estrutura de tabelas no banco é composta por diversas chaves compostas, o processo de geração dos QVDs agora "cria" as chaves que poderão ser utilizadas para conexão com outras tabelas. Assim, não há a necessidade de criação de chaves no momento das leitura.
Separação das informações
Restrições de consulta já conhecidas são aplicadas na geração dos arquivos, gerando muitas vezes arquivos diferentes com as informações; quando da criação de novas cargas, é investido um tempo maior para identificar possíveis novas restrições.
Equalização da estrutura de tabelas com mesma informação
Em virtude da separação das informações, também tive que equalizar a estrutura de arquivos que foram separados mas que frequentemente são utilizados em conjunto nos aplicativos.
Pré-execução de processos
Processos de transformação muitas vezes executados na aplicação foram colocados em programas separados e executados antes da carga dos dados para o aplicativo.
Ainda não concluí o projeto, mas achei que já era informação suficiente para compartilhar. As prévias de geração dos dados já apresentam redução de 70-80% em relação ao atual. Assim que concluir a migração passo aqui e atualizo vocês com o resultado.
Márcio
Dica importante:
- Quando quiser utilizar o EXISTS para leitura otimizada, o campo da restrição sempre DEVE fazer parte do LOAD.
Márcio Rodrigo Campestrini
