Discussion :

[Ceubex]

Bonjour,

J'ai fais un test pour voir les performances de mes insertions dans la base sqlite d'un de mes programme Java (au début la base est vide). Mais les performances semblent varier beaucoup au fur et à mesure que cela grossit

Voici le graph des performances (nb d'enregistrements fonction du temps) et la vitesse d'enregistrements à la seconde qui est divisée par 10 !!



Cela est pour moi un obstacle
Y aurait-il un moyen d'améliorer cela ?

Merci d'avance

[Jacobian]

tu peux faire une description détaillé de ton programme java ?

[_skip]

Salut Ceubex,

J'ai fait quelques tests depuis une application C++ il y a quelques années sur Sqlite, effectivement, lors d'une importation de masse, les performances étaient phénoménales lorsque la base était vide ( + de 5000 par sec.), en revanche, s'approchant du million, ça devenait catastrophique, tombant parfois à 50/sec.

En fait, mes recherches m'avaient conduit à la conclusion que c'était parce que la vérification des contraintes (doublons et co...) se faisaient uniquement par des btree et non des hash index. De ce fait, les tests nécessaires aux nouveaux ajouts se multipliaient, sans parler du disk trashing.

En fait je ne sais pas ce qu'il en est dans les versions actuelles donc ce que je dis est à prendre avec des pincettes. Sinon en premier lieu si c'est pas déjà fait, essaie d'utiliser un cache_size assez gros.

[Ceubex]

Ok merci pour l'info skip
Oui le cache size ça change un peu les choses mais ça n'est pas non plus le jour et la nuit.
N'y a-t-il pas moyen de désactiver la vérification des contraintes dont tu parles ?

[_skip]

C'est bien possible, bon il restera toujours la clef primaire. De toutes façons dans mon cas, puisque l'importation était pas une routine one shot mais un truc qui allait devoir s'exécuter chaque jour, je voulais à tout prix conserver la possibilité de rejeter des enregistrements donc désactiver les contraintes était un risque trop gros.

J'ai malheureusement pas vraiment de solutions... Il y a des articles un peu partout sur l'optimisation mais souvent ça demande des recompilations et ça a des effets de bord.

[OButterlin]

Il est possible que le problème vienne de la base de données proprement dite.
Je verrais bien un problème de maintenance d'un chemin d'accès...

[Ceubex]

Je vais chercher pour l'optimisation
OButterlin, je ne comprends pas ce que tu veux dire

[OButterlin]

En fonction de la base de données, on peut avoir des problèmes sur les chemins d'accès, suite à des insertions massives, qui disparaissent après une reconstruction du CA.
En ce qui concerne SQLITE, c'est une supposition, rien d'absolu, je ne l'utilise pas...
Une autre piste est peut être la mémoire disponible qui diminue...
Tu utilises la même transaction pour tous les enregistrements ?
Si oui, essaye de fragmenter les commit (si c'est possible), par exemple par groupe de 1000 enregistrements.

[newstarsandy2010]

it is too difficult for me !!

[Jidefix]

J'avais déjà constaté la même chose sur une base MySql...
Les deux solutions que j'ai trouvé ont effectivement été d'utiliser les batch au lieu de faire un executeUpdate par ligne, et surtout de désactiver/supprimer les contraintes (mais encore faut-il garantir extérieurement qu'elles sont respectées)