Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Cache de donnees
Bonsoir,
Je suis en ce moment en train d’implémenter un standard pour un projet d’école.
Il y a une base de données et il y a beaucoup d’opérations sur la base qui seront effectuées (surtout des opérations de lecture).
On m'a conseille de créer un cache et j'aimerais en savoir plus la dessus.
Dans quel cas utilise t-on un cache? Comment implémenter un cache?etc...
Merci d'avance
On implémente un cache lorsqu'une action est déterministe et couteuse en temps.
Si tu bosses dans l'ecosysteme Java, jette un coup d'oeil sur le framework EhCache
Salut,
Dans votre cas, le cache répondra à la place du serveur de base de donnée.
Le gros du boulot n'est pas tellement de mettre en place la techno de cache mais de savoir quelles sont les données que vous allez mettre dans le cache, comment les mettre à jour,...
Et surtout à quels endroits vous allez les mettre en œuvre.
Dans une application Web vous avez en général 5 unités de traitement:
1= le navigateur
2= le serveur HTTP
3= l'application
4= le SGDB
5= les disques.
Vous pouvez mettre en œuvre une mécanique de cache à chaque niveau. Le principe étant que chaque requête qui ne pourra pas être traitée "localement" par le cache, mettra plus de temps.
- W
Merci pour les réponses.
C'est exactement ça, le cache répondra a la place du serveur de base de données.
Mais dans mon cas, toutes les informations sont nécessaires souvent.
Ce que j'avais pense c'est de charger toute la base de données en mémoire au lancement du serveur. Laissons de cote la place en mémoire que ça pourrait prendre.
Ma question c'est comment réalise t-on cela? Est ce pas mieux de le faire manuellement, en créant une classe Cache (singleton) dans la couche DAL et de tout charger au démarrage dans des collections(le choix du type de collection sera important pour les performances)?
La question est que se passe-t-il en cas de crash, i.e. vous faite quoi de la fonction de persistance de la BDD dans ce cas?Envoyé par Miko95
Il n'y a pas de problème technique pour réaliser cela regardez comment on réalise une fonction appelée memoize dans votre langage de programmation préféré et l'API avec le "fonctionnel" est bouclée.Ma question c'est comment réalise t-on cela? Est ce pas mieux de le faire manuellement, en créant une classe Cache (singleton) dans la couche DAL et de tout charger au démarrage dans des collections(le choix du type de collection sera important pour les performances)?
Mais la durée de vie des données "cachées" et leur mise à jour reste à définir et c'est la dessus qu'il y a le plus de boulot à faire car spécifique aux traitements et au cycle de vie des données associées.
Exemples: X entre une nouvelle commande, Y la verra quelque minutes plus tard... Mais X se ravise et modifie la commande.... Est ce qu'Y travaillera longtemps sur une commande qui n'est plus d'actualité?
Pour entrer une nouvelle commande, X aura certainement besoin d'accéder au catalogue produit, aux prix,... ces informations changeant peu souvent on peut tolérer qu'une mise à jour ne soit pas prise en compte dans la minute...
- W
Je ne sais pas si j'ai bien compris, mais a chaque modification (ajout de données, modification de données), on modifie d'abord la base de données puis on charge les nouvelles données en cache. Pour la lecture, on accède directement au cache sans passer par la base de données car on suppose que le cache contient toute la base de données.
Les opérations d’écritures sont beaucoup plus rares que les opérations de lecture.
Si X entre une nouvelle commande, Y la verra après que la commande ait été charge de la BDD vers le cache. Idem pour la modification. Je comprends que c'est un problème, qu'avant que le cache soit mis a jour, certaines données ne sont peut être plus d’actualités.
Quelle est la solution dans ce cas?
Il n'y en a pas de simple.
Chaque fois que vous allez mettre une ligne de la base de donnée à jour, il faut éventuellement "invalider" l'entrée qui pourrait être dans le cache pour que la prochaine lecture "rafraîchisse" l'entrée.
Ce qui suppose savoir faire une mise en correspondance entre les lignes de cache et les lignes des tables de la BDD. Ce qui suppose la mise "en ligne" entre le cache et la BDD pour supporter la mécanique d'invalidation.
- W
PS: Utiliser des solutions qui marchent plutôt que flipper à chaque incident... mais en fonction de vos traitements "les solutions qui marchent" sont toujours sous optimales.
Quelles sont donc ces solutions qui marchent?
Yo Eight vous a suggéré de regarder EhCache.
On connaît sans doute mieux memcache.
Sinon vous avez des solution "propriétaires".
Un SGDB sait cacher les lignes de la BDD et ce cache peut généralement être "tuné" plus ou moins finement en fonction du SGDB.
Dans ce cas, le cache est côté SGDB et la pénalité sera le temps "réseau".
Memcache installe un cache entre l'application et le SGDB.
Si l'application est distribuée sur plusieurs serveurs, le cache sera "global" est une partie des accès sinon tous seront "externes": il n'est pas certain que ce soit mieux que le cache SGDB.
- W
Merci pour la réponse.
Cette méthode ne résout pas mon problème. Je m'explique. Le problème est que lorsque le serveur reçoit une requête pour créer une ligne dans la base de données, il crée donc la ligne dans la base puis la charge dans le cache. Si pendant le temps durant lequel la ligne n'est pas encore dans le cache, le serveur reçoit une requête pour créer la même ligne dans la base de données, il n'a aucun moyen de vérifier dans le cache si la ligne existe déjà ou pas.Il n'y en a pas de simple.
Chaque fois que vous allez mettre une ligne de la base de donnée à jour, il faut éventuellement "invalider" l'entrée qui pourrait être dans le cache pour que la prochaine lecture "rafraîchisse" l'entrée.
Ce qui suppose savoir faire une mise en correspondance entre les lignes de cache et les lignes des tables de la BDD. Ce qui suppose la mise "en ligne" entre le cache et la BDD pour supporter la mécanique d'invalidation.
Vous allez me dire que la base de données détectera l'erreur. Mais dans mon modèle de données, j'utilise pour chaque table une clé "artificiel" auto générée. Donc l’unicité des lignes de mes tables est a vérifier sur des champs hors clé primaire. Vous allez me dire que c'est le rôle des contraintes UNIQUE. Le problème est que les champs qui permettent d'identifier de manière unique mes lignes se trouvent dans des tables différentes. Mon post explique le problème en détail. La solution qui m'a été proposée est d'utiliser des triggers de type INSTEAD OF mais le problème est que c'est un projet open source et je dois donc utiliser une base de données open source comme MySQL (qui ne gère pas les triggers INSTEAD OF). Donc je me suis dis ok, je vais assurer l’unicité en vérifiant si l'information existe avant(SELECT). Mais voila que ça ne fonctionne pas au niveau du cache a cause du temps entre la mise a jour de la base et la mise a jour du cache.
Pensez vous que EhCache ou autre peut résoudre ce problème?
J'ai préfère vous ramener le problème avant pour ne pas qu'a la fin je me retrouve avec une solution qui ne marche pas.
Merci
L'histoire de la correspondance entre ligne de cache et lignes de tables est pour vous permettre de comprendre la mécanique et les points à traiter.
Il ne faut pas la prendre au premier degré: seuls peut être les caches CPU travaillent ainsi.
Une optimisation "flux" et mise en œuvre de cache s'aligne rarement spontanément avec des constructions objets "standards".
Lorsque je travaille sur ces questions, je considère l'ensemble des objets métiers (l'utilisateur voit-il autre chose?) et des traitements et j'essaie de mettre le modèle de donnée 'en tension' pour qu'il suive.
C'est un vrai travail de bout en bout qui peut remettre en cause des choix de design côté schémas des tables, etc..
Intuitivement si l'objet métier est en bijection avec une ligne de table, c'est simple (voir "active record pattern"). Lorsque c'est "composite", il faudra trouver des solutions "à la carte" ou casser un peu...
Ceci dit vous n'êtes peut être pas obligé de maximiser l'utilisation du cache: regardez les traitements les plus fréquents et les données qu'ils utilisent.
- W
PS: En relisant votre pointeur, hibernate doit avoir une mécanisme de "cache" qui pourrait répondre en partie.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager