[PHP 5.3] Import de masse en plusieurs étapes [Résolu]

[fanfouer]

Bonsoir,

Je souhaite avoir quelques conseils pour mettre en place un système d'import de données en masse pour une plateforme que je suis entrain de concevoir.
Je ne savais pas trop où placer ce topic, qui relève plus des concepts qu'un aide sur la syntaxe pure.

Cette plateforme peut être amenée à gérer plusieurs centaines de milliers d'enregistrements dans une base et se base sur un framework maison pour fonctionner et surtout interagir avec la base de données. Rien de trop exceptionnel.
Vu le volume d'informations, il peut être intéressant de fournir à l'utilisateur le moyen de les importer à partir de fichiers de formats divers (csv, texte, image - pourquoi pas...).

La question est de savoir comment gérer la digestion d'un fichier csv d'environ 10 000 lignes (parsage puis import dans la base de données) sachant que mon hébergeur ne va surement pas me permettre d’exécuter le script d'un seul coup vu le temps nécessaire.
J'ai déjà eu l'occasion de rencontrer ce type de problème et je ne vois pas comment renvoyer à l'utilisateur que le script s'est arrêté pour un dépassement de limite de temps d’exécution et surtout avec le dernier état connu (en l’occurrence un numéro de ligne en cours de traitement). Bien souvent, le serveur se contente de me renvoyer une page blanche ou même une erreur HTTP fantaisiste.

Je prévois de mettre en place une interaction client/serveur en AJAX pour que le client javascript "supervise" ce que fais le serveur pendant la digestion. Une fois le dernier état renvoyé au client, il est facile de dire au serveur dans un second temps "redémarre avec ce même fichier à telle nouvelle position".

Est-ce que quelqu'un aurait une idée de comment je peux connaitre ce fameux dernier état rencontré avant l'arrêt?

En vous remerciant de vos réponses.

[transgohan]

Tu enregistres cet état dans un fichier.
Et t'as plus qu'à avoir un script appelé avec de l'ajax pour vérifier son contenu.

Pour le dépassement de temps il y a il me semble la fonction register_shutdown_function() qui peut t'être utile.

[grunk]

Vu les quantités de données dont tu parles, je pense qu'un serveur dédié risque de s'imposer assez vite.

Ceci étant , pourquoi ne pas procéder à l'import avec mysql directement. La commande LOAD DATA INFILE permet de charger des données depuis un csv dans la base. Elle permet de gérer les doublons et tout un tas de choses qui vont être galère à mettre en place en php.
De plus l'import direct via mysql sera infiniment plus rapide que via php.

http://dev.mysql.com/doc/refman/5.0/en/load-data.html

D'après cet article il serait apparemment possible d'améliorer la vitesse d'insertion ainsi que de récupérer une progression.

[fanfouer]

Bonjour vous deux, merci de vos réponses

Envoyé par transgohan

Tu enregistres cet état dans un fichier.
Et t'as plus qu'à avoir un script appelé avec de l'ajax pour vérifier son contenu.

Bonne idée en effet.

Par contre l'utilisation d'un fichier n’alourdirait-elle pas encore plus le processus?
Vu que tout peut s’arrêter d'un moment à l'autre, il faut ouvrir puis fermer le fichier à chaque itération pour indiquer le tout dernier état.

Je vais chercher une piste de ce côté mais qu'en penses-tu?

Pour le dépassement de temps il y a il me semble la fonction register_shutdown_function() qui peut t'être utile.

Je suis en mutualisé chez OVH, mais je ne suis pas sur qu'il soit permis de le modifier.

Envoyé par grunk

Vu les quantités de données dont tu parles, je pense qu'un serveur dédié risque de s'imposer assez vite.

Non, justement c'est le but d'éviter ça

Ceci étant , pourquoi ne pas procéder à l'import avec mysql directement.

Non plus, parce que les données sont organisées dans différentes tables et il serait assez dur (et de manière peu globale en définitive) de gérer ça en SQL directement. Mon framework est là pour ça pour généraliser le processus (on pourra écrire ces données dans des fichiers, sur des webservices ou sur une base indépendamment en changeant juste le Driver responsable de l'écriture).

Je regarderai néanmoins l'article plus tard dans la journée, merci pour le lien.

[grunk]

Le fait de rester sur un mutualisé va t'obliger à effectuer les traitements par petits bout. Je sais pas à combien est OVH mais les mutualisé qui offre plus de 30 sec de timeout sont assez rare.
Tu risques également d'avoir quelques souçis avec OVH si tu consomme trop de ressource par rapport aux autres sites de ton cluster (10k enregistrements à balancer dans une bdd, c'est moyen pour les autres utilisateurs).

Ce qu'il serait possible de faire. A la réception d'un fichier tu le découpes en X parties. Puis tu lance l'insertion des parties les unes après les autres.
Ça va te permettre d'éviter les timeout car tu n'exécuteras que de petites insertion (par exemple 100 à chaque fois), ça va te permettre d'indiquer une progression à tes utilisateurs et éventuellement de pouvoir reprendre facilement à un endroit précis en cas de plantage.

[fanfouer]

Envoyé par grunk

Le fait de rester sur un mutualisé va t'obliger à effectuer les traitements par petits bout. Je sais pas à combien est OVH mais les mutualisé qui offre plus de 30 sec de timeout sont assez rare.
Tu risques également d'avoir quelques souçis avec OVH si tu consomme trop de ressource par rapport aux autres sites de ton cluster (10k enregistrements à balancer dans une bdd, c'est moyen pour les autres utilisateurs).

Oui, ce doit être 30 secondes mais on peut répéter x bouts de 30 secondes je crois que c'est l'idée générale qui se dégage de ce topic.
Pour l'utilisation des ressources, le mutualisé étant ce qu'il est bien entendu qu'il faut s'en servir de manière responsable mais d'un autre côté, si OVH me donne une certaine proportion du temps machine, je ne vois pas pourquoi je ne m'en servirais pas dans sa totalité.
Sinon qui est juge du "trop" ou "pas assez"?

Ce qu'il serait possible de faire. A la réception d'un fichier tu le découpes en X parties. Puis tu lance l'insertion des parties les unes après les autres.
Ça va te permettre d'éviter les timeout car tu n'exécuteras que de petites insertion (par exemple 100 à chaque fois), ça va te permettre d'indiquer une progression à tes utilisateurs et éventuellement de pouvoir reprendre facilement à un endroit précis en cas de plantage.

C'est vrai.
Ce sera un peu plus complexe que le "100 lignes ou rien" mais on peut en effet calculer un certain facteur en fonction du nombre de tables à toucher et de la complexité du jeu de donnée qu'on présente à l'import.

Par dessus, le fait de devoir recommencer une partie qui s'est arrêté plus tôt que prévue ne pose pas de réel problème d'intégrité, l'ORM du framework gère les différences des enregistrements et ne publie que ce qui a vraiment changé.

Merci pour vos réflexions je vais me mettre au travail.