Qu'en est-il en utilisant une base de données pour contenir données temporaires entre web app transitions? Est-ce une pratique normale?
La base de données possède en effet déjà un cache. Une application de conception de puits devrait essayer de tirer parti pour réduire le disque IO.
Le cache de base de données fonctionne au niveau des données. C'est pourquoi d'autres mécanismes de mise en cache peuvent être utilisés pour adresser différents niveaux. Au niveau java, vous pouvez utiliser le cache de deuxième niveau d'hibernation, qui peut mettre en cache des entités et obtenir des résultats de requête. Cela peut notamment réduire le réseau IO entre l'application. serveur et la base de données.
Ensuite, vous voudrez peut-être évolutivité horizontale, c'est-à-dire, ajouter des serveurs pour gérer la charge. Dans ce cas, le cache de deuxième niveau doit être distribué entre les noeuds. Cela existe (voir cache JBoss), mais peut être légèrement compliqué à gérer.
La mémoire cache distribuée tend à mieux fonctionner si elle a un schéma plus simple basé sur clé/valeur. C'est ce que memcached est, mais il y a aussi d'autres solutions similaires. Le plus gros problème avec les caches distribuées est invalidation des entrées périmées - qui peut elle-même se transformer en un goulot d'étranglement de la performance. Ne pensez pas que vous pouvez utiliser un cache distribué tel quel pour que vos problèmes de performances disparaissent. Concevoir une architecture distribuée évolutive nécessite de l'expérience et est toujours une question de compromis entre ce qu'il faut optimiser et non.
Pour revenir à votre question: pour application régulière, il n'y a pas à mon humble avis d'un cache distribué. Disque IO disque et réseau IO conduisent généralement à des performances décentes.
EDIT
Pour les objets non persistants, vous avez plusieurs options:
- Le
HttpSession. Les objets doivent implémenter Serializable. La manière exacte dont la session est gérée dépend du conteneur. Dans un cluster, la session est généralement répliquée deux fois, de sorte que si un nœud se bloque, vous en avez toujours une copie. Il y a ensuite affinité de session pour router la requête vers le serveur qui a la session en mémoire.
- Cache distribué. Un système comme
memcached peut en effet avoir du sens, mais je ne connais pas les détails.
- Base de données. Vous pouvez bien sûr vider n'importe quel objet
Serializable dans la base de données dans un BLOB. Peut être une option si les serveurs Web ne sont pas aussi fiables que le serveur de base de données.
Encore une fois, pour application régulière, je voudrais essayer d'aller aussi loin que possible avec le HttpSession.
@ewernli Merci pour une réponse complète. Peut-être que j'ai mal lu votre réponse, mais il y a des objets dans mon application qui ne sont pas persistés, alors qu'en est-il de ces objets. Voulez-vous dire que nous pouvons concevoir des tables spécifiques pour contenir de telles données temporaires en utilisant Hibernate et l'utiliser à la place du cache de niveau 2? Mon point est, je parle d'objets non persistants, qui n'ont pas de représentation db, qui sont créés seulement pendant la durée de vie de la session et sont détruits lorsque l'application est quittée. – EugeneP
Ah! Je me suis trompé et j'ai affiné ma réponse un peu. Pourquoi le 'HttpSession' n'est-il pas suffisant pour vous? – ewernli
Pour dire la vérité, j'ai entendu qu'utiliser HttpSession pour tenir des objets relativement gros n'est pas une bonne idée, mais après avoir lu votre réponse, je vois qu'il peut être utilisé et devrait être utilisé. Corrige moi si quelque chose. – EugeneP