最佳效能祕籍：SAP HANA資料建模

為了更好地為您提供服務，請您在回覆中告訴我們“針對該主題，您目前存在的困難，或者您還想了解的內容”，即可瀏覽/下載

　
      分析檢視是運算與聚合發揮作用的地方。包括屬性檢視和分析檢視在內，它們都將成為最終生成“計算”檢視的基礎。計算檢視結合並擴充套件了分析檢視與屬性檢視，這個以後設資料驅動的記憶體執行時計算模型正是SAP HANA的最大價值所在，因為後設資料層往往會免去將資料儲存到分配表之外其他層級的操作。
　　
       儘管在SAP HANA中進行建模通常被認為就是玩轉計算、分析或者屬性檢視，但同時需要強調的是要在記憶體中對資料進行合理的分配。資料必須符合其儲存結構的需要，SAP HANA也不例外。雖然資料模型能夠直接從傳統RDBMS的個星形schema移植過來，但是精心測試並設計一個合適的基礎模型，你將從SAP HANA中得到更多的回報。

　　SAP HANA如何處理資料?
　　在早期版本的RDBMS中，由於技術限制，資料只能首先被建模到物理的基於行的表中，並儲存到磁碟上。後來我們普遍使用了索引，來通過SQL查詢進行快速的資料訪問。索引目前仍然是資料庫當中非常重要的技術，因為它是圍繞傳統行式交易型資料庫概念進行設計的。

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

　　然後，列式資料庫的出現成為上面方法的替代品，它對於儲存資料用來進行生成報表是非常高效的。列式資料庫的資料儲存效率非常高，因此免去了額外的資料層需求。讀效能更好，但是寫資料的速度勢必會變慢變複雜。

　　再然後，就是SAP HANA的出現。可以說它是集合了所有上面所提到的資料庫設計理念，唯獨有一個差別：就是SAP HANA是將所有的資料集儲存在記憶體之中的。

　　SAP HANA將資料儘可能地儲存在離CPU最近的地方：記憶體。資料以行式與列式兩種方式物理地存放在記憶體當中。它還能夠通過特定型別的邏輯檢視進行建模，來模擬基於cube的儲存結構。