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) Data Science in Practice with Python - Sample 2

In this post I'll explain what is a recommender system, how work it and show you some code examples. In my previous post I did a quick introduction:

Sample 2 - Recommender System

WHAT IS A RECOMMENDER SYSTEM? A model that filters information to present users with a curated subset of options they’re likely to find appealing.
HOW DOES IT WORK? Generally via a collaborative approach (considering user’s previous behavior) or content based approach (based on discrete assigned characteristics).

Now I'll get into in some concepts very important about recommender systems.

Recommender System in Details:

We can say that the goal of a recommender system is to make product or service recommendations to people. Of course, these recommendations should be for products or services they’re more likely to want buy or consume.

Recommender systems are active information filtering systems which personalize the information coming to a user based on his interests, relevance of the information etc.…

(T) Verificando a consistência de um repositório ou um Business Model no Oracle BI