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小时才行?

Expert Oracle Exadata译者序

从去年8月份到现在,我跟KayaJacky合译的《Expert Oracle Exadata》,如果不出意外,应该可以在5月底出版。在出版以后,计划以ACOUG的名义和博文视点联合举办一些现场的发布活动,目前还在筹划中。

我个人从这本书的翻译中获益良多,甚至在最近的这次大数据量、短停机时间的数据库迁移项目中就开始使用书中介绍的Exadata迁移方法,虽然我的这个项目并没有Exadata,但是仍然可以从书中描述的通用的迁移解决方案和优化手段中得到启发。所以,我想无论是不是在使用Exadata,这本书都值得期待。下面是为我的译者序。

译者序-Kamus

这本书的翻译计划是从2011年8月份开始的,据我所知,最早是博文视点的编辑“侠少”找到阿里巴巴的张瑞(Jacky)和甲骨文的黄凯耀(Kaya),然后Jacky再找到我。

实际上,我个人开始想要翻译这本Exadata技术书籍倒是从更早的时候就开始了,这本书在Amazon上的发行日期是2011年8月9日,其实早在2011年2月份已经有另外一本关于Exadata性能的书籍(Achieving Extreme Performance with Oracle Exadata,作者全部是Oracle公司员工),但是论作者的知名度,仍然是本书更受人关注。最早知道这本书是从本书联合作者Tanel Poder的个人技术Blog中,那是2011年3月份,Tanel发文说已经可以Apress网站上购买新书的Alpha版本,Tanel是全球最受人尊重的Oracle技术专家之一,而一本技术书籍可以预先购买Alpha版本也是很稀奇的事情,再加上Exadata正是当今IT界的当红炸子鸡,理所当然这本书非常值得期待。在2011年4月份,我个人跟某出版社联系过,表达了如果该书可以引进中国,那么我很愿意组织人手进行翻译的工作,对方的回复是正在谈版权,之后没有消息。然后,Tanel在6月份发文说,本书已经即将定稿,再之后,就是8月份,该书正式发售。而在正式发售的当月,博文视点就开始寻找中文版本的译者,可以说是非常迅速。而版权的猜测,那一定是博文视点拿到了版权,而某出版社失利了。:-D

以上的情况,让我收到Jacky的邀请以后,毫不犹豫地接受了工作,无论工作如何繁忙,我都愿意这本书的中文翻译者里有我的名字,这对于我而言可以说是一种荣幸。2011年8月17日收到这本书的PDF电子版(当然后来又收到纸质版),从8月份开始,Kaya,Jacky和我都迅速地投入了翻译的工作,在整个过程中,通过不断地沟通,我们按照每个人的经验和对各个章节的熟悉程度以及感兴趣程度,大致是均分了各个章节。我负责翻译的章节是一、二、四、六、十三、十六章,原本我给自己定下的计划是每两周翻译一章,那么最快可以在2个月内完成翻译,再加上校稿,本来计划在3个月内可以完成所有的翻译,也就是如果一切顺利,这本书的中文译本应该在2011年年底的时候就跟大家见面了。但是,计划永远是赶不上变化的,除了工作的繁忙和个人的懒惰,我们几个译者还都在其它方面出现了这样那样的意外情况,导致整个翻译工作整体滞后。所幸,还不算太迟,我想在你们看到本书的时候,这个世界上应该还没有更新的Exadata书籍可以参考。所以,这本书仍然是迄今为止想要了解Exadata,想要使用Exadata,想要监控调整Exadata的最佳参考书籍。

Oracle Exadata的举世独步,对整个数据库硬件/软件市场的震撼,在全球或者仅仅是中国国内的引人瞩目,乃至热销,这已经无需赘言。作为数据库从业者,也许你没有听过Netezza,也许你没有听过Twinfin,也许你没有听过Hana,但是你一定听过Exadata,这绝不仅仅是由于Oracle公司一贯的好战、勇于进攻、大力宣传的风格,而是Exadata确实具有独步天下的功能。也许我们不能说在经过最精细地调整以后,Exadata在数据仓库领域与其它竞争对手相比一定具有绝对的优势,但是,不要忘记,在现在这个世界里,又有多少是纯粹的数据仓库系统呢?又有多少用户愿意OLTP用一套系统而数据仓库又用另外一套系统呢?这其中的数据传输开销和系统设计复杂性的开销,如果能够消减甚至是避免,那么又何乐而不为呢?Exadata正是这样的一套软硬件一体的平台,同时支持OLTP类型负载和数据仓库类型负载,通过Oracle Database 11gR2中的资源管理器来更加精细地调控硬件资源,让两种类型的负载都能获得各自需要的资源,并顺畅执行。

如果我们抛却Exadata在存储节点中的软件特性,它使用的各个硬件组件并不是划时代的,无论是Infiniband还是Flashcache/SSD,都已经出现了很久,在企业级市场中也被很多用户在使用了,但是将这些组件放在一起,并且预先调整为一个平衡的系统(没有任何一处明显的性能瓶颈),这是划时代的。Oracle将软硬一体机的概念推广到了开放性平台上,极大地挑战了Teradata的市场,用开放性的硬件+开放性的操作系统+开放性的数据库软件,构造出了一个平衡的,性能超强的平台,这同样是划时代的。

好吧,前面我们提到了“抛却Exadata在存储节点中的软件特性”是吗?这就好比我们说,把皇冠上最闪亮的那颗宝石先摘下来,别闪花了我们的眼睛。现在,我们要把这颗宝石放回去了,智能扫描(Smart Scan),存储索引(Storage Index),混合列压缩(Hybrid Columnar Compression),无论哪一项软件特性都足以震撼数据处理市场,而当他们结合在一起,配合上Oracle Database原本就具有的高性能,再配合前面说的这个平衡的硬件架构,我们就得到了足以颠覆一切固有理念的惊人性能。在Exadata的POC现场,有客户因为实在无法接受Exadata展示出来的飞一般的速度而怀疑Oracle的技术人员在造假。这在无奈的同时无疑也是一种自豪吧。

Exadata的出现,颠覆了一些我们既有的数据库管理理念,但是无论如何,Exadata中运行的是Oracle Enterprise Linux(当然也有Solaris,不过是x86-64版本,至少到目前为止,Oracle还没有计划显示会出现SPARC平台上的Exadata),Linux上运行的是Oracle Database 11gR2,对于所有数据库技术从业者来说,之前积累的操作系统管理知识,Oracle数据库/RAC管理知识都仍然适用。我们需要的只是与时俱进,将Exadata的特有知识点加入我们以前的知识体系中。本书是最佳的入手点,因为本书中不但有Exadata的特性阐述,也同样有使用经验和最佳实践。要知道本书的作者都是真正的Exadata使用者,而本书的Review者(Kevin)更是Exadata的性能架构师(不过,Kevin现在已经离开Oracle公司,加盟EMC,去玩Greenplum了)。

我唯一希望的是,大家在读这本中文译本的时候,不至于产生去重新阅读原著的冲动(虽然,我仍然建议大家去阅读原著),因为如果那样,那只能表示我们的翻译实在是很不适合中文读者的理解。如果你觉得本书优秀,那么基本上可以说这是原作者的功劳,当然,我也希望你们看到我们三位译者的努力。我们在翻译完各自的章节以后,又互相审阅了其他人的章节,我们尽量斟酌每一句话的翻译,希望读起来是符合中文阅读习惯的,对于一些比较难于理解的片段(比如Kevin说的某些话),我们通过邮件跟作者进行了沟通以确保译文是正确体现了作者意图的,对于一些原文较为晦涩的地方,我们也根据自己的理解增加了“译者注”,我相信这也是目前大多数技术书籍的译文中并不常见的,我们甚至在想,如果译者注足够多,那么就可以出一本批注版的书籍了(:-D)。这其中由于Kaya在Exadata中的实战经验尤为丰富,更是付出了格外的精力。你们现在看到的这本Expert Oracle Exadata中文版,应该是全球的最新版本,因为在我们的翻译过程中,不但将本书英文版出版以后提交给作者的错误修订全部都更正到本书中,而且我们还在翻译过程中发现了更多的错误,Kaya通过邮件直接跟三位作者沟通并一一确认,最终对于确实是错误的描述也都全部作了更正。实际上,这也是本书推迟到现在才出版的原因之一。

就在今天,我重新审阅完了自己翻译的第6章,回顾了一下从2011年8月份开始,我们三位译者和博文视点的侠少关于翻译本书的邮件沟通,来来回回将近300封邮件,我相信在本书中文版最终定稿的时候,沟通邮件量一定会超过300封(实际上最终的沟通邮件将近500封)。我们扪心自问,已经尽了自己最大的努力,但是一定还会有这样那样的不足,还望读者海涵。

最后,我要感谢我的妻子和可爱的儿子,在我工作之余的很多个深夜,我仍然在翻译此书,是我的妻子极大地包容了我,没有她的支持,没有她承担的几乎全部家务,和对于我们年仅1岁多的儿子的照料,也许我的翻译进度还会拖后。谢谢你,我爱你们。感谢Kaya,Jacky,还有博文视点的侠少,与你们关于本书翻译讨论的500封邮件是宝贵的财富。感谢我的大学师妹-董楠,她是《老美国志异》、《此地无人生还》、《满是镜子的房间》三本畅销书籍的译者,喜欢摇滚的朋友应该热爱这几本书籍,本书某些段落的措辞有得到她的指教。另外,我同样要感谢我所在的公司-云和恩墨的多位同事,是你们帮我承担了由于翻译工作而拉下的本应属于我的工作,感谢杨廷琨(老杨同时帮助审阅了本书的第一章),感谢盖国强。还有帮助我审阅中文译稿的同事们,仇实、刘洋、余广宏、董禹、宋春风,译稿里面也有你们的功劳,谢谢你们。

2012年2月29日
张乐奕(Kamus)于上岛咖啡,北京。