Tout d’abord, je précise que je ne cherche pas ici de solution toute faite mais plutôt des pistes pour développer une solution objet élégante et optimisée.
Le problème en question :
Cummuler les données de X fichiers
Les contraintes :
Des fichiers très importants (pouvant dépasser le million de lignes)
Des clés sur 6 champs ou plus (numérique et chaines de caractères)
De 2 à 20 fichiers à cumuler en même temps
Les fichiers sont tous triés par leur clé
Voici un début d’algo :
1 - Charger toutes les premières lignes des X fichiers
2 - Rechercher la plus petites clé et cumuler les données de cette clé
3 - Lire la ligne suivante pour les fichiers qui avaient la plus petite clé
4 - Retour à l’étape 2
Les problèmes à régler :
L’association fichier => Données
A priori il faudra contenir les fichiers et les données dans des tableaux avec des index respectifs.
La gestion des fins de fichiers
La comparaison des clés (Utilisation d’une interface Comparable ?)
Je pense qu’il serait très interressant d’avoir au finale une API de ce genre :
[code]class DataRunner {
new (List, Doeable)
void run()
}
class Doeable {
void do(List)
}
class Compareable {
int compare(Data, Data)
}[/code]
[quote=« ZGoblin, post:1, topic: 46798 »]Cummuler les données de X fichiers
Les contraintes :
Des fichiers très importants (pouvant dépasser le million de lignes)
Des clés sur 6 champs ou plus (numérique et chaines de caractères)
De 2 à 20 fichiers à cumuler en même temps
Les fichiers sont tous triés par leur clé[/quote]
On a rien d’inventer de mieux pour traiter les données, qui plus est énormes, que les bases de données.
Sous Oracle il existe des tables externes. C’est à dire que tu mets tes fichiers à un endroit précis et grâce au principe des tables externes tu peux les lire par des SELECT sous Oracle comme une table « normale ».
Après rien n’empêche de faire appel à tes tables via des API jdbc, ou par HSQL, et faire une partie de l’algo en java plutôt qu’en SQL bien que ce dernier soit plus approprié que le java. (si ton langage POO est java). Même si tu ne te sers pas de SQL, avec les tables externes tu as l’association fichiers-données et clés.
Cette partie[quote=« ZGoblin, post:1, topic: 46798 »]Voici un début d’algo :
1 - Charger toutes les premières lignes des X fichiers
2 - Rechercher la plus petites clé et cumuler les données de cette clé
3 - Lire la ligne suivante pour les fichiers qui avaient la plus petite clé
4 - Retour à l’étape 2[/quote] se ferait avec les fonctions analytiques qui sont faites pour cela à moins que tu veuilles réécrire un moteur de base de données.
Notre oracle commence à galérer lorsque l’on dépasse les 10 millions d’enregistrements et si on garde tout l’historique on peut même arriver jusqu’à 50 millions d’enregistrements.
Maintenant je ne suis pas expert Oracle, je ne fais que m’en servir et c’est d’autres collègue qui s’occupe de ces problèmes de volumétrie.
ça me parait quand même bizarre qu’un Oracle soit sur les genoux avec ce genre de volumétrie, à moins d’être super mal configuré et/ou de tourner sur un serveur en bois.
sinon, ton algo de départ me parait bon, mais dans ce cadre je ne pense pas que la poo apporte grand chose, et personnellement je m’orienterais plutôt vers du procédural (parce qu’on est pas obligés de faire de l’objet pour faire quelque chose de propre et de solide, surtout quand on bosse sur des enregistrements qui ne vont pas rester en mémoire plus de temps qu’il n’en faut pour les recopier dans le fichier cible).
[quote=« ZGoblin, post:6, topic: 46798 »]Notre oracle commence à galérer lorsque l’on dépasse les 10 millions d’enregistrements et si on garde tout l’historique on peut même arriver jusqu’à 50 millions d’enregistrements.
Maintenant je ne suis pas expert Oracle, je ne fais que m’en servir et c’est d’autres collègue qui s’occupe de ces problèmes de volumétrie.[/quote]
Je sais pas ce que font tes collegues ou ce que tu mets dans tes enregistrements mais pour avoir eut affaire a des bases avec des centaines de millions d’entrees sur des gigs et des gigs qui tournaient sans broncher, ou je rate un truc enorme ou a mon avis a moi, le probleme il vient pas d’oracle…
[quote=« ZGoblin, post:6, topic: 46798 »]Notre oracle commence à galérer lorsque l’on dépasse les 10 millions d’enregistrements et si on garde tout l’historique on peut même arriver jusqu’à 50 millions d’enregistrements.[/quote]???
Ou alors ai-je rêvé pendant toutes ces années.
Sinon pour répondre au problème, oui, ya plein de gens compétents qui se sont cassés le trognon pour faire des moteurs de BDD donc faut pas réinventer la poudre, hein, quand on peut…
[quote=« coccobill, post:9, topic: 46798 »]???
Ou alors ai-je rêvé pendant toutes ces années.
Sinon pour répondre au problème, oui, ya plein de gens compétents qui se sont cassés le trognon pour faire des moteurs de BDD donc faut pas réinventer la poudre, hein, quand on peut…[/quote]
Ce que tu essayes de me dire avec ‹ ??? › c’est que tu géres ce genre de problème depuis plusieurs années ? Tu travailles avec une base de données Oracle possèdant des millions de lignes dans certaines tables et que tu arrives à faire plusieurs jointures plutôt rapidement avec gestion de l’historique ?
Je travaille dans la distribution, imaginons, que nous avons 100 magasins, 50000 références par magasin et que nous voulons garder les stocks « fin de mois » des 5 dernières années, plus celui de tout le mois en cours :
(50000 * 100 * (12 * 5 + 30)) = 450 000 000
D’après mes collègues, au moment d’archiver le mois dernier (150 000 000 enregistrements) les performances étaient catastrophiques.
D’où l’idée de ne garder en base qu’une seule année, et archiver les données stocks sous forme de fichier texte afin de rejouer les calculs par la suite pour nos chers amis les commissaires au compte.
Outre le fait que je vois mal l’utilité de garder les stocks sur 5 années (mais là n’est pas la question), ça me parait pas incroyable de gérer ça.
Avec une base bien configurée, des tas d’index sur les dates, les magasins et les références, il n’y a aucune raison pour qu’oracle ne puisse pas gérer ça.
c’est sur qu’ajouter 150 millions de lignes d’un coup ne va pas se faire en quelques millisecondes et qu’il vaut mieux éviter de le faire au moment ou la base est très sollicitée pour autre chose, mais en théorie ça se fait très bien.
C’est juste la loi qui oblige de garder certaines informations pendant X années.
Après relecture de tous vos posts, je me demande si ce n’est pas un problème de machine qui n’est pas adaptés à nos besoins (lui rajouter quelques processeurs de plus ne lui ferait pas de mal), mais bon je fais avec les moyens du bords, ce n’est pas moi qui défini les budgets, je ne suis là que pour faire le développement .
Et pour revenir au sujet original, c’est à dire un algo qui permet de traiter X fichiers triées en faisant des cumuls par clé, j’ai repris ce que j’ai dis dans me premier post et je n’ai eu aucun problème.
En tout cas merci pour vos avis critique (dans le bon sens du terme).
Je travail aparament dans le même crénaux que toi (un grand groupe de magasin avec beaucoup de référence), de notre coté on garde 1 ans de base et le reste en archive, on fait une cloture comptable en fin d’année, on dump et on garde le dump sur bande au coffre.
Le jour ou des commissaires nous demande de leur ressortir des chiffres, on restaure le dump sur une machine dans une bdd provisoir.
Alors oui c’est chiand de ce taper 10go de restaure et de recharger un dump de 90Go, mais bon, ca évite de surcharger la base.
A noté que c’est uniquement un choix pour ne pas avoir a changer les machines gerant les base de données. (de vieux aix tout pourri :x)
Ca s’appelle un datawarehouse, j’ai joué avec ça pendant longtemps (dans le domaine de la distribution aussi), et je confirme qu’Oracle bien configuré supporte ça sans broncher. Quoiqu’il en soit, regarde du côté d’une vraie procédure d’archivage.
La Loi t’oblige à garder pas mal d’infos pendant longtemps, certes, mais d’une, pas autant que tu l’imagines (c’est quoi cette histoire de stock oO), et de deux, il y a plein plein plein de manières de le faire, par exemple, la très classique historisation de n-2 quand on est dans l’année n, l’utilisation du partitionnement, la séparation d’une base de production pour ton WMS au jour le jour et un DWH, etc.
Je te conseille de demander à tes dév BDD de chercher un vrai DBA Oracle car ça a l’air de manquer dans ta société (dit sans aucune méchanceté, mais la BDD, c’est un vrai métier :)).
Ce n’est pas ma boite, je suis prestataire et mon taf se limite à développer des traitements avec certaines contraintes, n’ayant pas les compétences techniques dans l’administration d’une base oracle, je me vois mal remettre en cause le travail du client, mais le jour où j’aurai plus de pouvoir, je ne tacherai pas de me rappeler ce thread
Je connais quelqu’un qui à l’école (supinfo) a travaillé sur de l’oracle, et pour faire un “simple tp” avec (de mémoire) pas trop de monde en même temps, ils ont été obligé de rajouter une machine et de faire du load balancing.
Bref je plussoie l’argument “Tes serveurs sont ils assez couillus?”
