SAP HANA: 列式記憶體資料庫評測

我一直懷疑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	ORACLE
616	680

 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）/ 資料表大小。資料表大小又分為不加索引、純資料的大小以及包含索引的大小。具體結果如下：

項目	HANA	ORACLE
不加索引大小	1.67G	5.14G
不加索引壓縮率	4.37	1.42
加索引大小	3.17G	9.84G
加索引後的壓縮率	2.3	0.74

由上表可見HANA具有非常出色的資料壓縮能力，在不加索引的情況下能将外部的CSV格式的檔案壓縮4.37倍。可見列式資料庫在資料壓縮方面的優越性。需要說明的是這次ORACLE的版本是11g R2, 也用到了其最新的行式壓縮技術，但跟HANA比起來明顯不是一個層次的。

3） 查詢性能

用qgen産生22個SQL查詢語句并對其做了簡單的文法調整，例如調整ADD_MONTHS等時間處理函數，盡量不改變語句原來的結構。将這22個查詢複制到SAP HANA Studio的SQL Editor中運作即可獲得每個查詢語句執行的時間。

測試結果以及和ORACLE對比如下（機關：毫秒ms）

查詢	HANA	ORACLE	提高倍數
1	4727	66240	14.01
2	1320	3830	2.9
3	1349	28440	21.08
4	1203	22180	18.44
5	1623	30760	18.95
6	738	16500	22.36
7	1104	25100	22.74
8	1041	20830	20.01
9	12896	60020	4.65
10	2213	26060	11.78
11	805	3700	4.6
12	987	22860	23.16
13	2963	70980	23.96
14	1950	19080	9.78
15	1437	17280	12.03
16	927	6060	6.54
17	860	15400	17.91
18	3177	58000	18.26
19	695	18930	27.24
20	728	20670	28.39
21	16702	47880	2.87
22	1294	6310	4.88
總時間	60739	607110	10

提高倍速 ＝ 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能一直堅持下去，能給我們足夠的驚喜！