Hello World !
 
Je développe actuellement un script en Java qui fait à peu près ceci :
 
 Pour chaque élément de ma table A j'effectue le traitement suivant
    Je récupère en fonction de l'algorithme des données dans diverses tables (B, C, D et E)
    Je réalise mes calculs
    J'enregistre le résultat de mon calcul dans la table E
 
 
Tout marche bien, parfait.
 
Pour la BDD, j'utilise JDBC (DB MySQL) et mes objets sont instanciés à l'aide d'un ResultSet.
 
Par contre, c'est beaucoup trop lent. Ma table A contient ~200k items, et le traitement réalisé sur chacun de ces items prend environ 1 seconde.  
 
Les calculs effectués sont relativement simples et d'après mes tests prennent maxi 5ms.
 
Le problème vient logiquement de la BDD. Que ce soit la lecture au début du traitement, ou l'écriture à la fin.
 
Je cherche donc améliorer les performances du script.  
 
J'ai commencé à réfléchir au problème et deux solutions sont apparues jusque là :
- placer les données MySQL en ramdisk
- ne travailler qu'avec des instances des objets de la base (les appels BDD sont remplacés par des appels à des objets instanciés, la persistance ne se faisant qu'en fin de script)
 
Avez vous d'autres pistes ?
 
Concernant les deux premières, quelques questions :
 
- ramdisk
J'ai vu des tutos sur comment faire, mais ce n'est pas perenne. Comment et à quel moment sauvegarde réellement les données sur le disque ?
 
- instances
J'imagine qu'il existe des librairies ? Comment est gérée la persistance (inscription réelle en BDD) ?
 
Merci d'avance  

Sans le code et la nature des données, difficile de t'en dire plus que quelques pistes génériques (dans l'ordre) :
 
1. Mesurer (à toutes les étapes d'ailleurs), les solutions sont différentes si le bottleneck intervient lors de la lecture ou de l'écriture
2. Optimiser ton algo
3. Optimiser tes requêtes
4. Perso, c'est seulement après les points précédents que je commencerais à regarder les solutions extérieures que tu évoques
 
Tu as certainement déjà regardé tout ça, mais t'as pas moyen de merger tes étapes 1 et 2 à coup de jointures ? Pour l'étape d'insertion (table E), tu as testé du bulk insert en fin de traitement ?
Jette un œil à HikariCP également, ça déboite

La notion de seconde ne veut rien dire : il faut le découpage entre la(les) lecture(s) et la(les) écritures.
 
Tu pourrais nous dire la nature des requêtes de select pour le/les item(s) (Select de "masse" avec jointure, select imbriqués, ... ) et la nature des requêtes d'écriture (Update, Insert, ...?) et/ou l'utilisation ou non des bonnes pratiques ("prepared Statement", autocommit "off" pour ne pas commiter à chaque MàJ, ...)
 
Sans ces éléments difficile d'aider "réellement", mais néanmoins qq remarques  
 
L'utilisation de RAMDISK peut être un gain, mais si c'est lié à l'algo lui même (des full scans ou des allez-retour avec la BDD trop "nombreux" à cause de requête imbriqués sans utilisation de prepared Statement, commit à chaque update/insert), tu ne gagneras probablement pas suffisamment.
 
Pour ce qui est d'utiliser une couche ORM, normalement, elle ne fait que rajouter de l'overhead (surcoût) par rapport à du JDBC et n'est pas forcément plus simple à "tuner". L'ORM est surtout la pour apporter de la souplesse, de la portabilité (travailler avec plusieurs back-ends avec le même code "métier" ) et de la maintenabilité...