次の方法で共有


Parallel Data Warehouse (PDW) でのステージング データベースの使用

SQL Server Parallel Data Warehouse (PDW) は、ステージング データベースを使用して、読み込みプロセス中に一時的にデータを格納します。 既定では、SQL Server PDW はステージング データベースとして変換先データベースを使用します。これにより、テーブルの断片化が発生する可能性があります。 テーブルの断片化を減らすために、ユーザー定義のステージング データベースを作成できます。 または、読み込みエラーからのロールバックが問題でない場合は、fastappend 読み込みモードを使用して、一時テーブルをスキップして変換先テーブルに直接読み込むことで、パフォーマンスを向上させることができます。

ステージング データベースの基本

ステージング データベースは、アプライアンスに読み込まれる間にデータを一時的に格納する、ユーザーが作成した PDW データベースです。 読み込みにステージング データベースを指定すると、アプライアンスは最初にデータをステージング データベースにコピーしてから、ステージング データベースの一時テーブルから変換先データベースの永続テーブルにデータをコピーします。

ステージング データベースが読み込みに対して指定されていない場合、分析プラットフォーム システム (PDW) は、変換先データベースに一時テーブルを作成し、それらを使用して読み込まれたデータを格納してから、読み込まれたデータを永続的な変換先テーブルに挿入します。

読み込みで fastappend モード を使用すると、分析プラットフォーム システム (PDW) は一時テーブルの使用を完全にスキップし、データをターゲット テーブルに直接追加します。 fastappend モードでは、アプリケーションの観点から一時テーブルであるテーブルにデータが読み込まれる ELT シナリオの読み込みパフォーマンスが向上します。 例えば、ELT プロセスでは、データを一時テーブルに読み込み、クレンジングと重複除去によってデータを処理し、ターゲット ファクト テーブルにデータを挿入できます。 この場合、PDW は、アプリケーションの一時テーブルにデータを挿入する前に、まず内部一時テーブルにデータを読み込む必要はありません。 fastappend モードでは、追加の読み込みステップが回避され、読み込みパフォーマンスが大幅に向上します。 fastappend モードを使用するには、マルチトランザクション モードを使用する必要があります。つまり、読み込みを失敗または中止してからの復旧は、独自の読み込みプロセスで処理する必要があります。

ステージング データベースの利点

ステージング データベースの主な利点は、テーブルの断片化を減らすことです。 ステージング データベースを使用しない場合、データは変換先データベースの一時テーブルに読み込まれます。 一時テーブルが作成され、変換先データベースで削除されると、一時テーブルと永続テーブルのページがインターリーブされます。 時間の経過とともに、テーブルの断片化が発生し、パフォーマンスが低下します。 これに対し、ステージング データベースでは、永続テーブルとは別のファイル領域で一時テーブルが作成および削除されます。

ステージング データベース テーブルの構造

各データベース テーブルのストレージ構造は、変換先テーブルによって異なります。

  • ヒープまたはクラスター化列ストア インデックスへの読み込みの場合、ステージング テーブルはヒープです。

  • 行ストア クラスター化インデックスへの読み込みの場合、ステージング テーブルは行ストア クラスター化インデックスです。

アクセス許可

ステージング データベースに対する (一時テーブルを作成するための) CREATE 権限が必要です。

ステージング データベースを作成するためのベスト プラクティス

  1. アプライアンスごとにステージング データベースは 1 つだけ必要です。 ステージング データベースは、すべての変換先データベースのすべてのロードジョブで共有できます。

  2. ステージング データベースのサイズはお客様によって異なります。 最初にアプライアンスにデータを取り込むときに、ステージング データベースは初期ロードジョブに対応できる十分な大きさにする必要があります。 複数の読み込みが同時に発生する可能性があるため、これらのロードジョブは大きくなる傾向があります。 初期のロードジョブが完了し、システムが実稼働状態になると、各ロードジョブのサイズは小さくなる可能性があります。 読み込みが小さい場合は、ステージング データベースのサイズを小さくして、より小さなロードサイズに対応できます。 サイズを小さくするには、ステージング データベースを削除し、サイズの小さい割り当てを使用してもう一度作成するか、ALTER DATABASE ステートメントを使用できます。

    ステージング データベースを作成する場合は、次のガイドラインを使用します。

    • レプリケート テーブルのサイズは、同時に読み込まれるすべてのレプリケート テーブルの計算ノードあたりの推定サイズである必要があります。 サイズは、通常は 25-30 GB です。

    • 分散テーブルのサイズは、同時に読み込まれるすべての分散テーブルの、アプライアンスごとの推定サイズである必要があります。

    • ログ サイズは、通常、レプリケートされたテーブル のサイズに似ています。

A. ステージング データベースの作成

次の例では、ステージング データベース、Stagedb を作成し、アプライアンス上のすべての読み込みで使用します。 5 GB のサイズのレプリケートテーブルが 5 個ずつ同時に読み込まれるとします。 この同時実行により、レプリケートされたサイズに対して少なくとも 25 GB が割り当てられます。 サイズ 100、200、400、500、500、550 GB の 6 つの分散テーブルが同時に読み込まれるとします。 この同時実行により、分散テーブル サイズに少なくとも 2250 GB が割り当てられます。

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