Verwenden einer Stagingdatenbank in Parallel Data Warehouse (PDW)

SQL Server Parallel Data Warehouse (PDW) verwendet eine Stagingdatenbank, um Daten während des Ladevorgangs vorübergehend zu speichern. Standardmäßig verwendet SQL Server PDW die Zieldatenbank als Stagingdatenbank, was zu einer Tabellenfragmentierung führen kann. Um die Tabellenfragmentierung zu verringern, können Sie eine benutzerdefinierte Stagingdatenbank erstellen. Oder wenn ein Rollback von einem Ladefehler kein Problem darstellt, können Sie den Fastappend-Lademodus verwenden, um die Leistung zu verbessern, indem Sie die temporäre Tabelle überspringen und direkt in die Zieltabelle laden.

Grundlagen der Stagingdatenbank

Eine Stagingdatenbank ist eine vom Benutzer erstellte PDW-Datenbank, die Daten vorübergehend speichert, während sie in die Anwendung geladen wird. Wenn eine Stagingdatenbank für eine Last angegeben wird, kopiert die Anwendung zuerst die Daten in die Stagingdatenbank und kopiert dann die Daten aus temporären Tabellen in der Stagingdatenbank in permanente Tabellen in der Zieldatenbank.

Wenn eine Stagingdatenbank für eine Last nicht angegeben wird, erstellt Analytics Platform System (PDW) die temporären Tabellen in der Zieldatenbank und verwendet sie, um die geladenen Daten zu speichern, bevor sie die geladenen Daten in die permanenten Zieltabellen einfügt.

Wenn eine Last den Fastappend-Modus verwendet, überspringt Analytics Platform System (PDW) die Verwendung temporärer Tabellen vollständig und fügt die Daten direkt an die Zieltabelle an. Der Fastappend-Modus verbessert die Ladeleistung für ELT-Szenarien, in denen Daten in eine Tabelle geladen werden, bei der es sich um eine temporäre Tabelle aus der Anwendungssicht handelt. Beispielsweise könnte ein ELT-Prozess Daten in eine temporäre Tabelle laden, die Daten durch sauber sing und Entdüngung verarbeiten und dann die Daten in die Ziel-Faktentabelle einfügen. In diesem Fall ist es nicht erforderlich, dass PDW zuerst die Daten in eine interne temporäre Tabelle lädt, bevor die Daten in die temporäre Tabelle der Anwendung eingefügt werden. Der Fastappend-Modus vermeidet den zusätzlichen Ladeschritt, wodurch die Ladeleistung erheblich verbessert wird. Um den Fastappend-Modus zu verwenden, müssen Sie den Multitransaktionsmodus verwenden. Dies bedeutet, dass die Wiederherstellung von einer fehlgeschlagenen oder abgebrochenen Last von Ihrem eigenen Ladevorgang verarbeitet werden muss.

Vorteile der Stagingdatenbank

Der Hauptvorteil einer Stagingdatenbank besteht darin, die Tabellenfragmentierung zu reduzieren. Wenn keine Stagingdatenbank verwendet wird, werden die Daten in temporäre Tabellen in der Zieldatenbank geladen. Wenn temporäre Tabellen in der Zieldatenbank erstellt und abgelegt werden, werden die Seiten für die temporären Tabellen und permanente Tabellen interleaviert. Im Laufe der Zeit tritt die Tabellenfragmentierung auf und beeinträchtigt die Leistung. Im Gegensatz dazu stellt eine Stagingdatenbank sicher, dass temporäre Tabellen in einem separaten Dateibereich erstellt und abgelegt werden als die permanenten Tabellen.

Staging von Datenbanktabellenstrukturen

Die Speicherstruktur für jede Datenbanktabelle hängt von der Zieltabelle ab.

• Bei Lasten in einen Heap- oder gruppierten Columnstore-Index ist die Stagingtabelle ein Heap.

• Bei Laden in einen gruppierten Rowstore-Index ist die Stagingtabelle ein gruppierter Rowstore-Index.

Berechtigungen

Erfordert CREATE-Berechtigung (zum Erstellen einer temporären Tabelle) in der Stagingdatenbank.

Bewährte Methoden zum Erstellen einer Stagingdatenbank

1. Pro Anwendung sollte nur eine Stagingdatenbank vorhanden sein. Die Stagingdatenbank kann von allen Ladeaufträgen für alle Zieldatenbanken freigegeben werden.

2. Die Größe der Stagingdatenbank ist kundenspezifisch. Beim ersten Auffüllen des Anwendung sollte die Stagingdatenbank groß genug sein, um die anfänglichen Ladeaufträge aufzunehmen. Diese Ladeaufträge sind tendenziell groß, da mehrere Lasten gleichzeitig auftreten können. Nachdem die anfänglichen Ladeaufträge abgeschlossen wurden und das System in der Produktion ist, ist die Größe jedes Lastauftrags wahrscheinlich kleiner. Wenn Ladevorgänge klein sind, können Sie die Größe der Stagingdatenbank verringern, um die kleineren Ladegrößen zu berücksichtigen. Um die Größe zu verringern, können Sie die Stagingdatenbank ablegen und erneut mit kleineren Größenzuweisungen erstellen, oder Sie können die ALTER DATABASE-Anweisung verwenden.

   Verwenden Sie beim Erstellen der Stagingdatenbank die folgenden Richtlinien.

   • Die replizierte Tabellengröße sollte die geschätzte Größe pro Computeknoten aller replizierten Tabellen sein, die gleichzeitig geladen werden. Die Größe beträgt in der Regel 25-30 GB.

   • Die Größe der verteilten Tabelle sollte die geschätzte Größe pro Anwendung aller verteilten Tabellen sein, die gleichzeitig geladen werden.

   • Die Protokollgröße ähnelt normalerweise der replizierten Tabellengröße.

Beispiele

.A Erstellen einer Stagingdatenbank

Im folgenden Beispiel wird eine Stagingdatenbank , Stagedb, für die Verwendung mit allen Lasten für die Anwendung erstellt. Angenommen, Sie schätzen, dass fünf replizierte Tabellen mit einer Größe von 5 GB gleichzeitig geladen werden. Diese Parallelität führt zu einer Zuordnung von mindestens 25 GB für die replizierte Größe. Angenommen, Sie schätzen, dass sechs verteilte Tabellen mit größen 100, 200, 400, 500, 500 und 550 GB gleichzeitig geladen werden. Diese Parallelität führt zu einer Zuordnung von mindestens 2250 GB für die Größe der verteilten Tabelle.

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