Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 4 sur 4
  1. #1
    Candidat au titre de Membre du Club
    Inscrit en
    février 2010
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : février 2010
    Messages : 5
    Points : 12
    Points
    12

    Par défaut 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.

  2. #2
    Expert Confirmé Sénior
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 698
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 698
    Points : 6 227
    Points
    6 227

    Par défaut

    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.

  3. #3
    Modérateur
    Avatar de Nemek
    Homme Profil pro Logan
    Architecte technique
    Inscrit en
    août 2005
    Messages
    2 053
    Détails du profil
    Informations personnelles :
    Nom : Homme Logan
    Âge : 29
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte technique
    Secteur : Transports

    Informations forums :
    Inscription : août 2005
    Messages : 2 053
    Points : 4 212
    Points
    4 212

    Par défaut

    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 ?
    Java : Forum - FAQ - Java SE 8 API - Java EE 7 API
    Articles sur Ceylon : Présentation et installation - Concepts de base

    ECM = Exemple(reproduit le problème) Complet (code compilable) Minimal (ne postez pas votre application !)
    Une solution vous convient ? N'oubliez pas le tag
    Signature par pitipoisson

  4. #4
    Membre régulier
    Homme Profil pro
    Développeur Java
    Inscrit en
    mars 2012
    Messages
    37
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : mars 2012
    Messages : 37
    Points : 76
    Points
    76

    Par défaut

    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.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •