Aggiornamento di una dimensione replicata di grandi dimensioni (SQL Server PDW)

Utilizziamo un dispositivo PDW di SQL Server per il nostro data warehouse. Una delle tabelle nel nostro magazzino è una tabella replicata con circa 20 milioni di righe. Come parte del nostro processo ETL, dobbiamo far scadere vecchi record da questa dimensione; tuttavia, stiamo vedendo che l'aggiornamento di una manciata di record (<100) richiede più di 1 ora per il completamento. Questo è ciò che vorrei migliorare se posso.

Naturalmente, un'opzione a cui ho pensato è stata quella di cambiare questa dimensione da replicata a distribuita. I miei test mostrano che risolverebbe il problema con il processo ETL che impiegherebbe molto tempo (da 1,5 ore a 30 secondi), ma tutti i join rispetto alla versione distribuita di questa dimensione sarebbero interessati poiché i join non sono quasi mai basati sulla stessa distribuzione colonna. Quando guardo il piano di esecuzione di alcune di queste query di solito vedo un'operazione ShuffleMove o BroadcastMove .

Quindi la mia domanda al guru del PDW è qui:

C'è qualcos'altro che può essere fatto per migliorare le prestazioni di aggiornamento dei record nella versione replicata di questa dimensione?

Ancora una volta, il passaggio a una tabella distribuita non sembra essere la soluzione migliore poiché influirà su centinaia di query e report SQL già scritti sviluppati da altre persone.

Alcune domande. 20 milioni di righe non sono necessariamente così grandi.

Quale processo stai utilizzando per eseguire gli aggiornamenti e le eliminazioni in questo momento?

La dimensione è un INDICE COLUMNSTORE CLUSTERATO, un INDICE CLUSTERATO o HEAP?

Stai dicendo che c'è movimento mentre aggiorni ed elimini questa tabella o hai appena visto movimento quando hai cambiato la tabella da replicata a distribuita?

Se è quest'ultimo che non è sorprendente. È improbabile che tu sia compatibile con join e aggregazione. Se stai facendo qualcosa per innescare il movimento attraverso il tuo aggiornamento / eliminazione, allora potremmo guardarlo - anche se un esempio concreto sarebbe utile.

In termini generali, vorrei iniziare cercando di mantenere semplice l'ETL.

Usa CTAS contro la dimensione selezionando solo le righe che vuoi mantenere, unisci in qualsiasi nuova riga e usa CASE per raccogliere eventuali modifiche (convertendo l'AGGIORNAMENTO in una trasformazione all'interno del CTAS). Una volta completato, puoi utilizzare una coppia di comandi RENAME OBJECT per passare dalla tabella corrente alla nuova tabella. Questo ti dà l'ulteriore vantaggio di avere una visione storica del tuo tavolo, che puoi lasciare a tuo piacimento.

Essere replicati non ti impedisce di usare il partizionamento. Partiziona il tuo tavolo.

Quindi, per le righe che è necessario eliminare o aggiornare, CTAS l'intera partizione in una nuova tabella, utilizzando LEFT JOIN e COALESCE per ottenere i valori appropriati (ovvero nuovi) per gli aggiornamenti dalle righe modificate mantenendo le righe desiderate ed escludendo quelli che non lo fai.

Infine, partizione cambia la nuova tabella con la tua vecchia partizione.

E fatto :)

Nella mia esperienza, a PDW non piacciono gli aggiornamenti e le eliminazioni. CTAS e switch di partizione funzionano bene.

Le istruzioni UPDATE in PDW sono solo parzialmente parallele piuttosto che completamente parallele come CTAS.

Detto questo, questo potrebbe essere dovuto all'indicizzazione. Qual è il codice effettivo che stai eseguendo? Hai degli indici in atto per aiutarti a trovare quei record che stai scadendo? È ancora necessario applicare alcune delle tecniche di ottimizzazione standard dell'applicazione di indici non cluster alle tabelle del file delle righe. Il fatto che PDW non supporti le chiavi primarie sembra spesso significare che le persone dimenticano di indicizzare la loro chiave naturale, quindi non trovarti in quella barca ...