由上表可见HANA具有非常出色的数据压缩能力，在不加索引的情况下能将外部的CSV格式的文件压缩4.37倍。可见列式数据库在数据压缩方面的优越性。需要说明的是这次ORACLE的版本是11g R2, 也用到了其最新的行式压缩技术，但跟HANA比起来明显不是一个层次的。

3） 查询性能

用qgen产生22个SQL查询语句并对其做了简单的语法调整，例如调整ADD_MONTHS等时间处理函数，尽量不改变语句原来的结构。将这22个查询复制到SAP HANA Studio的SQL Editor中运行即可获得每个查询语句执行的时间。

测试结果以及和ORACLE对比如下（单位：毫秒ms）

提高倍速 ＝ ORACLE的执行时间 ／ HANA的执行时间

可以看到HANA每个查询都比传统的行式数据库快很多，22个查询总体时间也正好是ORACLE的十分之一。对于有些查询，速度提升非常明显，例如第19和20个查询。深入调查发现这2个查询都涉及到对最大表lineitem的查询和聚合计算。可见HANA对越大的表查询提升的性能越明显。例外情况是第21个查询，虽然也涉及到了对lineitem的查询，但该语句包含了3次lineitem的自连接（self-join），进一步深入发现凡是对lineitem有join操作的 SQL查询HANA的性能都表现得相对不尽如人意。可见HANA对join处理还需要进一步提高，SYBASE IQ在这方面有许多值得HANA去借鉴的地方。

4） 增量更新

这次增量更新也是更加偏向于性能，而不是我们通常要求的ACID原则。先通过以下语句删除表lineitem中的6000000行记录：

DELETE FROM VINCENT.LINEITEM WHERE L_ORDERKEY BETWEEN 1 AND 6000000;

删除6000000记录耗时29秒。

用dbgen –s 1重新产生第1到6000000行记录的CSV文件，上传到HANA服务器上（/media/tpc-h1/），用以下导入命令完成对数据的加载：

IMPORT FROM '/media/tpc-h1/lineitem.ctl' WITH THREADS 10 BATCH 50000;

update VINCENT.LINEITEM MERGE DELTA INDEX;

跟初始导入所不同的是，这次导入是不会锁表的，并且有主码重复的检查和索引的同步更新消耗。导入时间40秒，融合时间为124秒。可以看出增量更新的速度（36000行每秒）不如初始导入时候的速度（97000行每秒），不过这个速度也是相当不错的。融合（MERGE）过程耗去了大部分的时间。

总结：

这次拿ORACLE和HANA做对比，没有任何贬低ORACLE的意思。ORACLE是传统RDBMS的翘楚，它代表了在这个领域最好的技术；而HANA是主存数据库的代表，是SAP孤注一掷的筹码。这样的对比能让我们更加清楚的看清未来数据库的发展趋势。也许熟悉ORACLE的人会说最新的版本11g支持并行查询，或许能获得和HANA相差不多的查询性能。但我们更应该看到主存数据库强大的潜力。SAP不大可能一蹴而就，但它似乎正在按照自己的步骤一步一步向前。在一次针对销售的培训上，我向一位德国的顾问提问“为什么不把HANA架构在云上？”，他半开玩笑的说：“啊！SAP应该马上把你招进来。实际上我们正在朝这个方向发展，但现在这种情况只是个开始。”

实际上我已经看到了BW on HANA，这也确实向大家证明：至少现在Netweaver平台是可以完全运行在HANA上的。我也知道 HP的硬件目前可支持16个节点8 TB容量的内存。因此我也有理由相信Hasso真能带领着他的200人近卫军改变当前沉闷的氛围和乏味的游戏规则。Business Suite on HANA 将是R4, Business ByDesign on HANA将是R5, HANA on Cloud就是R6, …… 希望SAP的Realtime能一直坚持下去，能给我们足够的惊喜！