¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

É mais eficiente usar NOT IN em uma tabela de dimensões antes de unir com a tabela de fatos ou aplicá-lo diretamente na tabela de fatos?

  • Creado 01/03/2024
  • Modificado 01/03/2024
  • 0 Vistas
0
Cargando...

Suponhamos que tenho duas tabelas de armazenamento de colunas: uma grande tabela de fatos (FACT) com, digamos, 10 milhões de linhas, e uma tabela de dimensões (DIM) com 1.000 linhas. As duas tabelas são unidas em alguma chave arbitrária, digamos PRODUCT_ID.

Qual consulta teria melhor desempenho?


SELECT
     FACT.*
FROM
     FACT
WHERE
     FACT.PRODUCT_ID NOT IN ('A', 'B', 'C')

ou


SELECT
     FACT.*
FROM
     FACT INNER JOIN DIM ON
          FACT.PRODUCT_ID = DIM.PRODUCT_ID
WHERE
     DIM.PRODUCT_ID NOT IN ('A', 'B', 'C')

Em outras palavras, é mais rápido realizar a cláusula NOT IN na pequena tabela de dimensões e então unir à grande tabela de fatos, ou simplesmente realizar a cláusula NOT IN diretamente na grande tabela de fatos? Ou não há diferença? Suponhamos que não foram adicionados índices secundários às tabelas além das chaves primárias, onde PRODUCT_ID é a chave primária da tabela DIM e PRODUCT_ID faz parte de uma chave primária composta da tabela FACT.

Além disso, a situação muda se, digamos, nossa tabela FACT não for mais uma tabela, mas sim uma exibição de cálculo que une várias tabelas de transações para criar uma visão de fatos antes de ser usada nos cenários anteriores?

Saudações,

Chris.

Pedro Pascal
Se unió el 07/03/2018
Pinterest
Telegram
Linkedin
Whatsapp

2 Respuestas

0
Cargando...

Olá Lars,

Obrigado pela sua resposta. Atualmente estou em um sistema de desenvolvimento e, portanto, não tenho grandes conjuntos de dados para trabalhar/testar minhas teorias, e não estava certo de como o otimizador considera as estatísticas das tabelas ao gerar seu plano de execução.

No entanto, sua resposta me inspirou e decidi gerar alguns dados de teste. 30 minutos depois, tenho uma tabela FACT com 5 milhões de linhas e uma tabela DIM com 1.000 linhas.

Aliás, estou executando a revisão 82 (bem antiga, eu sei!).

De qualquer forma, meus achados coincidem com os seus de que definitivamente há um custo adicional ao filtrar na tabela DIM e uni-la com a tabela FACT, já que o filtro é aplicado primeiro em ambas as tabelas antes da união. Suponho que a vantagem da tabela de armazenamento de colunas é que esse tipo de filtro é muito rápido mesmo na ausência de índices secundários!


select
     *
from
     fact
where
     fact.prod_id not in (9, 99, 999)
NOME_DO_OPERADOR DETALHES_DO_OPERADOR

vs


select
     *
from
     fact inner join dim on
          fact.prod_id = dim.prod_id
where
     dim.prod_id not in (9, 99, 999)
NOME_DO_OPERADOR DETALHES_DO_OPERADOR

Da mesma forma que com suas descobertas, observo o mesmo comportamento, seja usando o motor de COLUNA ou OLAP, com o desempenho do motor OLAP aumentando significativamente com a agregação crescente (naturalmente).

E sim, definitivamente estamos usando a união em estrela em nossos cenários de modelagem. Esta questão era mais direcionada a unir tabelas transacionais juntas (apenas usei a etiqueta de fact/dim por simplicidade).

Obrigado novamente,

Chris.

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
0
Cargando...

Tudo bem, esta é uma daquelas perguntas.

Elas parecem ser bastante simples e fáceis de responder, mas a realidade é bem diferente.

Uma primeira resposta poderia ter sido (e considerei brevemente): "Por que você não tenta fazer isso?".

E mesmo que eu não concorde com isso, recomendo fortemente que você faça isso de qualquer maneira.

Use seus dados, sua instância SAP HANA executando sua revisão atual e veja o que você obtém.

O SAP HANA não apenas recebe uma tonelada de novos recursos em cada nova SPS ( apareceu ontem), mas também muitas das suas funcionalidades internas são refeitas, alteradas, melhoradas, corrigidas, estendidas... feitas melhores.

Para resumir: não existe O SAP HANA.

Portanto, certifique-se de verificar o que funciona como na revisão relevante para você.

Agora, vamos à pergunta em questão.

Se eu reformular, o que você está perguntando é: aplicar uma restrição transitiva em uma junção afeta o desempenho?

E no cenário que você apresentou (junção interna simples, sem agregação), a resposta deve ser: SIM, certamente afeta.

Por quê? Porque você está pedindo especificamente ao banco de dados para avaliar o filtro E executar a junção (que conta como outro filtro aqui).

Hora da demonstração!


select  f.dim10, f.dim100, f.dim1000, f.dim1000000, f.kf1, f.kf2
from 
    fact f inner join dim10 d10
    on f.dim10 = d10.id
where 
    dim10 not in (3, 4, 7);   

Declaração 'select f.dim10, f.dim100, f.dim1000, f.dim1000000, f.kf1, f.kf2 from fact f inner join dim10 d10 on ...' 
executada com sucesso em 995 ms 673 µs  (tempo de processamento do servidor: 576 ms 848 µs)
executada com sucesso em 757 ms 531 µs  (tempo de processamento do servidor: 378 ms 439 µs)
executada com sucesso em 1.090 segundos  (tempo de processamento do servidor: 366 ms 501 µs)

Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019

contacto@primeinstitute.com

(+51) 1641 9379
(+57) 1489 6964

© 2024 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

¡Hola! Soy Diana, asesora académica de Prime Institute, indícame en que curso estas interesado, saludos!
Hola ¿Puedo ayudarte?
NOME_DO_OPERADOR DETALHES_DO_OPERADOR MOTOR_DE_EXECUÇÃO NOME_DA_TABELA TAMANHO_DA_TABELA TAMANHO_DE_SAÍDA CUSTO_DA_SUBÁRVORE
BUSCA DE COLUNA F.DIM10, F.DIM100, F.DIM1000, F.DIM1000000, F.KF1, F.KF2 (MATERIALIZAÇÃO TARDIA,