Prime Institute
¡Caminando hacia el éxito!

Aprende en Comunidad

Avalados por :

¡Acceso SAP S/4HANA desde $100!

Acceso a SAP

¿Es más eficiente usar NOT IN en una tabla de dimensiones antes de unir con la tabla de hechos o aplicarlo directamente en la tabla de hechos?

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

Supongamos que tengo dos tablas de almacenamiento de columnas: una tabla de hechos grande (FACT) con, digamos, 10 millones de filas, y una tabla de dimensiones (DIM) con 1,000 filas. Las dos tablas se unen en alguna clave arbitraria, digamos PRODUCT_ID.

¿Qué consulta tendría un mejor rendimiento? 


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

o 


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

En otras palabras, ¿es más rápido realizar la cláusula NOT IN en la pequeña tabla de dimensiones y luego unirse a la gran tabla de hechos, o simplemente realizar la cláusula NOT IN directamente en la gran tabla de hechos? ¿O no hay diferencia? Supongamos que no se han agregado índices secundarios a las tablas aparte de las claves primarias, donde PRODUCT_ID es la clave primaria de la tabla DIM y PRODUCT_ID es parte de una clave primaria compuesta de la tabla FACT.

Además, ¿cambia la situación si digamos que nuestra tabla FACT ya no es una tabla, sino una vista de cálculo que une varias tablas de transacciones para crear una vista de hechos antes de ser utilizada en los escenarios anteriores?

Saludos,

Chris.

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

2 Respuestas

0
Cargando...

Hola Lars,

Gracias por tu respuesta. Actualmente estoy en un sistema de desarrollo y, por lo tanto, no tengo conjuntos de datos grandes para trabajar / probar mis teorías, y no estaba seguro de cómo el optimizador considera las estadísticas de las tablas al generar su plan de ejecución.

Sin embargo, tu respuesta me inspiró y decidí generar algunos datos de prueba. 30 minutos más tarde, tengo una tabla FACT de 5 millones de filas y una tabla DIM de 1,000 filas.

Por cierto, estoy ejecutando la revisión 82 (¡muy antigua, lo sé!).

En cualquier caso, mis hallazgos coinciden con los tuyos en que definitivamente hay un sobrecosto al filtrar en la tabla DIM y unirla a la tabla FACT, ya que el filtro se aplica primero a ambas tablas antes de la unión. ¡Supongo que lo bueno de la tabla de almacenamiento de columnas es que este tipo de filtros son muy rápidos incluso en ausencia de índices secundarios! 


select
     *
from
     fact
where
     fact.prod_id not in (9, 99, 999)
NOMBRE_DEL_OPERADOR DETALLES_DEL_OPERADOR

vs 


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

Del mismo modo que con tus hallazgos, observo el mismo comportamiento ya sea que se utilice el motor de COLUMN o OLAP, con el rendimiento del motor OLAP aumentando significativamente con la agregación creciente (naturalmente).

Y sí, definitivamente estamos haciendo uso de la unión en estrella en nuestros escenarios de modelado. Esta pregunta estaba más dirigida a unir tablas transaccionales juntas (solo usé la etiqueta de fact / dim por simplicidad).

Gracias de nuevo,

Chris.

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

Alright, this is one of "those" questions.

They look fairly straight forward and should be simple to answer, but the reality is quite different.

A first reply could have been (and I considered this briefly): "Why don't you just go and try it out?".

And even as I don't go with this one, I highly recommend to do it anyhow.

Use your data, your SAP HANA instance running your current revision and see what you get.

SAP HANA does not only get a ton of new features in every new SPS ( appeared just yesterday), but also a lot of how it works internally is re-done, changed, improved, fixed, extended... made better.

To cut the blabber short: there is no THE SAP HANA.

So, make sure to check what works how in the revision relevant for you.

Now to the question at hand.

If I reformulate it then what you as is: does applying a transitive constraint across a join cost performance?

And in the scenario you presented (plain inner, join, no aggregation) the answer must be: YES, it sure does.

Why? Because you specifically ask the database to evaluate the filter AND to execute the join (which counts as another filter here).

Demo time! 


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);   

Statement 'select f.dim10, f.dim100, f.dim1000, f.dim1000000, f.kf1, f.kf2 from fact f inner join dim10 d10 on ...' 
successfully executed in 995 ms 673 µs  (server processing time: 576 ms 848 µs)
successfully executed in 757 ms 531 µs  (server processing time: 378 ms 439 µs)
successfully executed in 1.090 seconds  (server processing time: 366 ms 501 µs)
OPERATOR_NAME OPERATOR_DETAILS EXECUTION_ENGINE TABLE_NAME TABLE_SIZE OUTPUT_SIZE SUBTREE_COST
COLUMN SEARCH F.DIM10, F.DIM100, F.DIM1000, F.DIM1000000, F.KF1, F.KF2 (LATE MATERIALIZATION,
Respondido el 15/04/2024
LUCIANO RIOJA GHIOTTO
Se unió el 13/07/2019
Agregar

Partners:

contacto@primeinstitute.com

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

© 2026 Copyright. Todos los derechos reservados.

Desarrollado por Prime Institute

Hola ¿Puedo ayudarte?