使用Terracotta作为持久性解决方案

使用Terracotta作为持久性解决方案(替换数据库)会是个好主意吗？我特别想知道数据完整性问题和对事务系统的支持.

Terracotta是事务性的(同步块形成修改对象的事务)但不是也不希望符合JTA.有交易的一个相当长时间的讨论和有关兵马俑一些常见的误解在这里.

我写了一篇关于数据生命周期的博客文章,以及如何构建您对识别使用兵马俑的机会的想法.简而言之,Terracotta的最佳位置是您需要持久性和可用性的用例(您的应用程序可能崩溃,但您仍然需要数据)但数据不一定是长期关键的.

规范示例是在Web应用中的用户会话的上下文中重要的数据,例如购物车信息.您希望保持该数据的持久性,以便在您的Web应用程序崩溃时,维护购物车.但购物车本身可能会或可能不会被购买.因此,您将它存储在Terracotta中直到它被购买,然后将其作为"记录系统"数据保存到数据库中.

从历史上看,您存储在数据库中的数据始终是"记录系统"数据,这对您的业务的长期成功至关重要:客户,订单等.使用当今的"无状态"架构(实际上并非无状态) ,我们将所有中期数据推送到数据库.这意味着我们不必要地惩罚我们的数据库(有额外的工作和存储)和我们的开发人员(他们必须处理对象 - 关系阻抗不匹配,即使使用ORM).更好的方法是将其留在对象中并使用Terracotta进行聚类.最近一些Terracotta用户使用这种技术来显着减少他们的数据库占用空间(节省数百万美元),同时提高他们的扩展能力.

存在与数据库的集成点以及如何可靠地进行切换的问题.我们在最近发布的Examinator(Spring/Terracotta/Tomcat/MySql参考Web应用程序)中看到了这个用例.考试进行时,状态(问题答案,随机选择顺序,标记为复习的问题)存储在Terracotta中.但是,当考试完成后,计算结果分数并将其长期存储在数据库中.

为了安全地执行此操作,我们使用Hibernate密钥策略,首先在Terracotta中的对象中生成数据库行id,然后将数据保存到db,然后从Terracotta中删除.如果应用程序在保存到数据库之后但在从Terracotta中删除之前崩溃,则此方案具有潜在的竞争条件.在这种情况下,应用程序可能会尝试将数据重新保存到db,可能会创建两行.但是由于预先生成的ID,我们可以判断该行是否先前已成功写入并避免该问题.

总之,我认为Terracotta不会很快取代您的数据库.在大多数商店中甚至被认为是这样的新操作.使用模式有所不同.堆中没有查询或SQL功能(您的查询功能由对象模型定义).我认为它可以并且开始取代中期数据使用,它是一种更便宜,更容易的替代方案.但是,有些人开始尝试长期存储.