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….