Clé primaire et ralentissement [Résolu]

[HumanTool]

Bonjour,
J'ai une base donnée paradox avec environ 100 000 enregistrements que je souhaité migrer vers postgreSQL. J'ai donc recréé mes tables sous PostgreSQL et créé une application en delphi en utilisant la technologie dbexpress pour me connecter à PostgreSQL.

Par la même occasion je souhaité tester les performances de PostgreSQL face à paradox comme je fonctionnais en 3 tiers j'ai donc garder cette structure pour ma migration :
- Alias BDE + TQuery pour mes tables paradox
- TSQLConnection + TSQLDataset + TDataSetProvider + des TClientDataSet pour me connecter à postgreSQL.

Ma migration se passe bien et j'ai des temps trés correct je l'avoue (normal !), seulement voilà j'ai un comportement étrange vers le 90 000 enregistrement, la migration se ralentie. Le nombre d'enregistrement traité prend de plus en plus de temps et mon appli consomme de plus en plus de mémoire...

J'ai essayé les drivers Pge et le composant Zeos, et j'ai le même comportement. De plus la migration se passe trés bien si je supprime la contrainte de clé primaire sur la table....

Est-ce que quelqu'un aurait une idée ? J'ai créé des tables comme quand je le faisait sous paradox mais peut être y a t il un paramétrage particulier à faire sous PostgreSQL ?

Enfin, je suis sous vista, delphi 7, postgresql 8.2

[budtucker]

Salut,

Delphi n'est pas vraiment fait pour ce genre de rappatriement de données. Le problème n'est pas lié à la base de données en elle même, mais à la façon dont Delphi (indirectement Windows) gère ces enregistrements. Postgre gère très bien les grandes quantités d'occurence (> 1 000 000).

a+

[HumanTool]

Salut,
pourrais-tu détailler ce que tu veux dire par

la façon dont delphi(indirectement Windows) gère ces enregistrements

? Tu veux parler d'une mise en cache.

Le clientdataset de delphi garde les modif jusqu'à ce que j'appelle la méthode applyupdate, et là il envoi tout au sgbd. Je le fais tous les 50 enregistrements pour pas trop surcharger le provider delphi.

Le fait est que ce comportement à partir du 90 000 eme enregistrement est étrange, je m'attendais à un ralentissement exponentiel.

[budtucker]

En fait, le gros soucis de Windows est que lorsqu'il y a dans un temps très court des données alouées puis vidées plusieurs fois de suite, il finit par ne plus gérer correctement. Vista n'a pas évoluer de ce côté je pense !?! Peut être qu'il faudrait investiguer de ce côté là !!

A l'époque, lorsque je developpais des applications avec Delphi (sur de vieilles machines), il était très gourmand en mémoire pour de simple requête sur Paradox ou DBase.

Ce que je conseille est d'utiliser directement soit Postgre (faire des scripts en Perl), soit Paradox pour importer ou exporter les données. Une application tierce ne fera que lire puis écrire les données d'une base de données à une autre.

Lorsque tu seras sur Postgre, tu remarqueras alors toute sa force lorsque tu arriveras dans des cas assez complexe ou sur la gestion de grandes quantités de données. Sa force repose surtout sur une bonne gestion des index.

A+

[HumanTool]

D'accord je commence à mieux cerner le problème...
Merci pour ta réponse en tout cas !

une dernière question, Quand tu dis "une bonne gestion des index" cela signifit quoi exactement ? bien les choisir ? ou y a t il un paramétrage à connaitre ?

De plus, j'ai essayé la même appli sur la même base postgre mais dépourvu de clé primaire et index, or là tout se déroule bien :
107016 enregistrements -> 224562 millisecondes -> soit environ 3.74 minutes au total
dans l'autre cas :
107016 enregistrements -> temps exponentiel à partir de 90 000 qui tend à dépasser la demi-heure.

Donc il me manque un élément pour comprendre..........

[budtucker]

D'accord je commence à mieux cerner le problème...
Merci pour ta réponse en tout cas !

une dernière question, Quand tu dis "une bonne gestion des index" cela signifit quoi exactement ? bien les choisir ? ou y a t il un paramétrage à connaitre ?

De plus, j'ai essayé la même appli sur la même base postgre mais dépourvu de clé primaire et index, or là tout se déroule bien :
107016 enregistrements -> 224562 millisecondes -> soit environ 3.74 minutes au total
dans l'autre cas :
107016 enregistrements -> temps exponentiel à partir de 90 000 qui tend à dépasser la demi-heure.

Donc il me manque un élément pour comprendre..........

Désolé, si je n'avais pas répondu, c'est que je ne connais pas la raison pour laquelle le temps de réponse devient plus long.

Ce qui est sûr, c'est que pour Postgre comme pour n'importe quel SGBD-R, il est important de définir les index. Entre autre, les clés étrangères.

Il faut définir (car il y en a beaucoup qui ne le font pas) également les clés primaires.

Dans Delphi, (j'utilise actuellement Turbo Delphi, mais c'est pas mieux) le moteur qui est utilisé (BDE) et que tu dois forcément rajouter dans chacune des install de tes applications (et qui pèse une tonne) est carrément trop long pour attaquer une base de données toute simple. D'ailleurs je n'ai jamais compris la raison. Lorsque l'on utilise des applications web qui attaquent les mêmes type de BDD, celles ci sont beaucoup plus rapide. Si tu as le choix, mieux vaut créer une application de gestion sous forme web (php, jsp, asp) plutôt que delphi.

Une chose est sûr, il ne faut pas faire de comparaison entre Paradox et Postgre. C'est comme faire une comparaison entre un vélo et un avion !! Les 2 ont leurs utilisations spécifiques. Mais quoi qu'il en soit, je te conseille Postgre !!!!!!

A+

[HumanTool]

En effet je pense que je vais passer à Postgre.
J'ai refait mes tests en insérant 1000 enregistrement sur une table vide, puis j'ai migré la table en entier pour avoir une table rempli(environ 100000 enregistrements) et j'ai réinsérer 1000 enregistrements. Ainsi j'élimine les problème dû à windows.
Résultats je divise mes temps par 4 face à paradox.....

Merci pour tes réponses

[hpalpha]

petite précision, un phénomene de ralentissement apparait quand on fait beaucoup d'insert sans commiter, une parade est de mettre un truc du genre "if i mod 10000 then execsql('commit;begin work"); ".
sous zeos, il faut faire gaffe a l'autocommit, ca commit a chaque insert, je conseil de desactiver et de commit tous les 10000 ou plus, c'est plus rapide.

[HumanTool]

certes, mais je suis en 3 tiers sous delphi donc c'est la méthode ApplyUpdate de l'objet TClientDataSet que j'appelle en fonction du changecount. Tout est donc géré par les composants delphi.
De plus j'utilise le driver pge mais en version demo et les 'commit' sont limités par paquets de 15....
Mais merci pour l'info