一年前，一个在Oracle工作的朋友，提起了Timesten，并且告知我，他们的timesten已经在很多的实时系统中开始推荐使用，而且包括一些银行系统，也开始尝试着用timesten进行生产，也就记下了这个Timesten，并且马上下载了Timesten的数据库，安装在自己的机器上，结合Timesten的文档，开始摆弄起来这个产品。
不过那个时候，还是在公司里上班，也就是利用空余的时间学习和琢磨这个东西，并没有总结下来，由于平时公司和自己都是使用Oracle，也不好使用TImesten，隔以时日，知道上个月看到CSDN里的朋友，发了一个有关Timesten的求助的帖，才有一次重拾以前对Timesten的初识，重新复习和回顾了以前对TImesten的认识，并且也帮助新认识的客户，清理了他们对Timesten的使用上的错误，并对其Timesten的服务进行了规划和优化，从而解决了他们的问题，也提高了自己。
在这里我将持续的对Timesten关注，并把自己对Timesten的认识总结下来，以作参考。
首先我们还是从概要上了解Timesten这个产品。
Timesten是内存数据库，是Oracle的一个产品，Oracle在数据库这块有三个主要产品。
一个就是Oracle，一个就是这里要介绍的Timesten，还有一个就是Oracle berkeley db, 这个我在一个csdn的回帖里曾经提到过，这三个产品都是数据库产品，但是其主要面向的功能和实施的体系互不相同，所以三者并不冲突。
Oracle是我们传统的数据库，Timesten是以性能为优先的内存数据库，而Berkeley是嵌入式数据库。所以三者完全应用于不同的应用架构中，解决不同的问题。
我们这里主要介绍的Timesten的主要的体现上就是完全的内存进行数据库的存储，所以提供了更优的性能。
1992年HP试验室开始了Timesten项目，该项目主要针对电信网络应用，对内存数据库进行一些深入的研究。 到1996年，该项目的主要成员自立门户，(呵呵呵，好像很多伟大的产品都是如此，比如Oracle源自于IBM的DB2团队，SAP源自于Oracle团队，Pointbase也是源自于Oracle团队成员Scott，C#的首席架构师也是Bill从Java的首席架构师挖过来的) 独立成立自己的公司。在当年发布了Timesten的第一个商用版本2.0，2001年该产品增加了Cache connect组件，提供了In memory的方案和Oracle集成，提供Oracle的cache功能。也就慢慢被Oracle关注，2005年6月16日，Oracle和Timesten达成收购协议，从此Timesten正真的被整合成为Oracle的产品之一， 2009年7月29，Oracle宣布正式推出Timesten 11g和Timesten 11g In-memory database cache，Timesten正式开始走上商业之路。
Timesten通过改变数据在内存中的位置的方式来提供高性能的实时服务，把数据全部加载到内存中进行管理，通过对数据结构和数据访问的算法的优化，使得数据库能够以效率最高效的执行数据的操作，并且Timesten可以嵌入到应用中，这样可以避免进程通信或者是socket通信带来的一些不必要的性能损耗，从而进一步提高了数据库的访问性能。Timesten可以用于in-memory和Oracle集成，也可以客户端/服务端的调用，同时支持事务，和一致性读和commit写的事务隔离级别，并且支持表锁，行锁，在内存管理中也有latch的支持，从而提供稳定的并发性的处理，和完全满足工业生产需要的并发机制和特性。提供了JDBC和ODBC的接口支持，使得开发人员很容易使用其进行数据库上的开发。同时在高级特性上，Timesten支持replication和恢复的功能，这些也是工业生产中所必须具备的特性。
以下是Timesten的支持
in memory database cache集成
sql 92
jdbc odbc
replication
restore recovery
import export
consistance read and commit write
这里的特性足以让工业生产使用，不过目前对Timesten做很深入研究的人还是少数的，不过我想在11g的Oracle产品规划中，这个Timesten的出现势必会有很的人关注进来，所以Timesten的技术势必会吸引更多的技术人员的研究和客户的青睐。
其他的主流内存数据库
ALTIBASE
SolidDB
eXtremeDB
下一片Timesten的文章，我们将从Timesten的安装开始，带领大家一下开始Timesten的实践之旅。
