对于这些问题，Oracle解决方案在某些情况下可能是有用的，并会随着技术的成熟而逐渐改善。风险是，该解决方案被打断到Oracle的数据库集 群业务中。改善该项目的驱动力可能不会很高。
Terracotta
Terracotta似乎会提供以下列表内的所有需求：
◆网络间同步
◆用磁盘保留状态同步
◆透明的
◆快速的
Terracotta解决了笔者想要解决的一切问题，而且用一个优化的透明解决方案进行管理。不需要强制对象执行串行化、不需要进行其他任何类型的 实现改变，它可以透明地工作于虚拟机之下。它通过发送不同的对象而不是整个对象，来设法优化网络使用率。它甚至保留状态与文件系统的同步。总之，是目前最 透明的持久性系统。
唯一需要强调的是，它只支持Java版本，不支持.net。因此，想要使用它，你只能选择Java, Haskell, Scala, Groovy, jRuby, Jython, JavaScript或其他任何可以运行于JVM（Java虚拟机）的语言。
真实的魔术
Terracotta不会进行机器之间不必要的复制。它只做足以提供故障切换保护的工作，其余的事情会按需而做。它甚至会把不使用的数据从一台机器 中剔除。
另外，对于每台新添加到机群中的机器，为每台机器增加有效内存。
当笔者看到类似这样的事，笔者就想知道，除此之外，笔者还会需要数据库为笔者做什么事。
笔者唯一可以想到的是，为数据挖掘和商业智能软件包提供可用数据（或数据仓库）。多数这些工具已经围绕数据库进行设计。
因此，RDBMS有效地成为了一个日志机器。
放弃RDBMS
因此，通过使用由Terracotta所提供的公共收藏（集合/列表/映射），完全可以放弃使用RDBMS。其结果是整洁的（具有更好的可维护性） 代码，更有效的内存使用，和更快的执行时间。
有什么理由不喜欢Terracotta呢？
是否将概念取消？
是否取消使用共享内存的概念，作为摆脱数据库的一种方式。
笔者希望如此。这是一个人人都想拥抱简单的时代。Ruby on Rails, Grails, Spring, Wicket和其他框架的增加已经表明，大多数开发人员已经受够了过分复杂的解决方案。
他们可能会愿意完全摆脱一个复杂的解决方案。
也许，我只是完全错误的
或许RDBMS仍是一个很难移除的角色，可能是由于这个角色担当着重要的任务，有着重要的目的，例如是针对多个程序的集成点（就像Martin Fowler在他的Database Thaw Post中所说的） 。
Fowler实际上是建议建立一个HTTP包围数据库。这就把它从一个集成点转换成了一个应用程序。笔者已经参与了这种类型的应用，它具有一些非常 强大的功能。
本文所说的可能不会适用的另一个领域是数据仓库。但是，把它封装在REST层，将是一个极好的应用。
作为一个针对各种应用的共有方式，不考虑它的实现，为了共享数据，使用RDBMS似乎很难被击败。据笔者所知，Terracotta解决方案可以工 作于基于JVM的应用程序之间。但是，对于其他语言（C / C + + / Smalltalk ）可能是有点困难。
原文：Best alternative to RDBMS and ORMs : Terracotta by Taranfx
