Ik zal niet het volledige artikel herhalen (link staat onderin) maar ik wil hier wel even de test en specifiek uitkomst welke ze hebben gepresenteerd even uitlichten.
Wat ze hebben gedaan is een baseline package gemaakt op SQL Server 2008 met 30 miljoen rijen en 3 kolommen in varchar(50) formaat waar ze op een aantal plaatsen in het pakket een datatype conversie hebben toegepast om zo te testen wat het meest efficiente is. De plaatsen waar ze de transformatie hebben gemaakt zijn de volgende: in de query, in de advanced options van de OLEDB adapter, in een Data Conversion component, in een Derived Column component.
De resulaten waren als volgt:
|
Time(sec) |
CPU Utilization % |
Buffers in Use |
|
|
Baseline |
35 |
75 |
1 |
|
Transact-SQL conversion |
46 |
75 |
1 |
|
Conversion on the OLE DB Source component |
45 |
70 |
1 |
|
Data Conversion transformation |
49 |
90 |
1-3 |
|
Derived Column transformation |
71 |
85 |
7-8 |
Het meest opvallende hier is dat de oplossingen met SSIS-componenten welke de dataflow aanpassen trager en zwaarder zijn dan de oplossingen welke rechtstreeks de aan te leveren dataset muteren. Op zich niet geheel een onverwachtse conclusie, maar goed om dit toch een keer bevestigd te zien in wat getallen.
De eindconclusie van het artikel is dat als je conversie snel en efficient wilt doen je deze niet moet opnemen in een SSIS-component maar dat je het beste kan kiezen voor de T-SQL of de OLEDB oplossing.
Een reden echter om hier vanaf te wijken en toch de conversie toe te passen in SSIS is dat je op die manier wel goede debugging mogelijkheden krijgt, kies in dit geval dat toch altijd voor een Data Conversion component en niet voor een Derived Column… 🙂
Volledige artikel is hier te vinden