使用 Terracotta 作为持久性解决方案 [英] On using Terracotta as a persistence solution

问题描述

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

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.

推荐答案

兵马俑是 事务(同步块形成修改对象的事务)但不是也不希望符合 JTA.此处对交易和一些关于 Terracotta 的常见误解进行了相当长的讨论.

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.

我写了一篇关于数据生命周期的博文 以及您应该如何思考确定使用 Terracotta 的机会.简而言之，Terracotta 的最佳点是您需要持久性和可用性(您的应用程序可能会崩溃但您仍然需要数据)但数据不一定是长期关键的用例.

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.

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

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.

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

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.

存在与数据库的集成点以及如何可靠地进行切换的问题.我们在最近发布的 Examinator(一个 Spring/Terracotta/Tomcat/MySql 参考 Web 应用程序)中将此视为一个用例.当考试正在进行时，状态(问题的答案、随机选择顺序、标记为审查的问题)存储在 Terracotta 中.但是，当考试完成时，会计算得出的分数并长期存储在数据库中.

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.

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

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.

总而言之，我认为 Terracotta 不会很快取代您的数据库.它在操作上太新了，甚至在大多数商店中都不能被视为如此.使用模型大不相同.堆中没有查询或 SQL 功能(您的查询功能由您的对象模型定义).我认为它可以并且正在开始取代中期数据使用，因为它是一种更便宜、更容易的替代方案.但是，有些人开始尝试将其用于长期存储.

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屋！