使用Terracotta作为持久性解决方案 [英] On using Terracotta as a persistence solution
问题描述
使用Terracotta作为持久性解决方案（替换数据库）会是个好主意吗？我特别想知道数据完整性问题和对事务系统的支持。
Terracotta是 transactional （同步块形成修改对象的事务）但不是也不是想要符合JTA标准。有关交易的相当冗长的讨论以及关于兵马俑的一些常见误解此处。 / p>
我写了有关数据生命周期的博客文章以及如何构建您对识别使用兵马俑的机会的思考。简而言之，Terracotta的最佳位置是您需要持久性和可用性的用例（您的应用程序可能崩溃，但您仍需要数据）但数据不一定是长期关键的。
规范示例是在Web应用中的用户会话环境中重要的数据，例如购物车信息。您希望保持该数据的持久性，以便在您的Web应用程序崩溃时，维护购物车。但购物车本身可能会或可能不会被购买。因此，您将其存储在Terracotta中直到购买，然后将其作为记录系统数据保存到数据库中。
从历史上看，您存储在数据库中的数据始终是记录系统数据，这对您的业务的长期成功至关重要：客户，订单等使用今天的无状态架构（实际上并非无状态），我们将所有中期数据推送到数据库。这意味着我们不必要地惩罚我们的数据库（有额外的工作和存储）和我们的开发人员（他们必须处理对象 - 关系阻抗不匹配，即使使用ORM）。更好的方法是将其留在对象中并使用Terracotta进行聚类。最近一些Terracotta用户使用这种技术来显着减少他们的数据库占用空间（节省数百万美元），同时提高他们的扩展能力。
有问题与数据库的集成点以及如何可靠地进行切换。我们在最近发布的 Examinator （Spring / Terracotta / Tomcat / MySql参考Web应用程序）中将此视为用例。考试进行时，状态（问题答案，随机选择顺序，标记为复习的问题）存储在Terracotta中。但是，当考试完成后，计算结果得分并长期存储在数据库中。
为了安全地执行此操作，我们使用Hibernate密钥策略，首先在Terracotta中的对象中生成数据库行id，然后将数据保存到db，然后从红陶。如果应用程序在保存到数据库之后但在从Terracotta中删除之前崩溃，则此方案具有潜在的竞争条件。在这种情况下，应用程序可能会尝试将数据重新保存到db，可能会创建两行。但由于预先生成的ID，我们可以判断该行是否先前已成功写入并避免该问题。
总之，我不认为兵马俑将很快替换你的数据库。在大多数商店中甚至被认为是这样的新操作。使用模式有所不同。堆中没有查询或SQL功能（您的查询功能由对象模型定义）。我认为它可以而且正在开始取代中期数据使用，它是一种更便宜，更容易的替代方案。但是，有些人开始尝试长期存储。
Would it be a good idea to use Terracotta as a persistence solution (replacing a database)? I'm specifically wondering about data integrity issues and support for transactional systems.
Terracotta is transactional (synchronized blocks form transactions of modified objects) but is not and doesn't want to be JTA-compliant. There is a fairly lengthy discussion of transactions and some common misconceptions about Terracotta here.
I wrote a blog post about data lifetimes and how that should frame your thinking about identifying opportunities for the use of Terracotta. In short, Terracotta's sweet spot is the use case where you need persistence and availability (your app could crash but you still need the data) but where the data is not necessarily critical long term.
A canonical example is data important in the context of a user session in a web app, such as shopping cart info. You want to keep that data persistent so that if your web app crashes, you maintain the shopping cart. But the cart itself may or may not ever be purchased. So, you store it in Terracotta till it's purchased, then save to the database as "system of record" data.
Historically, the data you stored in a database was always "system of record" data that was critical to the long-term success of your business: customers, orders, etc. With today's "stateless" architectures (which really aren't stateless), we shove all the medium-term data down to the database. This means we are needlessly punishing our database (with extra work and storage) and our developers (who have to handle the object-relational impedance mismatch, even if using ORM). A better approach is to leave it in objects and cluster it with Terracotta. A number of recent Terracotta users have used this technique to significantly reduce their database footprint (saving them millions of dollars) while simultaneously increasing their ability to scale.
There is the question of the integration point with the database and how to make the hand-off reliably. We saw this as a use case in the recently released Examinator (a Spring / Terracotta / Tomcat / MySql reference web application). When exams are in progress, the state (answers to questions, randomized choice orderings, questions marked for review) is stored in Terracotta. But when exams complete, the resulting score is calculated and stored long-term in the database.
To do this safely, we use a Hibernate key strategy that generates the database row id in the object in Terracotta first, then saves the data to the db, then removes from Terracotta. This scenario has a potential race condition if the app crashes after saving to the database but before removing from Terracotta. In that case, the application could try to re-save the data to the db, possibly creating two rows. But due to the pre-generated ID, we can tell whether the row was previously successfully written or not and avoid that issue.
In summary, I don't think Terracotta will replace your db anytime soon. It's too new operationally to even be considered as such in most shops. The usage model is way different. There is no query or SQL capability into the heap (your querying capability is defined by your object model). I think it can and is starting to replace the mid-term data usage where it's a far cheaper and easier alternative. However, some people are starting to experiment with it for long-term storage.
这篇关于使用Terracotta作为持久性解决方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
