
Het blijft een discussie waar we maar moeilijk uitkomen: SSIS packages of stored procedures bouwen om data van bron naar bestemming te halen? Vooral wanneer in een ontwikkelteam veel T-SQL kennis aanwezig is, is de keuze voor het laatste snel gemaakt. Waarbij SSIS hooguit gebruikt wordt als workflow engine. Toch hebben SQL Server Integration Services packages, en het gebruik van de dataflow engine daarbinnen, een aantal grote voordelen:
- Geheugengebruik; SSIS maakt zeer efficient gebruik van het geheugen. Hierdoor kan, met name in packages waarin veel (complexe) transformaties plaatsvinden, een enorme performance winst behaald worden ten opzichte van een oplossing in T-SQL. Zeker wanneer je goed gebruik maakt van de mogelijkheden tot parallellisatie die SSIS biedt.
- Diverse externe bronnen en bestemmingen; SSIS is gemaakt om te werken met diverse externe bronnen en bestemmingen. Je kunt in één package meerdere bronnen gebruiken, ook niet SQL Server gerelateerd; hetzelfde geldt voor de bestemmingen.
- Logging en foutafhandeling; de manier waarop SSIS, zeker in SQL Server 2012, voorziet in logging en foutafhandeling (oa. event handlers), biedt veel meer mogelijkheden met minder inspanning dan in T-SQL.
- Debugging; met behulp van data viewers is het erg makkelijk te zien welke data er door een bepaald deel van een data flow heen gaat.
- Leesbaarheid; dankzij de grafische interface zijn complexe SSIS packages beter leesbaar dan complexe T-SQL. Je ziet sneller wat er gebeurt en, mits je SSIS kent, kun je vaak sneller complexe transformaties toevoegen aan een SSIS package.
- Modulair; SSIS packages zijn van nature modulair van opbouw, iets wat je in T-SQL alleen kunt bereiken door functionaliteit op te splitsen in meerdere stored procedures of door gebruik te maken van user defined functies, maar dan kunt je te maken krijgen met een flinke performance penalty.
Natuurlijk kun je ook van stored procedures voordelen opschrijven. En daarmee blijft dit een discussie die misschien wel nooit een definitieve uitkomst zal hebben. Vergeet niet dat een mix van SSIS en T-SQL ook heel goed mogelijk is, al wil ik met dit artikel juist waarschuwen niet standaard door te slaan naar alles standaard in T-SQL oplossen en SSIS alleen als workflow engine te gebruiken. Een discussie waarin je een aantal aspecten mee moet nemen om tot een goede keuze te komen:
- aanwezige kennis (bij ontwikkelaars én beheerders)
- performance eisen
- onderhoud
Een discussie die vaak als antwoord zal hebben: it depends…. Google maar eens op “ssis vs stored procedure” voor meer ‘food for thought’.
One comment
Goede post, Hans! Daarnaast zou biedt SSIS gigantische performance-winsten bij het kopiëren van de wat grotere tabellen (10GB+) tussen verschillende servers. Wanneer via T-SQL (bijv. een stored procedure) data wordt gekopieerd tussen servers, wordt tempdb zeer intensief gebruikt, vermoedelijk omdat niet teveel onnodig te locken, en alles dus eerst klaar te zetten alvorens de commit door te voeren (ik ben er niet volledig zeker van of dit de werkelijke reden is). Met SSIS heb je dit probleem niet. Gevaar zit ‘m dan wel weer in het ‘ad hoc’ toepassen van SSIS, bijvoorbeeld in een beheerscontext: de database-connecties zijn minder expliciet zichtbaar dan bij de vierdelige naamgeving vanuit T-SQL.
Ik ben nu wel benieuwd naar een vervolg: ben je weleens situaties tegengekomen waarin SSIS ten onrechte gebruikt werd, en een stored procedure echt een veel betere oplossing geweest zou zijn?
Koos