【TechTarget中國原創(chuàng)】SAP HANA是一個全新的數(shù)據(jù)庫平臺,，它提供了全新的數(shù)據(jù)建模方式,，使得傳統(tǒng)關系型數(shù)據(jù)庫管理系統(tǒng)（RDBMS）得到了進一步的擴展。但是新的東西往往都隱藏著新的挑戰(zhàn),，要想讓SAP HANA的性能達到最佳,，你就需要比以往更加精細地處理數(shù)據(jù)。

　　雖然SAP HANA的數(shù)據(jù)仍然是存儲在table中,，但是它與傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)存儲模型是有所區(qū)別的,。列存儲的數(shù)據(jù)壓縮性更好，且讀取速度也更快,，這一點毫無疑問,。而要充分利用這一點，它的數(shù)據(jù)建模就要有別于傳統(tǒng)基于行的RDBMS,，這主要是基于兩點原因：

　　其一,，同行式數(shù)據(jù)庫表相比，冗余數(shù)據(jù)在HANA中并不是大問題,。列式數(shù)據(jù)庫表通過提供指針來引用重復的數(shù)據(jù),，因此重復值僅會存儲一次。此外,，當數(shù)據(jù)不是扁平進入一個表當中,，或者在HANA的多個表中未進行標準化的時候，表連接的消耗將是相當大的,。HANA提供了基于行和基于列存儲的兩種數(shù)據(jù)庫引擎,，不同方式的處理會同時出現(xiàn)，而當數(shù)據(jù)需要物理地從一個引擎移動到另外一個進行處理的時候,，表連接的消耗就會提升,。所以，我們要盡量將數(shù)據(jù)處理過程保持在一個數(shù)據(jù)庫引擎中,，而且最好是HANA的列式數(shù)據(jù)庫引擎,。

　　表連接消耗對于傳統(tǒng)數(shù)據(jù)庫來說影響會比較小，主要因為索引和標準化,，而在HANA中它是不容忽視的,，你需要監(jiān)控數(shù)據(jù)庫查詢是否違反了列存儲結構的約束,。如果處理過程在列式內存數(shù)據(jù)庫引擎中不支持的話，那么結果就是它會物理地移動到行數(shù)據(jù)庫引擎當中,，這對于性能的破壞是可想而知的,。因此，在SAP HANA的配置階段,，你仍然需要對數(shù)據(jù)進行建模,。記住，它與傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)建模設計會有很大的不同,。

　　在數(shù)據(jù)建模和配置完成之后,，你就需要馬上著手處理元數(shù)據(jù)（metadata）。首先要對基于列式數(shù)據(jù)庫表中的數(shù)據(jù)供應進行“屬性”和“分析”視圖的建模,，這些視圖的運轉原理同傳統(tǒng)數(shù)據(jù)庫的視圖很類似,。屬性視圖設計用來給主數(shù)據(jù)（master data）設定上下文環(huán)境：它們提供有意義的數(shù)據(jù)值，比如ID列的描述或者實際ID值的名稱等,。

　　分析視圖是運算與聚合發(fā)揮作用的地方,。包括屬性視圖和分析視圖在內，它們都將成為最終生成“計算”視圖的基礎,。計算視圖結合并擴展了分析視圖與屬性視圖,，這個以元數(shù)據(jù)驅動的內存運行時計算模型正是SAP HANA的最大價值所在，因為元數(shù)據(jù)層往往會免去將數(shù)據(jù)存儲到分配表之外其他層級的操作,。

　　盡管在SAP HANA中進行建模通常被認為就是玩轉計算,、分析或者屬性視圖，但同時需要強調的是要在內存中對數(shù)據(jù)進行合理的分配,。數(shù)據(jù)必須符合其存儲結構的需要,，SAP HANA也不例外。雖然數(shù)據(jù)模型能夠直接從傳統(tǒng)RDBMS的個星形schema移植過來,，但是精心測試并設計一個合適的基礎模型,，你將從SAP HANA中得到更多的回報。

　　SAP HANA如何處理數(shù)據(jù),？

　　在早期版本的RDBMS中,，由于技術限制，數(shù)據(jù)只能首先被建模到物理的基于行的表中,，并存儲到磁盤上,。后來我們普遍使用了索引，來通過SQL查詢進行快速的數(shù)據(jù)訪問,。索引目前仍然是數(shù)據(jù)庫當中非常重要的技術,，因為它是圍繞傳統(tǒng)行式交易型數(shù)據(jù)庫概念進行設計的。

　　在這個平臺中,，讀數(shù)據(jù)不是主要的目的,。它的結構是圍繞如何將數(shù)據(jù)載入來設計的,，而不是導出。再后來,，聯(lián)機分析處理（OLAP）數(shù)據(jù)庫結構,，有時我們直接指代cube，成為解決行式數(shù)據(jù)庫報表性能瓶頸的新一代解決方案,。OLAP也是將數(shù)據(jù)導出的首次嘗試，它將主要精力放在了讀取數(shù)據(jù)上,。然而缺點是數(shù)據(jù)需要轉換到額外的持久性存儲之上,，因此它的整個過程都是非常復雜并且成本頗高（存儲與計算）。

　　然后,，列式數(shù)據(jù)庫的出現(xiàn)成為上面方法的替代品,，它對于存儲數(shù)據(jù)用來進行生成報表是非常高效的。列式數(shù)據(jù)庫的數(shù)據(jù)存儲效率非常高,，因此免去了額外的數(shù)據(jù)層需求,。讀性能更好，但是寫數(shù)據(jù)的速度勢必會變慢變復雜,。

　　再然后,，就是SAP HANA的出現(xiàn)?？梢哉f它是集合了所有上面所提到的數(shù)據(jù)庫設計理念,，唯獨有一個差別：就是SAP HANA是將所有的數(shù)據(jù)集存儲在內存之中的。

　　SAP HANA將數(shù)據(jù)盡可能地存儲在離CPU最近的地方：內存,。數(shù)據(jù)以行式與列式兩種方式物理地存放在內存當中,。它還能夠通過特定類型的邏輯視圖進行建模，來仿真基于cube的存儲結構,。