Skip to Content

我们知道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这样一种hybrid整体无法比较,只能用Exalytics与HANA对比才是apple to apple.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply