2013年4月18日，第四届中国数据库技术大会(DTCC 2013)在北京福朋喜来登酒店正式拉开序幕，现场座无虚席。4月18日下午，在内存数据库的分会场上，来自上海新炬网络技术有限公司的交付中心副总监王科先生发表了题为《Oracle TimesTen企业级应用实践》的精彩演讲。

本次演讲，王科重点介绍了TimesTen如何通过缓存为Oracle 数据库加速;TimesTen的高可用架构如何实现和高效运行;如何与应用系统架构结合满足大并发、高实时性的业务需求;此外，他还通过实践案例与大家逐一分享。

熟悉网购的朋友，恐怕对促销打折并不陌生，比如每年的双11与双12活动，让厂家，快递公司，消费者忙个不停。不过，并不是所有的电商应用都如此给力，实际上，大部分电商都经历过网站运行缓慢，甚至宕机的现象。而这一切，都与应用系统架构、网络带宽、数据库架构存在千丝万缕的联系。试想一下，当应用系统性能成为企业业务发展壮大的制约因素时，企业该如何选择?

那么，针对应用、网络、数据库IO造成的性能瓶颈，TimesTen能做些什么呢?不妨先来了解一下TimesTen的概念与功能。

Oracle TimesTen In-Memory Database (TimesTen) 是一个功能完备、经过内存优化的关系数据库，它具有持久性和可恢复性。它为应用程序提供了即时响应和极高的吞吐能力，可以满足数据库密集型应用程序的需要。TimesTen部署在应用程序层，运行在完全装入物理内存 (RAM) 的数据库上。应用程序使用标准 SQL 接口访问 TimesTen 数据库。对于现有应用程序数据存放于 Oracle 数据库中的客户，TimesTen 作为内存中缓存数据库来部署，可自动完成 TimesTen 与 Oracle 数据库之间的数据同步。

TimesTen也有自己的日志文件，以及存放日志文件的目录(LogDir)，缺省的就是和DataStore放在同一个目录下。但一般建议分开放。日志的概念和Oracle的一样，在回滚以及恢复的时候，都会用到它。

从Oracle的官方数据得知，TimesTen数据库事务吞吐量差不多是Oracle的10倍，这正如它的名字一样。因此可见，对于高并发、实时性要求高的应用，TimesTen是一种理想的选择，能解决数据库层的瓶颈问题。

另一方面，TimesTen完全可以作为共享库的方式，嵌入至应用程序内部，这相当于节省了网络传输带来的时间延迟，如下图所示：

TimesTen 从某种角度上来看，也是一种 Cache 机制，是磁盘数据库的 Cache，通过物理内存中的数据存储区的直接操作，减少了到磁盘间的 I/O 交互。举个例子，以下SQL演示的是Oracle数据库中，取得有500次购货记录的的客户姓名与地址，并且缓存到TimesTen中。

当TimesTen充当Oracle数据库的缓存，或者说与Oracle数据库构成主从关系时，支持两者的双向数据自动同步，具体表现为四种模式：

1.只读模式：指的是在Oracle数据库中更新，异步复制到 TimesTen可以自动刷新Oracle数据库的更新。只读模式适合更新不多的场合。

2.同步写入模式：在TimesTen中更新，然后同步传播到Oracle数据库。同步写入模式适合仅想高速化SELECT的场合。

3. 异步写入模式：在TimesTen中更新，然后异步传播到Oracle数据库,适合高速化 SELECT 以及 DML的场合。

4. 用户自定义模式。

从部署的角度，TimesTen支持独立部署、缓存部署、与RAC联合部署三种模式，如下图所示。

相对而言，前两种方式非常好理解，而最后一种方式的出发点是高可用性与负载均衡。以高可用性为例，如下图所示。读写缓存在Active节点提交事务，而事务将自动并行复制到Standby节点，在Standby节点将事务并行写到后端Oracle数据库;读缓存将Oracle数据库变更的数据刷新到Active节点，更新的缓存数据并行复制到Standby节点。如此一来，即便后端Oracle数据库宕机，前端TimesTen应用不受影响。

总之，无论是磁盘数据库，还是内存数据库，无论是Oracle数据库，还是TimesTen数据库，都不存在绝对的好与坏。正向演讲者王科介绍的那样，合适的产品加合理的运用才等于最大的效能。