Actualización de una gran dimensión replicada (SQL Server PDW)

Utilizamos un dispositivo SQL Server PDW para nuestro almacén de datos. Una de las tablas en nuestro almacén es una tabla replicada con aproximadamente 20 millones de filas. Como parte de nuestro proceso ETL, necesitamos expirar los registros antiguos de esta dimensión; sin embargo, estamos viendo que actualizar un puñado de registros (<100) lleva más de 1 hora en completarse. Esto es lo que me gustaría mejorar si puedo.

Naturalmente, una opción en la que pensé fue cambiar esta Dimensión de Replicada a Distribuida. Mi prueba muestra que solucionaría el problema con el proceso ETL que tarda mucho (de 1,5 horas a 30 segundos), pero todas las uniones contra la versión distribuida de esta dimensión se verían afectadas ya que las uniones casi nunca se basan en la misma distribución columna. Cuando miro el plan de ejecución de algunas de estas consultas, generalmente veo una operación ShuffleMove o BroadcastMove .

Entonces mi pregunta al gurú de PDW aquí es:

¿Hay algo más que se pueda hacer para mejorar el rendimiento de la actualización de registros en la versión replicada de esta Dimensión?

Una vez más, pasar a una tabla distribuida no parece ser la mejor solución, ya que afectará a cientos de consultas SQL ya escritas e informes desarrollados por otras personas.

Unas cuantas preguntas. 20 millones de filas no son necesariamente tan grandes.

¿Qué proceso está utilizando para realizar sus actualizaciones y eliminaciones en este momento?

¿Es la dimensión un ÍNDICE DE COLUMNISTA AGRUPADO, un ÍNDICE AGRUPADO o HEAP?

¿Está diciendo que hay movimiento mientras actualiza y elimina esta tabla o simplemente vio movimiento cuando cambió la tabla de replicada a distribuida?

Si es lo último, eso no es sorprendente. Es poco probable que sea compatible con la unión y agregación. Si está haciendo algo para activar el movimiento a través de su actualización / eliminación, podríamos analizarlo, aunque sería útil un ejemplo concreto.

En términos generales, comenzaría tratando de mantener el ETL simple.

Use CTAS contra la dimensión seleccionando solo las filas que desea mantener, la unión en cualquier fila nueva y use CASE para recoger cualquier cambio (convirtiendo la ACTUALIZACIÓN en una transformación dentro del CTAS). Una vez completado, puede usar un par de comandos RENAME OBJECT para cambiar de la tabla actual a la nueva tabla. Esto le brinda el beneficio adicional de tener una vista histórica de su mesa, que puede dejar a su gusto.

Ser replicado no te impide usar particiones. Divide tu mesa.

Luego, para las filas que necesita eliminar o actualizar, CTAS toda la partición en una nueva tabla, utilizando LEFT JOIN y COALESCE para obtener los valores apropiados (es decir, nuevos) para las actualizaciones de las filas modificadas mientras mantiene las filas que desea y excluye el los que no.

Finalmente, la partición cambia la nueva tabla con su antigua partición.

Y hecho :)

En mi experiencia, a PDW no le gustan las actualizaciones y eliminaciones. Los CTAS y los conmutadores de partición funcionan bien.

Las declaraciones de ACTUALIZACIÓN en PDW son solo parcialmente paralelas en lugar de ser completamente paralelas como CTAS.

Dicho esto, esto bien podría deberse a la indexación. ¿Cuál es el código real que estás ejecutando? ¿Tiene índices establecidos para ayudar a encontrar los registros que está caducando? Aún necesita aplicar algunas de las técnicas de ajuste estándar para aplicar índices no agrupados a las tablas del almacén de filas. El hecho de que PDW no admite claves primarias a menudo parece significar que las personas olvidan indexar su clave natural, así que no te encuentres en ese bote ...