Devrais-je utiliser SSIS ou une application multithread C # pour charger des fichiers à plat dans la base de données?

Question

Dans SQL Server Integration Services (SSIS), il est possible d’établir une connexion à un fichier plat pouvant contenir des millions d’enregistrements et transférer ces données dans une base de données SQL. En outre, ce processus peut être appelé à partir d'une application C # en référençant et en utilisant l'espace de noms Microsoft.SqlServer.Dts.Runtime.

Est-il préférable d’utiliser un fichier plat contenant des millions d’enregistrements avec SSIS ou au collectif "vous"? préférez une application c # avec plusieurs threads de travail (un pour lire et ajouter la ligne à une variable, un pour écrire à partir de cette variable dans la base de données) et un paramètre "mère". classe qui gère ces threads? (la boîte de dev a deux cpu)

J'ai vu ces données ( le blog de l'équipe SQL ) indiquant que, pour Un fichier plat avec un million de lignes, SSIS est le plus rapide:

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

Quelles sont vos pensées?

Answer 1

Je ne peux parler que de moi-même et de mon expérience. Je choisirais SSIS, car c’est l’un des cas où vous réinventez la roue inutilement. Il s'agit d'une tâche répétitive déjà résolue par SSIS.

J'ai environ 57 emplois (combinaison de DTS et SSIS) que je gère quotidiennement. Quatre d'entre eux gèrent régulièrement l'exportation de 5 à 100 millions d'enregistrements. La base de données que je gère compte environ 2 milliards de lignes. J'ai utilisé une tâche de script pour ajouter la date, à la milliseconde près, afin de pouvoir exécuter des tâches plusieurs fois par jour. Je fais ça depuis environ 22 mois maintenant. C'est génial!

Les travaux SSIS peuvent également être planifiés. Vous pouvez donc le définir et l’oublier. Je surveille tout chaque jour, mais la partie relative à la gestion des fichiers n’a jamais été interrompue.

La seule fois où j'ai eu recours à un programme C # personnalisé, c’est lorsque j’ai eu besoin de scinder les très gros fichiers en de plus petits morceaux. SSIS est un chien lent pour ce genre de choses. Il a fallu environ une heure pour séparer un fichier texte d’un concert à l’aide de la tâche de script. Le programme personnalisé C # a traité cela en 12 minutes.

À la fin, utilisez simplement ce que vous vous sentez à l'aise d'utiliser.

Answer 2

SSIS est incroyablement rapide. En outre, si cela doit se reproduire à plusieurs reprises, vous pouvez configurer un agent pour le déclencher dans les délais. L'écrire vous-même est une chose, essayer de le rendre multithread devient beaucoup plus compliqué qu'il n'y paraît au début.

Je recommanderais SSIS 9 fois sur dix.

Answer 3

Je ne vois pas en quoi l'utilisation de plusieurs threads pourrait améliorer les performances dans ce cas. Lors du transfert de gros volumes de données, le principal goulot d'étranglement est généralement les E / S de disque. La création de plusieurs threads ne résoudrait pas ce problème, et j’imaginais que cela aggraverait la situation car cela provoquerait un conflit de verrouillage entre les multiples processus frappant la base de données.