Utilisation d’une base de données intermédiaire dans Parallel Data Warehouse (PDW)

SQL Server Parallel Data Warehouse (PDW) utilise une base de données intermédiaire pour stocker temporairement les données pendant le processus de chargement. Par défaut, SQL Server PDW utilise la base de données de destination comme base de données intermédiaire, ce qui peut entraîner la fragmentation des tables. Pour réduire la fragmentation des tables, vous pouvez créer une base de données intermédiaire définie par l’utilisateur. Ou, lorsque la restauration après un échec de chargement n'est pas préoccupante, vous pouvez utiliser le mode de chargement fastappend pour améliorer les performances en ignorant la table temporaire et en chargeant directement dans la table de destination.

Principes de base de la base de données intermédiaire

Une base de données intermédiaire est une base de données PDW créée par l’utilisateur qui stocke temporairement les données pendant son chargement dans l’appliance. Lorsqu’une base de données intermédiaire est spécifiée pour une charge, l’appliance copie d’abord les données dans la base de données intermédiaire, puis copie les données des tables temporaires de la base de données intermédiaire vers des tables permanentes dans la base de données de destination.

Lorsqu’une base de données intermédiaire n’est pas spécifiée pour une charge, Analytics Platform System (PDW) crée les tables temporaires dans la base de données de destination et les utilise pour stocker les données chargées avant d’insérer les données chargées dans les tables de destination permanentes.

Lorsqu’une charge utilise le mode fastappend, Analytics Platform System (PDW) ignore complètement l’utilisation de tables temporaires et ajoute les données directement à la table cible. Le mode fastappend améliore les performances de chargement pour les scénarios ELT où les données sont chargées dans une table qui est une table temporaire du point de vue de l’application. Par exemple, un processus ELT peut charger des données dans une table temporaire, traiter les données en les nettoyant et en les dé-dédoublonnant, puis insérer les données dans la table de faits cible. Dans ce cas, il n’est pas nécessaire que PDW charge d’abord les données dans une table temporaire interne avant d’insérer les données dans la table temporaire de l’application. Le mode fastappend évite l’étape de charge supplémentaire, ce qui améliore considérablement les performances de charge. Pour utiliser le mode fastappend, vous devez utiliser le mode multi-transaction, ce qui signifie que la récupération à partir d’une charge ayant échoué ou abandonnée doit être gérée par votre propre processus de chargement.

Avantages de la base de données intermédiaire

L’avantage principal d’une base de données intermédiaire est de réduire la fragmentation des tables. Si une base de données intermédiaire n’est pas utilisée, les données sont chargées dans des tables temporaires dans la base de données de destination. Lorsque les tables temporaires sont créées et supprimées dans la base de données de destination, les pages des tables temporaires et les tables permanentes deviennent entrelacées. Au fil du temps, la fragmentation des tables se produit et dégrade les performances. En revanche, une base de données intermédiaire garantit que les tables temporaires sont créées et supprimées dans un espace de fichier distinct que les tables permanentes.

Structures de table de base de données intermédiaires

La structure de stockage de chaque table de base de données dépend de la table de destination.

• Pour les chargements dans un tas ou un index columnstore en cluster, la table intermédiaire est un tas.

• Pour les chargements dans un index clusterisé rowstore, la table intermédiaire est un index clusterisé rowstore.

Permissions

Requiert l'autorisation CREATE (pour créer une table temporaire) sur la base de données de la zone de transit.

Meilleures pratiques pour la création d’une base de données intermédiaire

1. Il ne doit y avoir qu’une base de données intermédiaire par appliance. La base de données intermédiaire peut être partagée par tous les travaux de chargement pour toutes les bases de données de destination.

2. La taille de la base de données intermédiaire est personnalisée pour chaque client. Initialement, lors du premier remplissage de l’appliance, la base de données intermédiaire doit être suffisamment grande pour prendre en charge les travaux de charge initiaux. Ces travaux de charge ont tendance à être volumineux, car plusieurs charges peuvent se produire simultanément. Une fois les travaux de chargement initiaux terminés et que le système est en production, la taille de chaque travail de charge est susceptible d’être plus petite. Lorsque les charges sont petites, vous pouvez réduire la taille de la base de données intermédiaire pour prendre en charge les tailles de charge plus petites. Pour réduire la taille, vous pouvez supprimer la base de données intermédiaire et la recréer avec des allocations de taille plus petites, ou vous pouvez utiliser l’instruction ALTER DATABASE .

   Lors de la création de la base de données intermédiaire, utilisez les instructions suivantes.

   • La taille de table répliquée doit être la taille estimée, par nœud de calcul, de toutes les tables répliquées qui seront chargées simultanément. La taille est généralement de 25 à 30 Go.

   • La taille de la table distribuée doit être la taille estimée, par appliance, de toutes les tables distribuées qui seront chargées simultanément.

   • La taille du journal est généralement similaire à la taille de la table répliquée.

Examples

A. Créer une base de données intermédiaire

L’exemple suivant crée une base de données intermédiaire, Stagedb, à utiliser avec toutes les charges sur l’appliance. Supposons que cinq tables répliquées de taille 5 Go soient chargées simultanément. Cette concurrence entraîne l’allocation d’au moins 25 Go pour la taille répliquée. Supposons que six tables distribuées de tailles 100, 200, 400, 500, 500, 500 et 550 Go se chargent simultanément. Cette concurrence entraîne l’allocation d’au moins 2250 Go pour la taille du tableau distribué.

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