Framework qui charge la DB en mémoire .. vos expériences ?

Bonjour,

je développe des frameworks depuis 15 ans professionnellement (et avant pour le fun). Quand je dis "des", c'est que dans les 3 entreprises ou je suis passé, j'ai dû développer "mon" framework.

Le principe ou j'en suis arrivé, c'est de tout charger en mémoire ; je le fais avec succès depuis 10 ans, les limites mémoires de mes projets ont eu la chance d'être réglées par l'évolution hardware.. 4 Go aujourd'hui, c'est rien !

J'ai commencé par utiliser Hibernate.. enfin une partie d'Hibernate pour charger les données (pour moi ça se limitait à faire select * from matable), pas de jointure... donc Hibernate est devenu très vite un bottleneck, que j'ai fini par redévelopper pour faire la même chose en optimisé pour mes besoins.

Toutes les API de cache que j'ai trouvées sont du cache partiel, et donc ils mémorisent pour chaque object des dates de dernier accès, etc.. etc.. bref, sur 1 millions d'objets en mémoire, ça fait vite beaucoup de choses "Inutiles".

Je fais essentiellement des extranets de gestion de produits.. les produits ont donc une arborescence de composants et chacun a ses propriétés, ses images, ses documents, etc.. bref un parcours d'arbre en mémoire est tellement facile à développer, maintenir et rapide.. Surtout quand vous devez retrouver par exemple tous les couples de cadran, aiguille différents qui vont sur les montres qui ont un mouvement mécanique (la requête SQL devient vite lourde).

bref, pourquoi je vous raconte tout ça ? Car je suis un peu le seul "créateur" dans mon entreprise, j'ai 10 développeurs sous mes ordres qui utilisent mon framework comme si c'était normal...

J'ai atteint un niveau de sophistication assez poussé (j'ai des index, des clés, des relations, etc.. ) .. bref un cache qui ressemble à une base de données en fait.

Le seul problème, c'est la consommation mémoire. Je suis souvent obligé d'utiliser la base de données qui est standard chez mes clients, et, helas, c'est souvent Oracle qui est pour moi, très lent.

Bref, qui a de l'expérience dans ce genre de framework ? Je doute être le seul à mettre tout le catalogue produits en mémoire ... je charge facilement plusieurs Go de données en mémoire au démarrage du serveur.

Voilà, je cherche donc des développeurs avec qui échanger sur le sujet et partager nos expériences...

J'aimerais bien utiliser terracotta dans le but, par exemple, d'avoir un socle commun (une jvm pour gérer les utilisateurs, clients, etc..) à mon portail et que chaque application du portail tourne dans sa propre JVM et puisse utiliser des objets du socle commun.

Hello,

Perso je tourne aussi avec 80% des données en mémoire et j'utilise simplement une DB postgresql pour le stockage persistant et pour recharger l'état au démarrage de l'application.
Pourquoi avoir choisi ce modèle? Car j'ai des contraintes sévères en terme de temps de réponse (mon produit est un service web), j'ai moins de 10ms par requête donc je n'ai pas le loisir de faire des accès disques.
Ensuite les données générées ne sont qu'à des fins de statistique, donc en perdre une partie à cause d'une panne reste acceptable.

Certes, certains comptes utilisent etre 300mo et 32go de mémoire. Mais ça reste gérable compte tenu des contraintes. En général un client qui débarque avec un catalogue de 2 mo de produits il comprend facilement qu'il faut un serveur plus baraqué que s'il en avait juste 300.
En contrepartie, le moteur est super rapide et les charges sont facilement absorbées, il y a aucune surprise venant d'outils ou frameworks qu'on maîtrise pas bien. Bref c'est un choix qui se défend, j'en suis persuadé.

Ayant développé durant des années des grosses applications en faisant du tout BDD, je me rends compte qu'en fait ce n'était pas toujours très judicieux de se priver de ressources disponibles et finalement peu onéreuses pour économiser des heures et des heures d'optimisation.

J'ai une question con mais si tu maintiens un graphe d'objet pourquoi parler de base de données ? Quelle propriété souhaites-tu ? ACID, réplication, répartition, conservation, etc.

Concernant le maintien en mémoire, il existe de nombreux SGBD mémoire : Derby, Berkley DB, etc.

Concernant la structure, les bases de données NoSQL sont une alternative au relationnel.

Concernant les framework de mapping, il en existe des beaucoup plus souples comme Apache Commons DBUtils, iBatis, ...

Concernant les caches, il faut en premier lieu définir les stratégies, et ensuite les mettre en place. Les implémentations JPA offrent souvent des interfaces pour surcharger le comportement par défaut. Sa dépend hautement de la "volatilité" des données et l'importance de leur obsolescence.
Il me semble qu'il existe des APIs de cache qui gère des débordements mémoire, il suffirait dans ton cas de garder ça dans un fichier ou une base de données. Mais tu couperas pas à la définition de priorité (en général Least Recently Used) pour savoir ce que tu sors en premier de ton cache.


Sinon il existe des framework de répartition de charges qui permette de répartir intelligemment les données sur plusieurs serveurs, un peu à la manière d'un RAID5.


Tu devrais peut-être jeté un oeil à Apache Cassandra ?

J'ai deja bosse avec un outil qui chargeait tout (a partir de fichier textes, eux meme extraits d'une base oracle) en memoire dans une BerkeleyDB (ct en perl a l'epoque, t'as une version java maintenant).

On chargeais plusieurs Go sans problemes (juste a configurer le kernel pour permettre des processus avec une taille > 4Go). C'etait rapide en effet, mais faudrais que tu fasses un essai pour comparer avec ton propre framework, tes volumes et l'utilisation que tu en fais.