我一直怀疑SAP宣称的主存数据库HANA能够实现OLTP。因为内存是会“挥发”的，一旦断电，便什么都没了。这也许对OLAP来说没什么，毕竟数据可以重新从源系统中抽取，而且OLAP的业务紧迫性似乎也从来没有来得比OLTP重要。所以我也一直相信内存计算只会充单BI 加速器的功能，因此也就对之“意兴阑珊”了——一个做报表的的系统又能挑起什么样的惊涛骇浪呢？

有段时间我把更多的注意力放在C-STORE上，一种基于网格（多节点，异地部署）的列式数据库方案。在处理扩展性和可用性方面，它通过Projection Overlapping(射影重叠冗余)技术实现K-Saftey（即能容忍K个节点同时挂掉）；在处理更新操作方面（列式数据库的难点便是更新），它通过一个巧妙的混合架构合并了一个写优化库（WS）和一个读优化库(RS)。WS通常保持很小的数据量，以便获得更高的更新性能；RS则是专门为查询优化过的数据结构。需要值得注意的是WS 也是列式的，而非行式，这样做的主要目的为了避免写两个不同的查询优化器，同时更加方便的将WS自动的转换城RS(Tuple Mover)。C-STORE是一种应付大数据很好的方案，很明显该方案似乎更适合主存架构，因此后来发展成H-STORE（商用VoltDB）也就顺理成章。所有的这些让我更加坚定主存数据库只有架构在网格上（或者说“云”）才能更好的实现其商业应用价值。

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

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

既然要参照，不能只参考SAP给的数据或者SAP BW等应用跑出的结果。HANA被公布成一种崭新的数据库，那么就让我们用数据库的公开基准测试标准TPC-H来测试它，并将结果与传统的行式数据库（ORACLE）进行对比。我这次用到的是TPC-H 2.8的数据结构和22个SQL查询。性能测试主要包含以下4个内容1）数据加载，作为暂时主打数据集市的数据库，数据加载能力是我们关注的重要指标；2）数据压缩，一则经常作为列式数据库的卖点，二则HANA是按内存大小来收费的，可是直接关乎成本的；3）查询性能，内存数据库的主要卖点，是这次基准测试的重头戏；4）增量更新，是数据仓库非常重要的指标，也能从侧面让我们看到HANA的OLTP能力，否则就只能成为Larry所说的“wacko”，而不够“transformative”了。

TPC-H是一个业界公认的数据库性能测试基准，比较公正和中立，它定义了8个标准数据库表:customer, lineitem, nation, orders, partsupp, part, region, supplier，各表之间的关系可见tpc.org官方文档。从tpch.org官网上下载源代码，编译后得到一个数据生成工具(dbgen)和一个查询生成工具(qgen)。TPC-H定义了不同的数据库容量(size)，用命令dbgen –s 10就可以生成10GB的数据，其中最大的表Lineitem行数达到59986052行。Qgen可以随机产生相同条件的不同取值的22个SQL查询。

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

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

操作系统SUSE Linux Enterprise Server 11.1

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）。

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） 数据压缩