SELECT trop lent dans un fichier texte

SELECT trop lent dans un fichier texte - C#/.NET managed - Programmation

Marsh Posté le 25-08-2006 à 11:22:18    

Bonjour,
 
Comment puis je faire pour accélérer mes temps de traitement?
J'ai un fichier de plus ou moins 2.000.000 de lignes dans lequel je doit effectuer environ 5000 query.
Donc pour l'instant je charge tout en mémoire dans une DataTable puis ensuite j'utilise une DataView puis la propriété DataView.RowFilter. Mais c'est horriblement lent!
 
Donc comment puis je optimiser? Est ce que se serait plus rapide de tout insérer dans MsSql puis de faire mes query via MsSql?  
Sinon existe t il quelque chose de plus rapide que les RowFilter des dataView pour faire mes query?
 
D'avance merci
 
Ben

Reply

Marsh Posté le 25-08-2006 à 11:22:18   

Reply

Marsh Posté le 25-08-2006 à 11:50:55    

Ce sera clairement plus rapide de bosser avec un SGBD, ça c'est sûr.
 
Ensuite, plutôt que de charger dans un DataView, si tes query ne portent que sur un seul champ, tu peux aussi charger le fichier dans un arbre. La recherche dans un arbre sera bien plus efficace.

Reply

Marsh Posté le 25-08-2006 à 12:06:57    

oui mais cela impliquerais que l'arbre soit trié :S pas génial non plus... C'est clair qu'un fichier de 2.000.000 d'enregistrements c'est pas super.  
 
Mais réinjecté les data dans une bd avant de faire la query si de tt façon les data de base sont dans un fichier, ralentira encore plus qu'autre chose l'opération.

Reply

Marsh Posté le 25-08-2006 à 12:09:47    

C'est sûr que s'il ne construit la base que pour faire les requêtes, ça ne va rien arranger.
 
Il est de quel format le fichier ?
Y'a déjà un tri de fait dedans ?

Reply

Marsh Posté le 25-08-2006 à 13:11:55    

Il est au format .txt  
Et non il n'y a aucun tri
 
J'utiliserai ce fichier que pour mes requete. Ce fichier est la sortie d'un programme sur lequel je n'ai pas la main!


Message édité par the big ben le 25-08-2006 à 13:12:42
Reply

Marsh Posté le 25-08-2006 à 13:16:18    

tu n'as pas trop de possibilités alors. L'arbre tombe à l'eau et passer par un SGBD aussi.  
 
Dans le meilleure des cas faudra prendre ton mal en patience. Cependant, rien ne t'empêche de faire des tri toi même (Heap Sort) et de faire les opérations après. Tu pourras gagner un peu de temps, mais ne crois pas que tu vas booster le truc à crever.

Reply

Marsh Posté le 25-08-2006 à 13:41:37    

.txt ça veut rien dire, ça pourrait être .duchemol ça changerait rien ;)
 
moi je parle du format interne : pas fixe, csv, xml, etc.

Reply

Marsh Posté le 28-08-2006 à 10:08:48    

du csv avec les champs séparés par des tab

Reply

Marsh Posté le 28-08-2006 à 10:35:38    

parcourir le fichier, preparer une requete:  
insert into x values(xxxx),(xxxx),(xxxx),(xxxxx),(xxxxxxx)
 
une seule requete à exécuter, le goulot d'étranglement sera la vitesse de lecture du fichier , pas le sgbd.
 
En comptant 100 caractère par ligne, on arrive à 200mo d'occupation mémoire pour la chaîne, tu peux découper par paquet de 10 000 lignes par exemple si tu n'as pas beaucoup de ram et ça swappe trop.

Reply

Marsh Posté le 28-08-2006 à 11:14:55    

En insérant dans une table temporaire (en mémoire) avec insert into #temp ca va déja nettement plus vite aussi....

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed