Pular para o conteúdo principal

(T) Indexação no Data Warehouse - Parte 2

Consideração sobre o predicado

Digamos que um data mart processasse continuamente consultas usando as colunas PURCHASE_DATE e CUST_NUM como parte do predicado. Essas duas colunas devem ser consideradas para índices. As colunas apresentadas como parte dos resultados da consulta, mas não utilizadas como parte de um predicado, não são boas candidatas para índice. Em outras palavras, a coluna em itálico na listagem a seguir pode não ser conveniente para um índice, enquanto a que parece em negrito pode ser uma candidata ideal:

select sum(aggr_day), region, ...
from day_summary, region
where trans_date between '01-jan-2002' and '31-jan-2002' ...;

Isso nos leva à segunda diretriz de indexação importante.

DICA: As colunas que normalmente fazem parte de critérios de seleção de consulta são candidatas para índices.

Naturalmente, como essa é uma regra (na verdade, uma diretriz), existem exceções. As colunas continuamente mencionadas em um predicado, mas nas quais uma função ou operação é efetuada, não são candidatas para índices. Se uma função deve ser executada em uma coluna, o índice da coluna não é usado. Chamamos isso de supressão de índice. A listagem a seguir mostra dois exemplos de como a coluna TRANS_DATE, da listagem anterior, pode ser usada, mas que não garante um índice:

select sum(aggr_day), region, ...
from day_summary, region
where to_char(trans_date, 'Dy') in ('Mon', 'Tue') ...;

select sum(aggr_day), region, ...
from day_summary, region
where months_between (trans_date, sysdate) > 6 ...;

Existe mais uma diretriz que trata com colunas mencionadas em predicados, com e sem função. Suponha que tenhamos um exemplo de quando a coluna TRANS_DATE de DAY_SUMMARY é usada na instrução SQL:

select ...
from day_summary ...
where to_char (trans_date) ...;

Assim como na instrução SQL:

select ...
from day_summary ...
where trans_date between ...;

DICA: Uma coluna que é usada em um predicado - com e sem função executada nela - ainda pode ser candidata para um índice. Analise o número de instruções SQL que estão usando uma função e implemente um índice, caso ele otimize as instruções sem uma função.

Exclusividade do data warehouse

De certa forma, verificamos aqui que a indexação de um data warehouse ou mesmo um data mart é um ponto importante a ser observado e tratado pelos arquitetos de solução juntamente com os administradores de banco de dados e que não pode ser colocado em segundo plano. Uma ocorrência comum encontrada no projeto de sistemas operacionais/transacionais é que o banco de dados usado durante o desenvolvimento é muito diferente de seu equivalente de produção. Por exemplo, ele poderia conter apenas um pequeno subconjunto dos dados de produção ou as tabelas usadas seriam uma fração de seu tamanho de produção.

Em algumas empresa é possível encontrar tabelas muito grandes, com 30 ou 40 milhões de linhas na produção e um subconjunto de 30 ou 40 mil linhas no desenvolvimento. No ambiente de data warehouse ou data mart, devem existir dados de desenvolvimento suficientes para que decisões de indexação bem pensadas possam ser tomadas em relação a volumes de dados realistas. Sob essas condições, torna-se mais fácil avaliar a eficiência dos índices e realizar testes para ajustar os índices adicionais que poderiam ajudar no desempenho das consultas a serem realizadas. As tabelas podem ser analisadas e cálculos sobre a seletividade podem ser feitos, para decidir quais são as colunas apropriadas para indexação.

DICA: As colunas indexadas nos sistemas operacionais/transacionais não são necessariamente boas candidatas à indexação no data warehouse.

Comentários

Postagens mais visitadas deste blog

(T) Como indexar uma tabela Fato - (Best Practice)

A base de qualquer projeto de bi é ter um bom dw/data mart. Podemos falar em modelagem star-schema durante dias, sem falar nas variações do snowflake, mas o objetivo principal deste artigo é apontar algumas negligências que tenho percebido no tratamento da tabela fato. Tabela esta que é o principal pilar da casa que reside um modelo star-schema.

Ouço muitas vezes os clientes reclamando do desempenho das consultas enviadas contra o seu dw/data mart, ou do tempo de resposta das análises solicitadas ao bi. Isto é realmente inaceitável, não só numa perspectiva de implantação do projeto, mas também de desempenho da entrega das informações.

Como eu mencionei anteriormente o meu objetivo neste artigo, é alertar sobre a importância da indexação da tabela fato: o que deveria ser, porque é necessário, porque chaves compostas são boas e más, e porque você deveria se preocupar com isso.

Então, vejamos:

|a| Indexação padrão (default):
De forma rápida, todas as colunas de chave estrangeira (FK) devem …

(A) Tucson Best Buy Analysis

“Data! Data! Data!” he cried impatiently.  “I can’t make bricks without clay.” —Arthur Conan Doyle
The Ascendance of Data

We live in a world that’s drowning in data. Websites track every user’s every click. Your smartphone is building up a record of your location and speed every second of every day. “Quantified selfers” wear pedometers-on-steroids that are ever recording their heart rates, movement habits, diet, and sleep patterns. Smart cars collect driving habits, smart homes collect living habits, and smart marketers collect purchasing habits. The Internet itself represents a huge graph of knowledge that contains (among other things) an enormous cross-referenced encyclopedia; domain-specific databases about movies, music, sports results, pinball machines, memes, and cocktails; and too many government statistics (some of them nearly true!) from too many governments to wrap your head around.
Buried in these data are answers to countless questions that no one’s ever thought to ask. In…