Discussion :

[fanfouer]

Bonjour,

Je suis entrain de mener une étude pour trouver des pistes de réalisation d'un traitement de données en grande quantité.
Pour préserver une certaine confidentialité, je ne pourrai pas révéler le contenu exact des fichiers mais imaginons qu'il s'agisse du log de tracking GPS des camions d'une société de transport.

Chaque camion possède un numéro et le système embarqué renvoi à intervalles rapprochés la position du camion. Cette société de transport possède un grand nombre de camions et à la fin d'une journée, le fichier qui conserve une trace de l'itinéraire de chaque véhicule pèse au moins 4Go (on ne peux pas le changer, il n'y a pas d'erreur de conception à ce niveau) - le fichier contient les entrées en ordre chronologique de tous les camions.

A différent moments dans la journée, les camions arrivent aux centres logistiques.
Le but de mon application est de sélectionner les camions qui sont dans certains centres puis de déterminer leur itinéraire. On obtient donc les numéros de ces camions en parcourant intégralement le fichier et en comparant les coordonnées des points remontés à celles des centres logistiques sélectionnés.
Une fois la liste obtenue, je pensais re-parcourir une seconde fois le fichier pour extraire toutes les entrées du log qui se rapportent aux bons camions.

Le problème est qu'on ne travaille pas avec des jeux de données légers et que mon serveur va exploser.
Je ne pense pas, par exemple, que d'utiliser SQL dans ce cas de figure soit approprié. 4Go de données texte, ca doit faire une grosse table
Sachant qu'il s'agit en quelques sorte de fichiers CSV, peut-être existe-t-il un algorithme qui permet de sélectionner des lignes au milieu de tout ce fouillis sans faire un joli while(!feof()).

Une de mes autres idées serait de trier le fichier suivant le numéro de camion dès le premier parcours (à la recherche des camions) puis d'éliminer toutes les lignes se rapportant à un camion dès que celui-ci à été détecté comme non valide.

Si des gens plus expérimentés ont d'autres avis, je serai ravi d'échanger avec eux.

Bonne journée.

[rawsrc]

Bonjour,

Comme tu le soulignes un fichier (csv) de 4 Go c'est très gros pour parser avec du PHP. Le plus simple serait d'utiliser ton moteur de base de données car il est parfaitement taillé pour ce genre de travail.
Regardes du côté de LOAD DATA INFILE sur MySql. C'est très performant et tu peux tout préparer d'avance (clés, index...) Bref une fois importé, le traitement en PHP n'en sera que plus aisé.

[Bovino]

il n'y a pas d'erreur de conception à ce niveau

Ben... AMHA, commencer par créer un fichier log pour chaque camion pourrait être une piste envisageable...

[fanfouer]

Comme tu le soulignes un fichier (csv) de 4 Go c'est très gros pour parser avec du PHP. Le plus simple serait d'utiliser ton moteur de base de données car il est parfaitement taillé pour ce genre de travail.

En fait, hormis le fait de charger bêtement le fichier en mémoire pour le parser, il y avait bien deux moyens à considérer dans mon idée.
L'utilisation de MySQL, comme tu l'affirmes faciliterait grandement le traitement derrière (le WHERE pour rechercher les bons camions c'est vraiment cool). Il faut aussi voir que si je créé des index (ce qui serait recommandé vu la taille) sur une table de 4 à 5Go (taille moyenne des fichiers, ça peut atteindre 12Go aussi), on va se retrouver avec un dataset énorme.
Est-ce que quelqu'un pourrait me dire à partir de quelle taille en gros SQL commence à perdre les pédales?
Il y avait aussi l'ouverture du fichier comme un flux et l'analyse ligne à ligne (puisque chaque ligne est indépendante). On ne sature pas la mémoire, par contre les accès disques risquent bien d'augmenter nettement le temps de traitement.
Pour infos, le traitement se fait la nuit et il est souhaitable que ça ne dépasse pas 4H de temps.

Une fois qu'on a récupéré ce qui nous intéresse dans le fichier, le calcul des stats commence véritablement, mais c'est du menu calcul passé ce stade.

Ben... AMHA, commencer par créer un fichier log pour chaque camion pourrait être une piste envisageable...

On ne peut pas créer un fichier de log pour chaque "camion". Je ne les maîtrise pas d'ailleurs, ces fichiers, je les récupère tels quel et il faut que je me débrouille

Merci pour vos réponses.

[rawsrc]

Est-ce que quelqu'un pourrait me dire à partir de quelle taille en gros SQL commence à perdre les pédales?

Cela fait un certain temps, que SQL ne perd plus les pédales quelque soit la taille du dataset, il faut juste que les ressources matérielles soient en adéquation avec l'objet traité.
J'ai vu des bases de données encaisser du 20 To par semaine sans broncher. Après pour les perfs, il faut des pro du côté de l'administration.
Penses aussi un fois que les données seront injectées s'il ne serait pas plus judicieux de faire les stats avec une procédure stockée.
Enfin, si tu ne veux pas mettre à genoux ton serveur de production, déportes ce travail sur un serveur dédié. Cela doit être possible du fait que le travail est périodique et à partir d'une source de données isolée.

[stealth35]

en stream (fgetcsv) ça prendra très peu de mémoire, si ton script est bien fait avec une belle requete préparée, ça sera rapide, une table de plusieurs GO ça me choque pas, c'est fait pour les SGBD