我一直怀疑SAP宣称的主存

有段时间我把更多的注意力放在C-STORE上，一种基于网格(多节点，异地部署)的列式数据库方案。在处理扩展性和可用性方面，它通过Projection Overlapping(射影重叠冗余)技术实现K-Saftey(即能容忍K个节点同时挂掉)；在处理更新操作方面(列式数据库的难点便是更新)，它通过一个巧妙的混合

而HANA从一开始让我更相信它会秉承SAP的传统，以INSTALL-BASE的模式交付，然后靠License获得收入。这种on-premises模式相较于on-demand模式让我觉得它老气横秋。就像那种令人讨厌又根深蒂固的老传统那样值得被唾弃。这种主观的偏见也一直蒙蔽了我，让我没有真正花时间去了解它。这次借和SAP合作培训的机会，我深入的了解这个代表SAP未来，也许是整个企业应用行业未来的主存数据库技术——HANA。

我这里不想累述HANA的具体架构，这些信息大家都可以从SAP发布的官方文档上去了解。SAP也在最近正式发布了 HANA的学术报告。了解后会发现跟我上面所述的C-STORE有许多异曲同工之处。我在这里想给大家一个参照，以帮助大家了解主存数据库到底有多快，以及我们以后该如何抉择？

既然要参照，不能只参考SAP给的数据或者SAP BW等应用跑出的结果。HANA被公布成一种崭新的数据库，那么就让我们用数据库的公开基准测试标准TPC-H来测试它，并将结果与传统的行式数据库(

TPC-H是一个业界公认的数据库性能测试基准，比较公正和中立，它定义了8个标准数据库表:customer, lineitem, nation, orders, partsupp, part, region, supplier，各表之间的关系可见

本次测试HANA的运行环境如下：

硬件HP DL980,  内存512G,  CPU Xeon X7560 2.27GHZ 32核

HANA版本1.00.25.358341

1) 数据加载

用dbgen –s 10命令生成外部的*.tpl文件(CSV格式)， 其中lineitem.tpl文件大小为7.3GB。手工创建对应的*.ctl文件，该文件为HANA所特有的导入参数文件，具体格式如下：

INTO TABLE VINCEN.LINEITEM

From lineitem.tbl FIELDS DELIMITED BY ‘|’

ERRO LOG LINEITEM.tbl.txt

将lineitem.tpl和lineitem.ctl文件上传到HANA服务器上(/media/tpc-h/)，然后在SAP HANA Studio里面打开一个SQL Editor窗口，输入如下命令：

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

WITH TABLE LOCK WITHOUT TYPE CHECK;

update VINCENT.LINEITEM MERGE DELTA INDEX;

WITH THREADS 10 BATCH 50000是指以10个线程并行导入，每50000条提交一次。这个是SAP所推荐的基于列式数据库导入的一个组合，我也尝试过其他组合，得到得结果也差不多。需要注意的是HANA最多容许256个并行线程。WITH TABLE LOCK 和WITHOUT TYPE CHECK同样可以起到加快数据加载速度的效果。最后还需要有个MERGE DELTA INDEX的动作，就像C-STORE一样，为了提高更新速度，HANA是先对一个DELTA index进行更新，然后再将之MERGE到主index上。

以同样的方式对其他表进行数据加载操作。

下表是针对lineitem进行加载的时间对比，单位为秒(s)。HANAORACLE

616680

HANA的时间是import和merge的时间之和。可见在数据加载方面，HANA的性能是不亚于常规ORACLE的。HANA不仅仅是将数据加载到内存中，它还需同时在HDD(硬盘)和SSD(高速闪存)上对数据进行快照存储和日志记录。这方面HANA在保证了数据完整性的同时，也实现了列式数据库更新方面的超越是非常值得肯定的。

在数据加载后设置每个表的主码和创建相关列的索引，用到语句如下：

ALTER TABLE VINCENT.LINEITEM ADD PRIMARY KEY (L_ORDERKEY,L_LINENUMBER);

CREATE INDEX  ORDERKEY1 ON VINCENT.LINEITEM (L_ORDERKEY);

CREATE INDEX  PARTSUPPKEY1 ON  VINCENT.LINEITEM (L_PARTKEY,L_SUPPKEY);

针对表lineitem 59986052条数据集，上述3个语句执行的总时间在300秒左右。

2) 数据压缩

在SAP HANA Studio中选中lineitem表，然后右键->Open Definition->Runtime Information可查看到lineitem的大小。我们将原来CSV格式的外部文件大小除以数据库表的大小的结果作为压缩率，即：压缩率 ＝ CSV文件大小(7.3G)/ 数据表大小。数据表大小又分为不加索引、纯数据的大小以及包含索引的大小。具体结果如下：项目HANAORACLE

不加索引大小1.67G5.14G

不加索引压缩率4.371.42

加索引大小3.17G9.84G

加索引后的压缩率2.30.74

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

3) 查询性能

用qgen产生

测试结果以及和ORACLE对比如下(单位：毫秒ms)查询HANAORACLE提高倍数

147276624014.01

2132038302.9

313492844021.08

412032218018.44

516233076018.95

67381650022.36

711042510022.74

810412083020.01

912896600204.65

1022132606011.78

1180537004.6

129872286023.16

1329637098023.96

141950190809.78

1514371728012.03

1692760606.54

178601540017.91

1831775800018.26

196951893027.24

207282067028.39

2116702478802.87

22129463104.88

总时间6073960711010

提高倍速 ＝ 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能一直坚持下去，能给我们足够的惊喜！