Uso di un database di staging in Parallel Data Warehouse (PDW)

SQL Server Parallel Data Warehouse (PDW) usa un database di staging per archiviare temporaneamente i dati durante il processo di caricamento. Per impostazione predefinita, SQL Server PDW usa il database di destinazione come database di staging, che può causare la frammentazione della tabella. Per ridurre la frammentazione della tabella, è possibile creare un database di staging definito dall'utente. In alternativa, quando il rollback in caso di errore di caricamento non è un problema, è possibile utilizzare la modalità di caricamento fastappend per migliorare le prestazioni, ignorando la tabella temporanea e caricando direttamente nella tabella di destinazione.

Nozioni di base sul database di staging

Un database di staging è un database PDW creato dall'utente che archivia temporaneamente i dati durante il caricamento nell'appliance. Quando un database di staging viene specificato per un carico, il dispositivo copia inizialmente i dati nel database di staging, per poi trasferirli dalle tabelle temporanee nel database di staging a tabelle permanenti nel database di destinazione.

Quando un database di staging non viene specificato per un carico, Analytics Platform System (PDW) crea le tabelle temporanee nel database di destinazione e le usa per archiviare i dati caricati prima di inserire i dati caricati nelle tabelle di destinazione permanenti.

Quando un carico usa la modalità fastappend, Analytics Platform System (PDW) ignora completamente l'uso di tabelle temporanee e accoda i dati direttamente alla tabella di destinazione. La modalità fastappend migliora le prestazioni di caricamento per gli scenari ELT in cui i dati vengono caricati in una tabella che rappresenta una tabella temporanea dal punto di vista dell'applicazione. Ad esempio, un processo ELT potrebbe caricare i dati in una tabella temporanea, elaborare i dati tramite pulizia e deduplicazione e quindi inserire i dati nella tabella dei fatti di destinazione. In questo caso, non è necessario prima che PDW carichi i dati in una tabella temporanea interna prima di inserire i dati nella tabella temporanea dell'applicazione. La modalità fastappend evita il passaggio di caricamento aggiuntivo, migliorando significativamente le prestazioni di caricamento. Per usare la modalità fastappend, è necessario abilitare la modalità multi-transazione, il che significa che il ripristino da un caricamento fallito o interrotto deve essere gestito dal proprio processo di caricamento.

Vantaggi del database di staging

Il vantaggio principale di un database di staging consiste nel ridurre la frammentazione delle tabelle. Se non viene usato un database di staging, i dati vengono caricati in tabelle temporanee nel database di destinazione. Quando le tabelle temporanee vengono create ed eliminate nel database di destinazione, le pagine per le tabelle temporanee e quelle permanenti vengono intercalate. Nel corso del tempo, la frammentazione delle tabelle si verifica e peggiora le prestazioni. Al contrario, un database di staging garantisce che le tabelle temporanee vengano create e eliminate in uno spazio file separato rispetto alle tabelle permanenti.

Strutture delle tabelle del database di staging

La struttura di archiviazione per ogni tabella di database dipende dalla tabella di destinazione.

• Per i caricamenti in un heap o un indice columnstore cluster, la tabella di staging è un heap.

• Per i caricamenti in un indice clusterizzato rowstore, la tabella di staging è un indice clusterizzato rowstore.

Permissions

Richiede l'autorizzazione CREATE (per la creazione di una tabella temporanea) nel database di staging.

Procedure consigliate per la creazione di un database di staging

1. Dovrebbe essere presente un solo database di staging per appliance. Il database di staging può essere condiviso da tutti i processi di caricamento per tutti i database di destinazione.

2. Le dimensioni del database di staging sono specifiche del cliente. Inizialmente, quando si popola l'appliance, il database di staging deve essere sufficientemente grande per supportare i processi di caricamento iniziali. Questi processi di caricamento tendono a essere di grandi dimensioni perché più carichi possono verificarsi simultaneamente. Dopo il completamento dei processi di caricamento iniziali e il sistema è in produzione, è probabile che le dimensioni di ogni processo di carico siano inferiori. Quando i carichi sono di piccole dimensioni, è possibile ridurre le dimensioni del database di staging per supportare le dimensioni di carico più piccole. Per ridurre le dimensioni, è possibile eliminare il database di staging e crearlo di nuovo con allocazioni di dimensioni inferiori oppure usare l'istruzione ALTER DATABASE .

   Quando si crea il database di staging, usare le linee guida seguenti.

   • Le dimensioni della tabella replicate devono essere le dimensioni stimate, per nodo di calcolo, di tutte le tabelle replicate che verranno caricate contemporaneamente. Le dimensioni sono in genere di 25-30 GB.

   • Le dimensioni della tabella distribuita devono essere le dimensioni stimate, per appliance, di tutte le tabelle distribuite che verranno caricate contemporaneamente.

   • Le dimensioni del log sono in genere simili alle dimensioni della tabella replicata.

Examples

A. Creare un database di staging

Nell'esempio seguente viene creato un database di staging, Stagedb, da usare con tutti i carichi nell'appliance. Si supponga di stimare che cinque tabelle replicate di dimensioni pari a 5 GB verranno caricate contemporaneamente. Questa concorrenza comporta l'allocazione di almeno 25 GB per la dimensione replicata. Si supponga di stimare che sei tabelle distribuite di dimensioni pari a 100, 200, 400, 500, 500 e 550 GB verranno caricate contemporaneamente. Questa concorrenza comporta l'allocazione di almeno 2250 GB per le dimensioni della tabella distribuita.

CREATE DATABASE Stagedb  
WITH (  
  
    AUTOGROW = ON,  
  
    REPLICATED_SIZE = 25 GB,  
  
    DISTRIBUTED_SIZE = 2250 GB,  
  
    LOG_SIZE = 25 GB  
  
);