Devo utilizzare SSIS o l'applicazione C # multithread per caricare file flat nel database?

Question

All'interno di SQL Server Integration Services (SSIS) esiste la possibilità di impostare una connessione a un file flat che può contenere milioni di record e che i dati vengano trasferiti a un database SQL. Inoltre, questo processo può essere chiamato da un'app C # facendo riferimento e utilizzando lo spazio dei nomi Microsoft.SqlServer.Dts.Runtime.

Sarebbe meglio eseguire un file flat con milioni di record con SSIS o il collettivo "tu" preferisce un'app c # con più thread di lavoro (uno per leggere e aggiungere la riga alla variabile, uno per scrivere da quella variabile al DB) e una "madre" classe che gestisce quei thread? (la casella di sviluppo ha due CPU)

Ho visto questi dati ( blog del team sql ) dichiarandoli per un file flat con un milione di righe, SSIS è il più veloce:

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

Quali sono i tuoi pensieri?

Answer 1

Posso parlare solo per me stesso e la mia esperienza. Vorrei andare con SSIS, poiché questo è uno di quei casi in cui potresti reinventare inutilmente la ruota. Questa è un'attività ripetitiva che è già stata risolta da SSIS.

Ho circa 57 lavori (combinazione di DTS e SSIS) che gestisco quotidianamente. Quattro di questi gestiscono regolarmente le esportazioni tra 5 e 100 milioni di record. Il database che gestisco ha circa 2 miliardi di righe. Ho fatto uso di un'attività di script per aggiungere la data, fino al millisecondo, in modo da poter eseguire i lavori più volte al giorno. Lo sto facendo da circa 22 mesi. È stato fantastico!

È inoltre possibile pianificare lavori SSIS. Quindi puoi impostarlo e dimenticarlo. Controllo tutto ogni giorno, ma la parte relativa alla gestione dei file non si è mai scomposta.

L'unica volta che ho dovuto ricorrere a un programma C # personalizzato, è stato quando ho dovuto dividere i file molto grandi in blocchi più piccoli. SSIS è un cane lento per quel genere di cose. La divisione di un file di testo di un concerto ha richiesto circa un'ora, usando l'attività di script. Il programma personalizzato C # lo ha gestito in 12 minuti.

Alla fine, usa semplicemente ciò che ti senti a tuo agio nell'utilizzare.

Answer 2

SSIS è incredibilmente veloce. Inoltre, se si tratta di qualcosa che deve ripetersi ripetutamente, è possibile impostare un agente per attivarlo nei tempi previsti. Scriverlo da solo è una cosa, cercare di renderlo multithread diventa molto più complicato di quanto sembri inizialmente.

Consiglierei SSIS 9 volte su dieci.

Answer 3

Non riesco a vedere come l'utilizzo di più thread possa aiutare le prestazioni in questo caso. Quando si trasferiscono grandi volumi di dati, il collo di bottiglia principale è generalmente l'I / O del disco. La generazione di più thread non risolverebbe questo problema, e la mia ipotesi sarebbe che peggiorerebbe le cose poiché introdurrebbe la contesa bloccante tra i molteplici processi che colpiscono il database.