Compare SAP HANA with Oracle Exadata

【前言】
本文的最终观点:如果不是拿全公司的产品线来混合搭配,如果仅就一款产品而言,无论其它厂商如何宣传,目前整个IT业界还没有任何一款一体机产品能跟Oracle Exadata同场较量,TeraData不能,IBM PureSystem不能,SAP HANA也同样不能。而SAP HANA可能更应该拿自己去跟Exalytics作比较,而不是Exadata。

本文对于SAP HANA的认知来自于“SAP HANA Essentials eBook”以及Experience SAP HANA站点,完全属于纸上谈兵,如果有更熟悉SAP HANA技术的技术人员认为本文有失偏颇,欢迎指正。

【正文】
需要承认SAP HANA的出现,在理念上与Oracle Exadata几乎是完全一致的,SAP也意识到大量的数据要从缓慢的磁盘子系统中读取到计算资源中,这部分读取操作成为了最大的性能瓶颈,解决方法就是在计算时减少不必要的IO。对此,SAP HANA的解决方案是跳过磁盘层,通过压缩,将大量数据完全放到内存中,当然于此相配套的还有一些对于数据持久化的技术解决方案,但是无论如何,HANA作到的只是内存间计算而已,能够做到这一点,几乎完全得益于硬件的发展,如果不是当前内存容量剧增而成本却持续下降的话,几乎无法想象HANA能够成为普遍的企业级解决方案。

而与HANA相比,很明显Oracle Exadata在磁盘层读取技术上进行了大量创新,Smart Scan以及Storage Index等技术,都是更有意思的创造,从这一点而言,Oracle的创新更大,作为内存数据库+内存分析解决方案的Exalytics提供了跟Exadata的完美连接,如果需要分析的数据过于庞大而无法完全放置在Exalytics的内存中,那么仍然可以通过Exadata中的压缩,并行,智能扫描等创新技术来加速存储在磁盘中的数据的计算。这是一套更完善的解决方案,也更适合企业IT架构更平滑的过渡。

我们可以简单地认为SAP HANA是一个内存数据库解决方案(这可以与Oracle TimesTen相比较),或者称为内存计算解决方案(这可以与整合了Oracle BI,Oracle TimesTen以及Essbase的Exalytics相比较),这与Exadata的定位以及地位完全不一样。

说的更直白一些,凭着内存足够大,将数据都放到内存中,来获得计算速度的提升,这算什么创新的本事?内存大了,哪家数据库厂家花点儿心思在持久化保存上,都能这么干,这样并无核心竞争力。

以下列出一些分散的并不成体系的关于SAP HANA和Oracle Exadata的观点,同样,欢迎点评及讨论。

1. SAP HANA中列式表和行式表的转换也许是一个亮点。我想Oracle在Exadata中应该借鉴。

2. HANA迄今为止只支持报表应用,因此维护大并发需要的事务锁机制这个最大的技术难点目前看SAP还没有任何解决方案,那么这样的产品并不能与Exadata相提并论。事实是这样的:一直到2012年之前,SAP HANA的解决方案都称为SAP BW Accelerator,这需要一个独立的HANA数据库来完成BI报表,直到SAP BW 7.3 SP5 on SAP HANA的出现,HANA可以当作主数据库使用,不但是查询,而且企业数据改变也直接访问HANA,但这也仍然只是面对数据仓库以及BI领域的应用,这时候被称为SAP NetWeaver BW Powered by SAP HANA(说实话,这名字真够长的)。迄今为止HANA还未能宣布支持真正OLTP应用的案例。

3. HANA的数据持久化机制从文档上看,并无任何特殊之处,几乎与Oracle完全一样,通过将提交的事务写入log,来保证断电重启以后,可以重演log,这就是Oracle的redolog写机制。

4. 成本比较,HANA的硬件成本更贵,因为需要的内存更大;而同时只要企业真正业务产生的最原始数据是需要通过数据传输/同步手段(无论这个传输过程标称如何快速、如何实时)转移到HANA中的,HANA就还需要表复制,表同步的时间和人力成本;还需要额外的手段将SAP应用的相关报表数据迁移到HANA中,即使SAP宣称有快速的最佳实践部署方式,但是只要一种方式可以被称为solution,那就不会太简单。

5. SAP把HANA视为革命性地创新,试图打造一个围绕在HANA周边的原厂,合作伙伴,客户共同创造新应用的生态圈,虽然我们需要承认内存计算导致的应用延迟降低,确实具有其革命性的潜质,但是我仍然认为SAP期望过高。
HANA的多合作伙伴硬件一体机架构,可能会导致混乱。虽然SAP限定了CPU型号(Intel E7),内存型号(Samsung),以及操作系统版本(SUSE Linux SLES 11),但是每家合作伙伴的硬件设计工艺都不尽相同,服务能力也有差距,而SAP自身是否有足够能力同时保证七个硬件厂家(目前7家合作伙伴是Cisco, Dell, Fujitsu, IBM, HP, Hitachi, NEC)产品上运行HANA的性能,质量,可用性的测试认证,这也存在疑问。这并非一体机的好模式。

6. SAP的优势在于从ERP应用往下层延升,试图进入新一代数据库市场,而Oracle本来就占据数据库市场霸主地位,Exa系列的推出拓展了一片新的一体机天地,看看能否借助这样的优势,往上层延升,获得更大的ERP应用市场份额。

7. 在文档中多处看到了以Apple为例,看来Apple才是现今各种创新的源头,大家都从Apple那里学习和借鉴。各大厂商实际上都在尽量整合自己的解决方案,历来都如是,所以如果从这个意义上而言,其实从来就不缺乏一体机的概念。不过你有办法想象苹果的成功会来自于苹果提供iOS,指定芯片类型,而由三星或者诺基亚来制造手机吗?所以看上去Oracle在学Apple,而SAP在学Google的Android策略。

最后,有两个疑问能否有人帮我解答?
1. HANA的后台持久化磁盘存储也是共享磁盘,这是需要一个SAN磁盘阵列吗?那么一个HANA集群中的多个数据库实例是通过Share Everything的方式来共享访问这个存储?
2. 如果一个HANA节点挂掉了,这部分数据全部重新加载到备用节点的内存中,这个过程大约要花多长时间?我现在获得的数据是每秒钟扫描100TB数据集中的1000亿条记录(这个说法实在模糊,是扫描100TB数据还是扫描1000亿条记录,1000亿条记录又是多大数据?),每分钟可以加载1600万记录到内存中,这样的话,一秒钟扫描的数据也需要加载10小时才行?

6 thoughts on “Compare SAP HANA with Oracle Exadata

  1. adam says:

    难得见到有比较HANA和Exadata的文章,我补充几点关于HANA的现状和定位,可能和kamus的说法不太一致。
    一、HANA在OLTP领域的应用:这一点SAP应该还是投入了很大力气去研发、推广,现在SAP的ERP ON HANA的解决方案已经基本完成,就是把SAP的ERP后端oracle关系型数据库完全替换为HANA,目前正在找用户做实际案例的推广,所以在这方面在半年到1年时间会有实际的案例供大家参考。目前ERP ON HANA的成熟度还不高,我了解到做试点的用户要求数据库容量大小最好不超过2T,可以看出SAP推HANA还是比较谨慎的。
    二、HANA和ERP后台数据库的同步:除了ERP ON HANA这种彻底的替代方案外,SAP还支持一种“HANA应用加速器”的用法,在SAP的ERP中可以在应用层透明的将热点数据替换成HANA,数据同步使用SAP的SLT技术完成。这一点完全是因为是ERP和HANA都是SAP开发才能做到,通过应用程序的改造,做到应用级别的数据同步,大概的原理就是将写入db的数据放到一个内存消息队列中,以近实时的速度写入到HANA中。
    三、HANA的成本:主要的成本不是硬件,使用PC SERVER,再贵也比小机便宜多了。关键是软件,HANA的授权是按照数据量来的,64G为一个unit,投入完全与数据量大小成正比。
    四、HANA的技术优势:主要就是内存数据库+列式数据库的混合体,使用内存数据库补偿了列数数据库在更新性能的不足,而列式数据库的数据压缩特性也大大降低了对内存容量的要求(SAP宣称有5-30倍的压缩率),虽然说不上是什么颠覆性的创新,但这两个特性组合起来还是不错的。
    五、HANA的前景:按照HANA在SAP应用软件整合方面的优势,加上SAP对自己产品数据库使用HANA的刻意引导,估计在未来3-5年内,会有不少巨型的企业在SAP的产品中使用HAHA。但其他领域就比较困难了,应用整合困难,成本高这两方面的问题会极大的制约HANA的推广。

  2. kamus says:

    **@adam**
    非常感谢对于我的文章的补充,实际上在经过一段时间的再学习和思考以后,也意识到文章中的某些观点确实有失偏颇,但是在此并不作修改,也是给自己留一个底儿。
    如果根据你的补充(HANA=内存数据库+列式数据库的混合体),给HANA打个分,满分是100的话,HANA目前大约可以拿到70,确实是很不错的产品。

  3. Miss_Bonbon says:

    最近在做两者的对比,重点学习HANA的时候发现,HANA的持久化磁盘存储并不是共享的,备份系统是共享的,所以当一个server挂掉后,他只需要远程搭载(并非physically load上去)挂掉服务器所对应的数据备份文件即可,所以感觉效率应该也还可以~ 共同学习,欢迎指正。

  4. Chris_LJ_Liu says:

    kamus,您好
    关于你在这篇文章中最后提到的”如果一个HANA节点挂掉了,这部分数据全部重新加载到备用节点的内存中,这个过程大约要花多长时间?”这个问题我还是挺感兴趣,在Experience SAP HANA站点上找到了一篇文章”SAP HANA – High Availability”中的内容或许能够回答您的问题
    如果是在多个SAP HANA数据库节点进行Cluster,他们最好使用共享存储有点类似oracle的rac,如果一个节点crash,HANA通过Host auto-failover和IP重定向(和Oracle的rac VIP)技术异曲同工来保障业务的连续性,同时HANA在在节点复制的时候(特别是同步复制)会把相关主节点数据的状态信息放到备用节点中(这样做就是保障一旦主节点发生故障,备用节点能在非常短的时间内接管工作RPO是0,RTO是几秒钟或几分钟),多以从源库中实际载入HANA中的数据量并不大.

    我个人认为:HANA在数据库的体系架构和timesten相差甚远,目前能做的野象你说的职能进行OLAP的应用

    也欢迎您对我的观点进行批评指正

  5. Kamus says:

    @Chris_LJ_Liu
    感谢对于本文的补充。
    共享存储这一点在持久化存储上是可以理解的(虽然你说的跟上面的Miss_Bonbon所做的comment有些冲突),但是如何保障备用节点的内存中也有所需要的数据(这可能是几十TB的内存),这是比较大的问题。我不确认你说的“相关主节点数据的状态信息放到备用节点中”是不是指所有数据都在主备内存中同步,如果是,那可能是可以做到几秒钟的RTO,但是这种同步的开销应该不小。虽然HANA不太支持OLTP,但是当OLAP应用大批量加载数据的时候,主备内存都要有响应,也是一份双倍的开销。
    BTW,今年10月份OOW上发布了Oracle 12c In-Memory Option,是对HANA的极大挑战。

  6. Kamus says:

    @adam
    你提到内存数据库+列式数据库,这两个特性组合起来还是不错的。而今年10月份OOW上Oracle刚刚宣布的Oracle 12c In-Memory Option正是如此的一个产品,一个列式缓存,这一举解决了持久化存储是列式所带来的不支持OLTP的劣势,而又用到了列式结构对于OLAP应用的加速,并且这又是一个内存结构。对于SAP HANA而言,是一个强劲的对手,而且,这个Option还可以跑在Exadata上。

Leave a Reply

Your email address will not be published. Required fields are marked *