【前言】 本文的最终观点：如果不是拿全公司的产品线来混合搭配，如果仅就一款产品而言，无论其它厂商如何宣传，目前整个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….