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