none
Recuperar Claves Subrogadas en tablas de hechos RRS feed

  • Pregunta

  • Buenas, a ver si me podéis ayudar con un problema que tengo, gracias de antemano.

    Tengo una tabla de hechos con 3 millones de filas y 10 columnas. Estoy intentando seguir la estrategia de ponerle claves subrogadas, con lo cual en mi SSIS pongo de origen la tabla de hechos y voy haciendo lookups con las 9 dimensiones donde tengo generadas las sk con el fin de tener una tabla final con 9 campos con sk y un valor. El problema es que tengo un par de dimensiones bastante grandes, del orden de 600.000 registros y el proceso se ralentiza mucho.

    ¿Hay alguna forma de optimizar la carga? ¿Utilizar merges?

    Un saludo. Gracias.

    jueves, 2 de enero de 2014 15:48

Respuestas

  • Además de lo que te comenta Alberto, otra pregunta: ¿qué tipo de Lookup estás usando? 

    - Si usas Non caché, cada vez que llega una fila por el flujo hace una consulta contra la tabla de la dimensión. Para 3 millones de filas, son 3 millones de consultas X 9 dimensiones = 27 millones de consultas. Cuando sean dimensiones muy pequeñas te puede valer esta aproximación, pero 6 millones de consultas (los dos lookups) contra 600k filas sí puede penalizar muchísimo el rendimiento. 

    - Si usas Partial Caché sí subirás a memoria partes de la tabla o consulta que especifiques, pero aun no estarás moviendolo todo a memoria.

    - Con Full Caché si estarás leyéndolo todo y subiéndolo a memoria. Aquí, como dice Alberto, no debería de costarte mucho subir esas filas, a no ser que tengas mucha presión en RAM y te quedes sin memoria. En ese caso SSIS paginará a disco duro y sí podría ralentizarse muchísimo el proceso. 

    Las dos primeras opciones sólo se suelen usar para casos concretos en los que no dispones de RAM (caso raro en un entorno de producción) o en los que hay que modificar la consulta SQL que tira contra la dimensión para cada fila que llega. Si no tienes ninguna de estas necesidades (u otra que te fuerce a usarlas), sería recomendable que usases Full Cache, es probable que te funcione más rápido. 

    Usar Merges es otra opción, con la diferencia fundamental entre un Lookup y un Merge: El lookup coge solo una ocurrencia (la primera que encuentre en el set de datos de referencia) y un Merge es igual que un Join en T-SQL, puede devolver más de una coincidencia. En el caso de una carga de una tabla de hechos no se suelen usar Merges porque si duplicamos una fila duplicamos ese hecho (y probablemente las métricas asociadas).

    miércoles, 8 de enero de 2014 16:15

Todas las respuestas

  • Hola.

    ¿Qué campos pones en el lookup? Se supone que únicamente tienes que poner la clave, no toda la tabla de dimensión, y en esas condiciones, subir 600.000 registros a memoria no debe ser especialmente lento.



    Alberto López Grande
    SQL Server MVP
    Visita mi blog en http://qwalgrande.com
    Sígueme en twitter en http://twitter.com/qwalgrande

    jueves, 2 de enero de 2014 21:25
    Moderador
  • Además de lo que te comenta Alberto, otra pregunta: ¿qué tipo de Lookup estás usando? 

    - Si usas Non caché, cada vez que llega una fila por el flujo hace una consulta contra la tabla de la dimensión. Para 3 millones de filas, son 3 millones de consultas X 9 dimensiones = 27 millones de consultas. Cuando sean dimensiones muy pequeñas te puede valer esta aproximación, pero 6 millones de consultas (los dos lookups) contra 600k filas sí puede penalizar muchísimo el rendimiento. 

    - Si usas Partial Caché sí subirás a memoria partes de la tabla o consulta que especifiques, pero aun no estarás moviendolo todo a memoria.

    - Con Full Caché si estarás leyéndolo todo y subiéndolo a memoria. Aquí, como dice Alberto, no debería de costarte mucho subir esas filas, a no ser que tengas mucha presión en RAM y te quedes sin memoria. En ese caso SSIS paginará a disco duro y sí podría ralentizarse muchísimo el proceso. 

    Las dos primeras opciones sólo se suelen usar para casos concretos en los que no dispones de RAM (caso raro en un entorno de producción) o en los que hay que modificar la consulta SQL que tira contra la dimensión para cada fila que llega. Si no tienes ninguna de estas necesidades (u otra que te fuerce a usarlas), sería recomendable que usases Full Cache, es probable que te funcione más rápido. 

    Usar Merges es otra opción, con la diferencia fundamental entre un Lookup y un Merge: El lookup coge solo una ocurrencia (la primera que encuentre en el set de datos de referencia) y un Merge es igual que un Join en T-SQL, puede devolver más de una coincidencia. En el caso de una carga de una tabla de hechos no se suelen usar Merges porque si duplicamos una fila duplicamos ese hecho (y probablemente las métricas asociadas).

    miércoles, 8 de enero de 2014 16:15