web-dev-qa-db-ja.com

SSISの結合変換とルックアップ変換の違いは何ですか？

こんにちはSSISパッケージは初めてで、パッケージを書いて、同時にそれらについて読んでいます。

DTS=をSSISパッケージに変換する必要があり、異なるデータベースからの2つのソースで結合を実行する必要があります。

表面上は非常によく似ています。 「結合」ではデータを事前にソートする必要がありますが、「ルックアップ」ではこれを必要としません。アドバイスは非常に役立ちます。ありがとうございました。

sql-serverssis
34
saj

スクリーンショット＃1は、Merge Join transformationとLookup transformationを区別するためのいくつかのポイントを示しています。

ルックアップについて：

ソース1入力に基づいてソース2で一致する行を検索する場合、およびすべての入力行に対して1つだけ一致することがわかっている場合は、ルックアップ操作を使用することをお勧めします。たとえば、OrderDetailsテーブルで、一致するOrder IdとCustomer Numberを検索する場合、Lookupの方が適切なオプションです。

マージ結合について：

Addressテーブル内の特定の顧客のCustomerテーブルからすべての住所（自宅、職場、その他）を取得するなどの結合を実行する場合、顧客は結合結合を使用する必要があります。 1つ以上のアドレスを関連付けることができます。

比較する例：

Merge JoinとLookupのパフォーマンスの違いを示すシナリオを次に示します。ここで使用されるデータは、1対1の結合です。これは、比較する共通のシナリオです。

  1. dbo.ItemPriceInfo、dbo.ItemDiscountInfo、dbo.ItemAmountという名前の3つのテーブルがあります。これらのテーブルの作成スクリプトは、SQLスクリプトセクションで提供されます。

  2. Tablesdbo.ItemPriceInfoとdbo.ItemDiscountInfoの両方に13,349,729行があります。両方のテーブルには、共通列としてItemNumberがあります。 ItemPriceInfoには価格情報があり、ItemDiscountInfoには割引情報があります。スクリーンショット＃2は、これらの各テーブルの行数を示しています。スクリーンショット＃3は、テーブルに存在するデータについてのアイデアを提供するために、上位6行を示しています。

  3. マージ結合とルックアップ変換のパフォーマンスを比較するために、2つのSSISパッケージを作成しました。両方のパッケージは、テーブルdbo.ItemPriceInfoおよびdbo.ItemDiscountInfoから情報を取得し、合計金額を計算して、テーブルdbo.ItemAmountに保存する必要があります。

  4. 最初のパッケージはMerge Join変換を使用し、内部ではINNER JOINを使用してデータを結合しました。スクリーンショット＃4および＃5はサンプルパッケージの実行と実行を示しています期間。 05分14秒かかりました719ミリ秒で、マージ結合変換ベースのパッケージを実行します。

  5. 2番目のパッケージは、フルキャッシュを使用したLookup変換を使用しました（これはデフォルト設定です）。 creenshots＃6および＃7はサンプルパッケージの実行と実行を示します期間。 11分03秒かかりました610ミリ秒で、ルックアップ変換ベースのパッケージを実行します。次の警告メッセージが表示される場合があります。情報：The buffer manager has allocated nnnnn bytes, even though the memory pressure has been detected and repeated attempts to swap buffers have failed.ここに link があります。これは、ルックアップキャッシュの計算方法について説明しています。サイズ。このパッケージの実行中、データフロータスクがより速く完了したにもかかわらず、パイプラインのクリーンアップには多くの時間がかかりました。

  6. このdoes n'tは、参照変換が悪いことを意味します。それは賢明に使用する必要があるということです。私は自分のプロジェクトで非常に頻繁にそれを使用していますが、繰り返しますが、毎日の検索で1,000万行以上を処理していません。通常、私のジョブは200万から300万行を処理します。そのため、パフォーマンスは本当に優れています。最大1,000万行、どちらも同様に良好に機能しました。私が気づいたほとんどの場合、ボトルネックは変換ではなく宛先コンポーネントであることがわかりました。複数の宛先を設定することで、これを克服できます。 Here は、複数の宛先の実装を示す例です。

  7. スクリーンショット＃8は、3つのテーブルすべてのレコード数を示しています。スクリーンショット＃9は、各テーブルの上位6レコードを示しています。

お役に立てば幸いです。

SQLスクリプト：

CREATE TABLE [dbo].[ItemAmount](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
    [CalculatedAmount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemAmount] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemDiscountInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Discount] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemDiscountInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ItemPriceInfo](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [ItemNumber] [nvarchar](30) NOT NULL,
    [Price] [numeric](18, 2) NOT NULL,
CONSTRAINT [PK_ItemPriceInfo] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO

スクリーンショット＃1：

1

スクリーンショット＃2：

2

スクリーンショット＃3：

3

スクリーンショット＃4：

4

スクリーンショット＃5：

5

スクリーンショット＃6：

6

スクリーンショット＃7：

7

スクリーンショット＃8：

8

スクリーンショット＃9：

9

81
user756519

結合結合は、SQLでJOINが機能する方法と同様の結果を生成するように設計されています。 Lookupコンポーネントは、SQL JOINのようには機能しません。結果が異なる場合の例を次に示します。

入力1（請求書など）と入力2（請求書明細など）の間に1対多の関係がある場合、これら2つの入力の結合の結果に1つの請求書の1つ以上の行を含める必要があります。 。

結合結合を使用すると、目的の出力が得られます。入力2がルックアップソースであるルックアップでは、入力2に存在する行数に関係なく、出力は請求書ごとに1行になります。データが入力2からどの行に来るか思い出せませんが、少なくとも、重複データの警告が表示されることを確認してください。

そのため、各コンポーネントにはSSISでの独自の役割があります。

9
bobs

検討すべき3番目の代替案を提案します。あなたのOLE DBSourceはテーブルではなくクエリを含むことができ、そこで結合を行うことができます。これはすべての状況で良いわけではありません。 。

4
HLGEM

2つの違いがあります。

  1. 並べ替え：

    • マージ結合では、同じ方法でboth入力をソートする必要があります
    • ルックアップでは、どちらの入力もソートする必要はありません。

  2. データベースクエリの負荷：

    • マージ結合はデータベースを参照せず、2つの入力フローのみを参照します（ただし、参照データは通常、「select * from table order by join critera」の形式です）
    • ルックアップは、参加するように求められている各値（キャッシュされている場合は個別の値）に対して1つのクエリを発行します。これは、上記のselectよりも急速に高価になります。

これは、ソートされたリストを作成する労力がなく、約1％を超える行が必要な場合（単一の行を選択すると、ストリーミング時に同じ行のコストの約100倍になります）（ソートしたくない場合）メモリ内に1000万行のテーブル..）その後、マージ結合が進むべき方法です。

少数の一致（キャッシュが有効になっている場合に異なる値が検索された）のみが予想される場合は、ルックアップの方が優れています。

私にとって、この2つの間のトレードオフは、1万行から1万行の間で調べる必要があります。

より速いものは依存します

  • 処理される行の総数。 （テーブルがメモリに常駐している場合、マージするデータの種類は安価です）
  • 予想される重複したルックアップの数。 （ルックアップの行ごとのオーバーヘッドが高い）
  • ソートされたデータを選択できる場合（テキストのソートはコード照合の影響を受けるため、SQLでソートされていると見なされるものが、SSISでソートされていると見なされることに注意してください）
  • 検索するテーブル全体の割合。 （マージではすべての行を選択する必要がありますが、片側に数行しかない場合はルックアップの方が優れています）
  • 行の幅（ページごとの行は、単一のルックアップとスキャンのIOコストに大きく影響する可能性があります）（狭い行->マージの優先度）
  • ディスク上のデータの順序（ソートされた出力を生成しやすく、マージを優先します。物理ディスクの順序でルックアップを編成できる場合、キャッシュミスが少ないためルックアップのコストが低くなります）
  • ssisサーバーと宛先間のネットワーク遅延（遅延が大きい->マージを優先）
  • どれだけのコーディング努力を費やすか（マージは書くのが少し複雑です）
  • 入力データの照合-SSISマージは、英数字以外の文字を含むがnvarcharではないテキスト文字列の並べ替えに関するアイデアをひねります。 （これはソートに行き、sqlがssisがマージして満足できるソートを発行するのは難しいです）
2
Andrew Hill

ルックアップは、マージ結合コンポーネントの左結合に似ています。 Mergeは他の種類の結合を行うことができますが、これが望むのであれば、違いは主にパフォーマンスと利便性にあります。

ルックアップするデータの相対的な量（ルックアップコンポーネントへの入力）と参照されるデータの量（ルックアップキャッシュまたはルックアップデータソースのサイズ）によって、パフォーマンス特性は大きく異なります。

例えば。 10行のみを検索する必要があるが、参照されるデータセットが1,000万行である場合-部分キャッシュモードまたは非キャッシュモードを使用した検索は、1,000万行ではなく10レコードのみを取得するため、高速になります。 1000万行をルックアップする必要があり、参照されるデータセットが10行である場合、完全にキャッシュされたルックアップはおそらくより高速です（1000万行が既にソートされており、マージ結合を試すことができる場合を除く）。両方のデータセットが大きい場合（特に使用可能なRAMを超える場合）、または大きい方のデータセットが並べ替えられている場合、Mergeの方が適している可能性があります。

2
Michael Entin

これは古い質問ですが、与えられた答えでカバーされなかったと感じる重要な点の1つは、マージ結合が2つのデータフローをマージするため、任意のソースからのデータを結合できることです。一方、ルックアップでは、1つのデータソースをOLE DB。

1
Dave Sexton

結合の結合では、1つ以上の基準に基づいて複数の列に結合できますが、ルックアップは、一致する列情報に基づいて1つ以上の値のみを取得するという点でより制限されています-ルックアップクエリはそれぞれに対して実行されますデータソースの値（SSISは可能であればデータソースをキャッシュします）。

それは、2つのデータソースの内容と、マージ後の最終的なソースの表示方法に大きく依存します。 DTSパッケージのスキーマに関する詳細を教えてください。

考慮すべきもう1つのことは、パフォーマンスです。誤って使用すると、それぞれが他より遅くなる可能性がありますが、やはり、所有するデータの量とデータソーススキーマに依存します。

1
Cᴏʀʏ