hana数据库 字段长度_SAP HANA: 列式内存数据库评测
我一直怀疑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能一直坚持下去,能给我们足够的惊喜!
文章来自于网络,如果侵犯了您的权益,请联系站长删除!