web-dev-qa-db-fra.com

Quelles sont les différences entre les transformations Merge Join et Lookup dans SSIS?

Salut, je suis nouveau dans les packages SSIS et j'écris un package et je les lis en même temps.

J'ai besoin de convertir un DTS en un package SSIS et j'ai besoin d'effectuer une jointure sur deux sources de bases de données différentes et je me demandais quelle était la meilleure approche, pour utiliser une recherche ou une jointure de fusion?

En surface, ils semblent très similaires. La "Fusionner la jointure" nécessite que les données soient triées au préalable, tandis que la "Recherche" ne l'exige pas. Tout conseil serait très utile. Merci.

sql-serverssis
34
saj

La capture d'écran # 1 montre quelques points pour distinguer _ Merge Join transformation et Lookup transformation.

Concernant la recherche:

Si vous souhaitez trouver des lignes correspondant à la source 2 en fonction de l'entrée de la source 1 et si vous savez qu'il n'y aura qu'une seule correspondance pour chaque ligne d'entrée, je suggère d'utiliser l'opération de recherche. Un exemple serait votre table OrderDetails et vous voulez trouver la correspondance Order Id et Customer Number, alors la recherche est une meilleure option.

Concernant la jointure de fusion:

Si vous souhaitez effectuer des jointures comme extraire toutes les adresses (domicile, travail, autres) de la table Address pour un client donné dans la table Customer, vous devez utiliser Merge Join car le client peut avoir une ou plusieurs adresses associées.

Un exemple à comparer:

Voici un scénario pour illustrer les différences de performances entre Merge Join et Lookup. Les données utilisées ici sont une jointure un à un, qui est le seul scénario commun entre elles à comparer.

  1. J'ai trois tables nommées dbo.ItemPriceInfo, dbo.ItemDiscountInfo et dbo.ItemAmount. Les scripts de création de ces tables sont fournis dans la section des scripts SQL.

  2. Les tablesdbo.ItemPriceInfo et dbo.ItemDiscountInfo les deux ont 13 349 729 lignes. Les deux tableaux ont le ItemNumber comme colonne commune. ItemPriceInfo a des informations sur les prix et ItemDiscountInfo a des informations sur les remises. La capture d'écran # 2 montre le nombre de lignes dans chacun de ces tableaux. La capture d'écran # 3 montre les 6 premières lignes pour donner une idée des données présentes dans les tableaux.

  3. J'ai créé deux packages SSIS pour comparer les performances des transformations Merge Join et Lookup. Les deux packages doivent prendre les informations des tables dbo.ItemPriceInfo et dbo.ItemDiscountInfo, calculez le montant total et enregistrez-le dans le tableau dbo.ItemAmount.

  4. Premier paquet utilisé Merge Join transformation et à l'intérieur, il a utilisé INNER JOIN pour combiner les données. Les captures d'écran # 4 et # 5 montrent l'exemple d'exécution du package et l'exécution durée. Il a fallu 05 minutes 14 secondes 719 millisecondes pour exécuter le package basé sur la transformation Fusionner la jointure.

  5. Le deuxième paquet a utilisé la transformation Lookup avec le cache complet (qui est le paramètre par défaut). les captures d'écran # 6 et # 7 montrent l'exemple d'exécution du package et l'exécution durée. Il a fallu 11 minutes 03 secondes 610 millisecondes pour exécuter le package basé sur la transformation de recherche. Vous pourriez rencontrer le message d'avertissement Informations: The buffer manager has allocated nnnnn bytes, even though the memory pressure has been detected and repeated attempts to swap buffers have failed. Voici un lien qui explique comment calculer la taille du cache de recherche. Pendant l'exécution de ce package, même si la tâche de flux de données s'est terminée plus rapidement, le nettoyage du pipeline a pris beaucoup de temps.

  6. Cela ne signifie pas que la transformation de recherche est mauvaise. C'est juste qu'il doit être utilisé à bon escient. J'utilise cela assez souvent dans mes projets, mais encore une fois, je ne traite pas plus de 10 millions de lignes pour la recherche quotidienne. Habituellement, mes jobs traitent entre 2 et 3 millions de lignes et pour cela les performances sont vraiment bonnes. Jusqu'à 10 millions de lignes, les deux ont aussi bien performé. La plupart du temps, ce que j'ai remarqué, c'est que le goulot d'étranglement s'avère être le composant de destination plutôt que les transformations. Vous pouvez surmonter cela en ayant plusieurs destinations. Ici est un exemple qui montre l'implémentation de plusieurs destinations.

  7. La capture d'écran n ° 8 montre le nombre d'enregistrements dans les trois tableaux. La capture d'écran # 9 montre les 6 premiers enregistrements de chacun des tableaux.

J'espère que ça t'as aidé.

Scripts 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

Capture d'écran # 1:

1

Capture d'écran # 2:

2

Capture d'écran n ° 3:

3

Capture d'écran n ° 4:

4

Capture d'écran n ° 5:

5

Capture d'écran n ° 6:

6

Capture d'écran n ° 7:

7

Capture d'écran n ° 8:

8

Capture d'écran n ° 9:

9

81
user756519

Une jointure de fusion est conçue pour produire des résultats similaires à la façon dont les JOIN fonctionnent en SQL. Le composant de recherche ne fonctionne pas comme un SQL JOIN. Voici un exemple où les résultats seraient différents.

Si vous avez une relation un-à-plusieurs entre l'entrée 1 (par exemple, les factures) et l'entrée 2 (par exemple, les éléments de facture), vous souhaitez que les résultats de la combinaison de ces deux entrées incluent une ou plusieurs lignes pour une seule facture. .

Avec une fusion, vous obtiendrez la sortie souhaitée. Avec une recherche, où l'entrée 2 est la source de recherche, la sortie sera une ligne par facture, quel que soit le nombre de lignes existantes dans l'entrée 2. Je ne me souviens pas quelle ligne de l'entrée 2 les données proviendraient, mais je ' Je suis presque sûr que vous obtiendrez au moins un avertissement de données en double.

Ainsi, chaque composant a son propre rôle dans SSIS.

9
bobs

Je proposerai une troisième alternative à considérer. Votre OLE DBSource pourrait contenir une requête plutôt qu'une table et vous pourriez y faire la jointure. Ce n'est pas bon dans toutes les situations, mais lorsque vous pouvez l'utiliser, vous n'avez pas besoin de trier au préalable .

4
HLGEM

il y a 2 différences:

  1. Tri:

    • une jointure de fusion nécessite les deux entrées pour être triées de la même manière
    • la recherche ne nécessite aucun tri des entrées.

  2. Charge de requête de base de données:

    • une jointure de fusion ne se réfère pas à la base de données, seulement les 2 flux d'entrée (bien que les données de référence soient généralement sous la forme de `` sélectionner * dans l'ordre des tables selon les critères de jointure '')
    • la recherche émettra 1 requête pour chaque valeur (distincte, si mise en cache) à laquelle il est demandé de se joindre. Cela devient rapidement plus cher que la sélection ci-dessus.

Cela conduit à: s'il n'y a aucun effort pour produire une liste triée et que vous souhaitez plus d'environ 1% des lignes (une seule ligne sélectionne ~ 100x le coût de la même ligne lors de la diffusion) (vous ne voulez pas trier une table de 10 millions de lignes en mémoire ..) puis fusionner la jointure est la voie à suivre.

Si vous ne vous attendez qu'à un petit nombre de correspondances (des valeurs distinctes sont recherchées, lorsque la mise en cache est activée), la recherche est meilleure.

Pour moi, le compromis entre les deux se situe entre 10 000 et 100 000 lignes à rechercher.

Celui qui est le plus rapide dépendra

  • le nombre total de lignes à traiter. (si la table est résidente en mémoire, une sorte de données à fusionner est bon marché)
  • le nombre de recherches en double attendues. (frais généraux élevés par ligne de recherche)
  • si vous pouvez sélectionner des données triées (notez que les tris de texte sont influencés par le classement de code, alors faites attention à ce que sql considère comme triés est aussi ce que ssis considère comme triés)
  • quel pourcentage de la table entière vous chercherez. (la fusion nécessitera de sélectionner chaque ligne, la recherche est meilleure si vous n'avez que quelques lignes d'un côté)
  • la largeur d'une ligne (les lignes par page peuvent fortement influer sur le coût io de la recherche unique par rapport à une analyse) (lignes étroites -> plus de préférence pour la fusion)
  • l'ordre des données sur le disque (facile à produire une sortie triée, préférez la fusion, si vous pouvez organiser les recherches à effectuer dans l'ordre du disque physique, les recherches sont moins coûteuses en raison de moins d'échecs de cache)
  • latence du réseau entre le serveur ssis et la destination (latence plus grande -> préférez la fusion)
  • combien d'efforts de codage vous souhaitez consacrer (la fusion est un peu plus complexe à écrire)
  • le classement des données d'entrée - la fusion SSIS a des idées étranges sur le tri des chaînes de texte qui contiennent des caractères non alphanumériques, mais qui ne sont pas nvarchar. (cela va au tri, et obtenir sql pour émettre un tri que ssis est heureux de fusionner est difficile)
2
Andrew Hill

La recherche est similaire à la jointure gauche dans le composant Fusionner la jointure. La fusion peut faire d'autres types de jointures, mais si c'est ce que vous voulez, la différence réside principalement dans performance et la commodité.

Leurs caractéristiques de performances peuvent être très différentes selon la quantité relative de données à rechercher (entrée dans le composant de recherche) et la quantité de données référencées (cache de recherche ou taille de la source de données de recherche).

Par exemple. si vous avez seulement besoin de rechercher 10 lignes, mais que l'ensemble de données référencé est de 10 millions de lignes - La recherche en utilisant le mode cache partiel ou sans cache sera plus rapide car elle ne récupérera que 10 enregistrements, au lieu de 10 millions. Si vous devez rechercher 10 millions de lignes et que l'ensemble de données référencé est de 10 lignes - la recherche entièrement mise en cache est probablement plus rapide (sauf si ces 10 millions de lignes sont déjà triées de toute façon et que vous pouvez essayer Fusionner la jointure). Si les deux ensembles de données sont volumineux (en particulier s'il y a plus de RAM que disponible) ou si le plus grand est trié, la fusion peut être un meilleur choix.

2
Michael Entin

Je sais que c'est une vieille question, mais un point critique qui, selon moi, n'a pas été couvert par les réponses données est que, parce que la jointure de fusion fusionne deux flux de données, elle peut combiner des données de n'importe quelle source. Alors qu'avec la recherche, une source de données doit être conservée dans une base de données OLE.

1
Dave Sexton

Fusionner la jointure vous permet de vous joindre à plusieurs colonnes en fonction d'un ou de plusieurs critères, tandis qu'une recherche est plus limitée en ce qu'elle ne récupère qu'une ou plusieurs valeurs en fonction de certaines informations de colonne correspondantes - la requête de recherche va être exécutée pour chaque dans votre source de données (bien que SSIS mettra en cache la source de données s'il le peut).

Cela dépend vraiment de ce que contiennent vos deux sources de données et de la façon dont vous souhaitez que votre source finale gère la fusion. Pourriez-vous fournir plus de détails sur les schémas dans votre package DTS?

Une autre chose à considérer est la performance. S'ils ne sont pas utilisés correctement, chacun pourrait être plus lent que l'autre, mais encore une fois, cela dépendra de la quantité de données dont vous disposez et de vos schémas de source de données.

1
Cᴏʀʏ