¿Debo utilizar SSIS o la aplicación C # de multiproceso para cargar archivos sin formato en la base de datos?

Question

Dentro de los Servicios de Integración de SQL Server (SSIS), existe la capacidad de configurar una conexión a un archivo plano que puede contener millones de registros y tener esos datos en una base de datos SQL. Además, este proceso se puede llamar desde una aplicación C # haciendo referencia y usando el espacio de nombres Microsoft.SqlServer.Dts.Runtime.

¿Se ejecutaría mejor un archivo plano con millones de registros con SSIS, o el colectivo " usted " prefiera una aplicación c # con varios subprocesos de trabajo (uno para leer y agregar la fila a la variable, uno para escribir desde esa variable en la base de datos) y una " madre " clase que maneja esos hilos? (La caja de dev tiene dos CPU)

He visto estos datos ( blog del equipo de SQL ) indicando que para un archivo plano con un millón de líneas, SSIS es el más rápido:

Process                Duration (ms)
--------------------   -------------
SSIS - FastParse ON         7322 ms 
SSIS - FastParse OFF        8387 ms 
Bulk Insert                10534 ms 
OpenRowset                 10687 ms 
BCP                        14922 ms

¿Cuáles son tus pensamientos?

Answer 1

Solo puedo hablar por mí y por mi experiencia. Me gustaría ir con SSIS, ya que este es uno de esos casos en los que podría estar reinventando la rueda innecesariamente. Esta es una tarea repetitiva que ya ha sido resuelta por SSIS.

Tengo alrededor de 57 empleos (combinación de DTS y SSIS) que administro a diario. Cuatro de ellos manejan rutinariamente la exportación entre 5 a 100 millones de registros. La base de datos que gestiono tiene unos 2 mil millones de filas. Hice uso de una tarea de script para adjuntar la fecha, hasta el milisegundo, de modo que pueda ejecutar trabajos varias veces al día. He estado haciendo eso durante unos 22 meses ahora. ¡Ha sido genial!

Los trabajos SSIS también se pueden programar. Así que puedes configurarlo y olvidarlo. Superviso todo todos los días, pero la parte de manejo de archivos nunca se ha roto.

La única vez que tuve que recurrir a un programa de C # personalizado, fue cuando tuve que dividir los archivos muy grandes en trozos más pequeños. SSIS es un perro lento para ese tipo de cosas. Un archivo de texto de una actuación tardó aproximadamente una hora en dividirse, usando la tarea de script. El programa personalizado de C # manejó eso en 12 minutos.

Al final, solo usa lo que te sientas cómodo usando.

Answer 2

SSIS es increíblemente rápido. Además, si es algo que debe ocurrir repetidamente, puede configurar un agente para que lo dispare según lo programado. Escribirlo por ti mismo es una cosa, tratar de que sea multiproceso se vuelve mucho más complicado de lo que parece al principio.

Recomendaría SSIS 9 veces de cada diez.

Answer 3

No puedo ver cómo el uso de varios subprocesos ayudaría al rendimiento en este caso. Cuando se transfieren grandes volúmenes de datos, el cuello de botella principal suele ser la E / S del disco. Generar múltiples hilos no resolvería este problema, y ??supongo que empeoraría las cosas, ya que introduciría una contención de bloqueo entre los múltiples procesos que golpean la base de datos.