初探TimesTen与HANA

我们知道HANA的直接竞争对手是Exalytics和Exadata，而Exadata很多是硬件层面的创新，所以在SAP ERP on HANA之前，还是比较用于OLAP分析的Exalytics有一些意义。由于HANA是行存储列存储混合存在的完整一体机，而Exalytics的软件部分是由TimesTen和Essbase组成的，所以我们分别研究做简单比较。由于我并不是数据库专家，也不为了推销任何产品，所以目的只是单纯的想了解两方的产品，不免有不准确之处。

 

TimesTen的资料很多，下面是我大概浏览过的

http://www.oracle.com/technetwork/products/timesten/overview/index.html

http://wenku.baidu.com/view/a47d19f09e31433239689317.html

http://wenku.baidu.com/view/bfb40a0f52ea551810a687ae.html

 

首先，TimesTen是90年代源于HP实验室，于2005年被Oracle收购的。想想这数据库存在的时间如此之久，当初真的是很创新的产品。

TimesTen是行存储的关系型内存内数据库。而SAP HANA的行存储部分也是由历史悠久的MaxDB置于内存内. MaxDB源于70年代，在90年代被SAP收购。关于TimesTen，已经有大量的用户（由于其存在时间较长），而HANA本身年龄还小，目前主要客户应用是OLAP而非OLTP，所以TimesTen相对是经过时间考验的。同样，由于这个原因，TimesTen有很多实际的数据，而HANA关于OLTP的提升数据，可能只有BusinessOne.

 

基本上TimesTen是通过将数据置于内存内并针对内存访问优化算法达到性能提升，关于这点，与HANA并无过大区别。但是HANA强调的不仅仅是内存内存储数据，还有内存内计算。我认为，ERP on HANA不仅仅要解决open-SQL支持HANA的问题（技术上来说，只要open SQL支持了HANA，那么现有ABAP应用就可以跑在HANA上），更重要的是将部分应用层的计算推到HANA一层来做。这是BW on HANA和BPC on HANA能获得性能提升的一个重要因素。

除此以外，ERP on HANA还要能够解决一些技术问题，比如行存储表在HANA启动初就全部加载到内存（将来应该要按需加载），这会造成内存浪费和启动时间过长，还有我假想行存储和列存储在ERP on HANA中都应派上用场，但是怎么利用好，是个问题（HANA行列存储可转换 同步以及做join操作）。

由于TimesTen主要是做为一个通用的数据库产品，而HANA首先定位还是服务于SAP自己的应用，所以TimesTen并不会像HANA那样内置很多应用库，所以应用不会从内存内计算这里获得太大益处，但是它更加通用。

 

TimesTen，所有的数据都在内存内，所以能够加载的数据总量受物理内存限制。HANA是具有持久层的。最新的SP包过后HANA的行存储表是否默认加载到内存，我需要确认，但是如果这个问题解决了，HANA按需加载使得它可以加载更多的数据。

 

TimesTen支持数据复制功能，以此来获得负载均衡以及高可用性。关于这一功能，我认为HANA功能更强，它是真正的cluster，一个数据表可以partition到不同的节点上，CPU并行计算，以此发挥硬件的能力。同时，因为有持久层，所以并不需要靠数据复制来获得高可用性。

 

TimesTen所支持的连接方式很丰富。除了常见的client server方式外，推荐的是将TimesTen与应用程序至于同一个box中，应用程序的shared lib控制对TimesTen的操作。除此以外，TimesTen连接Oracle也是不错的选择，这样TimesTen就成了Oracle DB的一个高速缓存。而HANA没有这么多连接场景，SAP的方向是对SAP产品的广泛的支持。

 

其它关于TimesTen的架构及技术细节，从上面的链接都可以获得。作为一个有一段历史的数据库，还是很强大的。但是我们也可以看到TimesTen本身并不比HANA行存储（我暂且叫做MaxDB in memory）强很多，所以与HANA整体无法比较。