Data Warehousing - Tuning

Um data warehouse continua evoluindo e é imprevisível qual consulta o usuário postará no futuro. Portanto, fica mais difícil ajustar um sistema de data warehouse. Neste capítulo, discutiremos como ajustar os diferentes aspectos de um data warehouse, como desempenho, carga de dados, consultas, etc.

Dificuldades no ajuste do data warehouse

Ajustar um data warehouse é um procedimento difícil devido aos seguintes motivos -

O data warehouse é dinâmico; nunca permanece constante.
É muito difícil prever qual consulta o usuário postará no futuro.
Os requisitos de negócios mudam com o tempo.
Os usuários e seus perfis estão sempre mudando.
O usuário pode alternar de um grupo para outro.
A carga de dados no warehouse também muda com o tempo.

Note - É muito importante ter um conhecimento completo de data warehouse.

Avaliação de desempenho

Aqui está uma lista de medidas objetivas de desempenho -

Tempo médio de resposta à consulta
Taxas de varredura
Tempo usado por consulta do dia
Uso de memória por processo
Taxas de transferência de E / S

A seguir estão os pontos a serem lembrados.

É necessário especificar as medidas no acordo de nível de serviço (SLA).
Não adianta tentar ajustar o tempo de resposta, se eles já são melhores do que os necessários.
É essencial ter expectativas realistas ao fazer a avaliação de desempenho.
Também é essencial que os usuários tenham expectativas viáveis.
Para ocultar a complexidade do sistema do usuário, agregações e visualizações devem ser usadas.
Também é possível que o usuário escreva uma consulta que você não tenha ajustado.

Ajuste de carga de dados

A carga de dados é uma parte crítica do processamento noturno. Nada mais pode ser executado até que o carregamento de dados seja concluído. Este é o ponto de entrada no sistema.

Note- Se houver um atraso na transferência dos dados ou na chegada dos dados, todo o sistema será gravemente afetado. Portanto, é muito importante ajustar primeiro o carregamento de dados.

Existem várias abordagens para ajustar a carga de dados que são discutidas abaixo -

A abordagem muito comum é inserir dados usando o SQL Layer. Nessa abordagem, verificações e restrições normais precisam ser realizadas. Quando os dados são inseridos na tabela, o código é executado para verificar se há espaço suficiente para inserir os dados. Se não houver espaço suficiente disponível, pode ser necessário alocar mais espaço para essas tabelas. Essas verificações demoram para serem executadas e custam caro para a CPU.
A segunda abordagem é ignorar todas essas verificações e restrições e colocar os dados diretamente nos blocos pré-formatados. Esses blocos são posteriormente gravados no banco de dados. É mais rápido do que a primeira abordagem, mas pode funcionar apenas com blocos inteiros de dados. Isso pode levar a algum desperdício de espaço.
A terceira abordagem é que, ao carregar os dados na tabela que já contém a tabela, podemos manter os índices.
A quarta abordagem diz que para carregar os dados em tabelas que já contêm dados, drop the indexes & recreate themquando o carregamento de dados for concluído. A escolha entre a terceira e a quarta abordagem depende de quantos dados já estão carregados e de quantos índices precisam ser reconstruídos.

Verificações de integridade

A verificação de integridade afeta fortemente o desempenho da carga. A seguir estão os pontos a serem lembrados -

As verificações de integridade precisam ser limitadas porque exigem grande capacidade de processamento.
As verificações de integridade devem ser aplicadas no sistema de origem para evitar degradação do desempenho do carregamento de dados.

Tuning Queries

Temos dois tipos de consultas no data warehouse -

Consultas corrigidas
Consultas ad hoc

Consultas Fixas

As consultas fixas são bem definidas. A seguir estão os exemplos de consultas fixas -

relatórios regulares
Consultas enlatadas
Agregações comuns

Ajustar as consultas fixas em um data warehouse é o mesmo que em um sistema de banco de dados relacional. A única diferença é que a quantidade de dados a ser consultada pode ser diferente. É bom armazenar o plano de execução mais bem-sucedido enquanto testa as consultas fixas. Armazenar esses planos de execução nos permitirá detectar a alteração do tamanho dos dados e a distorção dos dados, pois isso fará com que o plano de execução seja alterado.

Note - Não podemos fazer mais na tabela de fatos, mas ao lidar com tabelas de dimensão ou agregações, a coleção usual de ajustes de SQL, mecanismo de armazenamento e métodos de acesso podem ser usados para ajustar essas consultas.

Consultas Ad hoc

Para entender as consultas ad hoc, é importante conhecer os usuários ad hoc do data warehouse. Para cada usuário ou grupo de usuários, você precisa saber o seguinte -

O número de usuários no grupo
Se eles usam consultas ad hoc em intervalos regulares de tempo
Se eles usam consultas ad hoc com frequência
Se eles usam consultas ad hoc ocasionalmente em intervalos desconhecidos.
O tamanho máximo da consulta que eles tendem a executar
O tamanho médio da consulta que eles tendem a executar
Se eles exigem acesso detalhado aos dados de base
O tempo de login decorrido por dia
O horário de pico de uso diário
O número de consultas que eles executam por hora de pico

Points to Note

É importante rastrear os perfis do usuário e identificar as consultas que são executadas regularmente.
Também é importante que a afinação realizada não afete o desempenho.
Identifique consultas semelhantes e ad hoc que são executadas com frequência.
Se essas consultas forem identificadas, o banco de dados será alterado e novos índices podem ser adicionados a essas consultas.
Se essas consultas forem identificadas, novas agregações podem ser criadas especificamente para essas consultas que resultariam em sua execução eficiente.