Choix d'un langage et d'une base de données

Bonjour,

Je dois travailler sur une quantité énorme de données (des millions de fichiers par jour).

L'objectif est de parser les données, récupérer l'information qui nous intéresse et la stocker dans une base de données.

J'ai fait un script en php avec des regex pour ouvrir tous les fichiers, trier les données et insérer dans une bdd mysql. Mais la requête met 1h30 à charger à chaque fois. Et je doute que Mysql soit optimisé pour une volumétrie importante.


Vous me conseillez quoi comme langage pour parser le plus rapidement possible ?

merci d'avance : )

grep, awk sur Linux

Le problème c'est que je suis sur un serveur windows pour l'instant.

Citation:

---

pour ouvrir tous les fichiers, trier les données et insérer dans une bdd mysql. Mais la requête met 1h30 à charger à chaque fois.

---

Tu fais une seule requete pour l'ensemble des fichiers ?

Si tu faisais des requêtes plus petites, par bloc de 10 ou 20 fichiers, voire par fichier.

Je fais une requête par fichier. Explication du déroulement de mon script :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

On ouvre le répertoire ou y a tous les fichiers On liste tous les noms des fichiers. On les stocks dans un tableau On ouvre les fichiers 1 par 1 grâce à notre tableau et à une boucle foreach Pour chaque fichier ouvert on parse (REGEX) : On compte le nombre de ticket dans un fichier. Pour chaque tickets : On vérifie si c’est un appel sortant sinon on passe au ticket suivant Si oui on vérifie si le temps de session est > à 0 sinon ticket suivant Si oui : on parse et on récupère les données qui nous intéressent. On stock tout dans un double tableau On passe au ticket suivant On éclate le tableau pour en faire une requête SQL et on insère tout dans la bdd On passe au fichier suivant

---

en gros j'ai une requête par fichier mais le script ouvre tous les fichiers 1 par 1 et y en a beaucoup. C'est pour ça que c'est long

eddit : Je me suis mal exprimé sur mon premier post. J'ai des millions de ticket par jour répartie sur une 30aine de fichier

Citation:

---

Envoyé par shonan

On éclate le tableau pour en faire une requête SQL et on insère tout dans la bdd

---

je pense que c'est là que ça se passe, ton bouchon...

Je pensais aussi. Alors au final j'ai tout mis dans un fichier .txt (donc pas d'insert dans une boucle) et j'ai gagné quelques minutes. Mais le script reste encore très long. J'essaye de traduire mon code en python pour l'instant. Je vais voir si ça donne de meilleur résultat

Citation:

---

Envoyé par shonan

Je pensais aussi. Alors au final j'ai tout mis dans un fichier .txt (donc pas d'insert dans une boucle) et j'ai gagné quelques minutes. Mais le script reste encore très long. J'essaye de traduire mon code en python pour l'instant. Je vais voir si ça donne de meilleur résultat

---

je ne crois absolument pas que tu gagneras..

Ce n'est pas en passant de C (le plus rapide) à Python ..

C'est dans les requêtes..

Faire une requête par ticket est vraisemblablement le noeud de ton problème...

M'enfin, "c'est vous qui voyez" ...

Bonjour,

MySQL n'est pas ton probleme, a condition d'avoir une version recente et de ne pas faire d'acces concurrents.

Je reviens donc a ton code :

Code:

---

1 2 3 4 5 6

Pour chaque tickets : On vérifie si c’est un appel sortant sinon on passe au ticket suivant Si oui on vérifie si le temps de session est > à 0 sinon ticket suivant Si oui : on parse et on récupère les données qui nous intéressent. On stock tout dans un double tableau On passe au ticket suivant On éclate le tableau pour en faire une requête SQL et on insère tout dans la bdd

---

Si je comprends bien, tu fais une insertion par ticket ? Pourquoi ? Tu crains de ne pas pouvoir stocker tous tes resultats pour chaque appel ?

Sinon, tu passes a un gros moteur de bases de donnees, et tu le fais en procedure stockees. Ca se fait bien, mais ca demande du temps pour apprehender les concepts et les appliquer au parsing des tickets d'appel.

Bien sur, ton modele de base de donnees va jouer aussi : si tu passes ton temps a inserer des chaines de caracteres, c'est beaucoup plus lent que si tu inseres des chiffres.

non je ne fais pas une insertion par ticket mais une insertion par fichier.
1 fichier a plusieurs tickets (+ de 10 000).

Et le problème ne vient pas de l'insertion car j'ai remplacé l'insertion dans la bdd mysql par une écriture dans un fichier texte et le temps était quasiment similaire (2-3 min de gagner)

pour avoir fait un peu de MySQL(5.1)/PHP, je dirais que la structure de la base (tables) est importante.
J'avais des procédures stockées, et là MySQL est lamentable.
Pour en revenir aux tables, je les avais indexées pour un max de perfs.
Pour faire un test, j'avais migré (comme un porc) ma table (100 000 lignes) sous SQL Server Express : pas de clé primaire, pas d'index.

Bah; c'était plus rapide sous SQL Server Express. :aie:

Oui mais je ne peux pas me permettre d'enlever les index vu que j'ai une interface derrière et je fais pas mal de requêtes sur la base.
Et ma base est très bien structuré.
C'est normal que mon code PHP soit lent. Je veux juste gagner 20 minutes en changeant de langage , car il passe côté serveur et ça prend du temps pour rien.
Bref je me suis lancé en python. Je reste sur mysql pour l'instant.

Si tu veux vraiment gagner, ce n'est pas en passant d'un langage interprété à un autre que tu auras une énorme différence. Sans devoir tout réécrire, peut-être essayer un outil pour compiler le PHP (pour la JVM ou .Net ; Phalanger, c'est le seul que je connaisse en fait...). Puis, tu peux tenter une réécriture en C, C++, pour avoir un maximum de contrôle sur ce qui se passe et optimiser au maximum ce qui peut l'être.

Citation:

---

Envoyé par dourouc05

Si tu veux vraiment gagner, ce n'est pas en passant d'un langage interprété à un autre que tu auras une énorme différence.

---

Si si. Cf les benchmarks php vs python, c'est donc quelque chose qui peut se tenter (si le problème est effectivement là, et non lié à l'algo ou aux e/s).

Citation:

---

Envoyé par Tommy31

Si si. Cf les benchmarks php vs python, c'est donc quelque chose qui peut se tenter (si le problème est effectivement là, et non lié à l'algo ou aux e/s).

---

C'est vrai que, avec une recherche, il y a bien une différence monstre, je n'imaginais pas PHP aussi mauvais que ça :aie: ! (http://shootout.alioth.debian.org/u3...hon3&lang2=php, par exemple). J'irai voir plus en détail, parce que ça m'intrigue assez fort...

Edit : apparemment, il y a moyen de les égaler http://www.akngo.com/webdev/php-faster-than-python/...

Bonjour,

Citation:

---

Envoyé par Tommy31

Si si. Cf les benchmarks php vs python, c'est donc quelque chose qui peut se tenter (si le problème est effectivement là, et non lié à l'algo ou aux e/s).

---

Attention aux benchs : on leur fait dire ce que l'on veut, et cela change tres facilement en fonction de certains parametres. J'ai par exemple vu des benchs montrant que Java est plus rapide que du C : dans certaines circonstances, c'est vrai ; mais dans la plupart des cas, non.

Perso, je résoudrai ce problème en fabricant des fichiers CSV contenant des blocs de plusieurs milliers de tickets et je soumettrai le tout aux fonctions de bulk insert (je connais pas bien mysql mais il en existe sans doute).
Sous postgreSQL, ça m'a donné des gains de vitesse d'insertions de plus de x10 dans la majeure partie des cas.

On a eu un problème équivalent un jour, au chargement, en C, de fichiers avec des conditions multiples. On a décidé de modifier en chargeant tout sans conditions dans une table tampon Oracle (une fonction préfabriquée), puis en traitant les conditions de table tampon à table finale.
On est ainsi passé de 1h30 à 10 min.
Les conditions multiples au chargement fichier étaient-elles le seul problème ? Ou bien le truc mal écrit ?