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é...