Serait-ce une bonne idée d'utiliser Terracotta comme solution de persistance (en remplaçant une base de données)? Je m'interroge spécifiquement sur les problèmes d'intégrité des données et la prise en charge des systèmes transactionnels.Sur l'utilisation de Terracotta comme solution de persistance
Terracotta est transactional (les blocs synchronisés forment des transactions d'objets modifiés) mais n'est pas et ne veut pas être compatible avec JTA. Il y a une discussion assez longue des transactions et quelques idées fausses communes au sujet de Terracotta here.
J'ai écrit un blog post about data lifetimes et comment cela devrait encadrer votre réflexion sur l'identification des possibilités d'utilisation de Terracotta. En bref, le sweet spot de Terracotta est le cas d'utilisation où vous avez besoin de persistance et de disponibilité (votre application peut tomber en panne mais vous avez toujours besoin des données) mais où les données ne sont pas nécessairement critiques à long terme.
Un exemple canonique est celui des données importantes dans le contexte d'une session utilisateur dans une application Web, telles que les infos du panier. Vous souhaitez conserver ces données persistantes afin que, si votre application Web tombe en panne, vous gérez le panier. Mais le panier lui-même peut ou ne peut jamais être acheté. Donc, vous le stockez dans Terracotta jusqu'à ce qu'il soit acheté, puis sauvegardez dans la base de données en tant que données "système d'enregistrement". Historiquement, les données que vous avez stockées dans une base de données étaient toujours des données du «système d'enregistrement» qui étaient essentielles au succès à long terme de votre entreprise: clients, commandes, etc. Avec les architectures «apatrides» d'aujourd'hui (qui sont vraiment 't apatride), nous transférons toutes les données à moyen terme dans la base de données. Cela signifie que nous punissons inutilement notre base de données (avec un travail et un stockage supplémentaires) et nos développeurs (qui doivent gérer la discordance d'impédance relationnelle objet, même en utilisant ORM). Une meilleure approche est de le laisser dans des objets et de le grouper avec Terracotta. Un certain nombre d'utilisateurs récents de Terracotta ont utilisé cette technique pour réduire considérablement leur empreinte de base de données (en leur économisant des millions de dollars) tout en augmentant simultanément leur capacité à évoluer.
Il y a la question du point d'intégration avec la base de données et comment rendre le transfert fiable. Nous avons vu cela comme un cas d'utilisation dans la publication récente Examinator (une application Web de référence Spring/Terracotta/Tomcat/MySql). Lorsque les examens sont en cours, l'état (réponses aux questions, choix aléatoires, questions marquées pour la révision) est stocké dans Terracotta. Mais lorsque les examens sont terminés, le résultat obtenu est calculé et stocké à long terme dans la base de données. Pour cela, nous utilisons une stratégie de clé Hibernate qui génère d'abord l'identifiant de la ligne de base de données dans l'objet en Terracotta, puis enregistre les données dans la base de données, puis les supprime de Terracotta. Ce scénario présente une condition de concurrence potentielle si l'application se bloque après l'enregistrement dans la base de données mais avant de supprimer Terracotta. Dans ce cas, l'application pourrait essayer de réenregistrer les données dans la base de données, en créant éventuellement deux lignes. Mais en raison de l'ID pré-généré, nous pouvons dire si la ligne a déjà été écrite avec succès ou non et éviter ce problème. En résumé, je ne pense pas que Terracotta remplacera bientôt votre db. Il est trop nouveau pour être considéré comme tel dans la plupart des magasins. Le modèle d'utilisation est très différent. Il n'y a pas de requête ou de capacité SQL dans le tas (votre capacité d'interrogation est définie par votre modèle d'objet). Je pense que cela peut et commence à remplacer l'utilisation des données à moyen terme là où c'est une alternative beaucoup moins chère et plus facile. Cependant, certaines personnes commencent à l'expérimenter pour le stockage à long terme.
La terre cuite est uniquement Java. Si cela vous convient d'être enfermé dans cette technologie, sans la possibilité d'écrire simplement des scripts (sans la JVM) dans d'autres langues, alors allez-y.
L'article Kill Your Database with Terracotta était vraiment sympa.