java - 关于使用 Terracotta 作为持久性解决方案

Question

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

Answer 1

Terracotta 是事务性的（同步块形成修改对象的事务），但不是也不希望符合 JTA。这里有相当长的关于交易的讨论和一些关于兵马俑的常见误解。

我写了一篇关于数据生命周期的博客文章，以及它应该如何构建您对识别使用 Terracotta 机会的思考。简而言之，Terracotta 的最佳点是您需要持久性和可用性（您的应用程序可能会崩溃但您仍然需要数据）但数据不一定长期关键的用例。

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

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

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

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

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

Answer 2

兵马俑仅是 Java。如果您可以被锁定在这项技术中，而不能只用其他语言编写一些脚本（没有 JVM），那么就继续使用它。

这篇文章用 Terracotta 杀死你的数据库非常好。