Discussion :

[rockley]

Salut tout le monde.

J'aurai besoin de votre expertise et de votre expérience en c# pour m'orienter.

J'ai un projet en c# consistant à faire des lectures/traitements/écritures en base de donnée. (on tourne autour de 6 000 000 de lignes d'enregistrements)
Alors que le projet est presque terminé, il y a un changements de cap.
Je vais devoir passer par des fichiers plats au lieux des BDD.

Mon problème change donc, puisque après avoir optimisé le programme pour passé de six jours de traitements à 30 min, je dois tout laisser tomber pour recommencer. Et je ne sais pas si je peux retrouver l'équivalent.

Avant tout, je fait ma méa culpa s'il y a des questions trop simple, je me suis mis au c# que depuis un mois.


Quelles sont les méthodes les plus rapide de lecture et d'écriture dans un fichier ?

Comment donner un comportement type BDD à un fichier, faire un unload du BDD ?
Dans beaucoup de langage on peut crée un fichier liées au fichier de donnée définissant la structure d'une ligne avec ordre/nom/type/taille
des variable par ligne.


Peut-on écrire des "lignes multiples" en une fois ?
( L'équivalent de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
INSERT INTO table (column1, column2)
SELECT value1, value2 FROM DUAL UNION ALL
SELECT value1, value2 FROM DUAL UNION ALL
...etc...
SELECT value1, value2 FROM DUAL ;

en oracle)
Cela m'avais permis de diviser mon temps de traitements par 8.


Pour ne pas trop rallonger la liste des questions, en synthétisant, je voudrais avoir un fichier avec un comportement similaire aux BDD (ordre/nom/type/taille des variables) et avec les meilleurs perfs.

[NicoL__]

Salut,
ça m'a l'air bien ce qui a été réalisé pour passer de 6 jours à 30 min... le changement de cap m'a l'air un peu foufou, j'imagine que le décideurs savent ce qu'ils font et ce qu'ils disent.
En fait manipuler des données structurées dans des fichiers plats est tout un art, le mainframe des année 80-90 le font pas trop mal. Et Oracle le fait aussi très bien car au final, la base de données écrit dans un fichier...
Enfin si y a qu'une table donc un seul fichier pourquoi pas... encore qu'il vaudrait mieux le découper et réaliser un indexe pour pouvoir faire des accès concurrents... et puis monter ça en mémoire, bref c'est un peu ce que fait une base de données.

Les API pour manipuler le XML ont des comportement un peu du genre des BDD mais je suis pas certain que le perfs soit meilleurs pour de gros volumes de données, ça va soit être lent soit intégralement monter ne mémoire. Mais cette dernière option peut-être intéressante si la mémoire est suffisante : une lecture intégrale et une réécriture intégrale.

Bref tout ça pour dire que les bases de données c'est pas mal et performant et c'est pour cela qu'elles ont peu à peu supplantées les mainframes.

Sinon y a des trucs au peu advance genre "big data" et NoSql mais bon je pense que c'est un peu hors sujet.


PS : pas mal la technique pour Oracle je n'y avais jamais pensé.

[Bluedeep]

Bref tout ça pour dire que les bases de données c'est pas mal et performant et c'est pour cela qu'elles ont peu à peu supplantées les mainframes.

La remarque ne manque pas de sel quand on sait que les bases de données sont apparues à l'orgine sur les mainframe ......

[Bluedeep]

Salut tout le monde.

J'aurai besoin de votre expertise et de votre expérience en c# pour m'orienter.

J'ai un projet en c# consistant à faire des lectures/traitements/écritures en base de donnée. (on tourne autour de 6 000 000 de lignes d'enregistrements)
Alors que le projet est presque terminé, il y a un changements de cap.
Je vais devoir passer par des fichiers plats au lieux des BDD.

Il y a plusieurs solutions; dans presque tous les cas, le résultat sera beaucoup plus mauvais qu'en utilisant un SGBD.

Quelle est la raison de ce choix ?

[rockley]

Pour être plus précis.

Le projet comprend 3 tables.
Une table de départ contenant les infos à traiter.(5 000 000 d’enregistrements).
Une table contenant les infos de prod, avec numéro du client et numéro du dossier, ... (1 000 000 d’enregistrements).
Et une table final (en insert) qui contiens les infos venant des deux tables une fois les relations faites et traitées.

Pour les lectures, je charge la table de prod en entier, et la table de départ est fragmenté en 10 (sinon la mémoire explose).
Je fais le traitement et je fais des insertions de masse.


Je ne doute pas que se soit plus lent, si j'utilise les classes les plus préforment pour lire et écrire dans un fichier qui a un formatage spécifique, je pense que ça devrais le faire.
Et c'est pour ça que je demande vote aide et votre avis.

PS:

Quelle est la raison de ce choix ?

mésentente entre les acteurs avec moi au milieux

[NicoL__]

Je rajouterais un petit trucs si l'objectif est uniquement d'être plus rapide il faut déterminer le goulet d'étranglement :
- CPU programme client
- CPU BDD
- IO BDD
- réseau entre BDD et client
- Nombre de requêtes

Si le CPU client est à 100% et que les calculs sont optimisés alors c'est pas mal, ça coûte surement mois chère d'acheter un machine plus puissante que de tout revoir. Voir de mettre en place un traitement réparti sur plusieurs machines surtout si les traitement peuvent se faire par lots.

PS : Si l'homme descend du "singe" il n'en a pas moins supplanté ses ancêtres. Mais, Tomasi est un homme, Tomasi descend du singe, Tomasi ne descend pas du panneau de basket.

En java il y a des API genre : http://joafip.sourceforge.net/, il y a peut-être des choses équivalentes en .net

[rockley]

En utilisant un BinaryFormatter et les sérialisations j'ai réussi à faire la même chose avec le même temps de traitement.

Le seul IK c'est que je dois créer un projet à part pour pouvoir simuler une espèce de sqlDeveloper.

Sinon merci pour votre aide.