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

dd_dong發表於2013-08-13
雖然SAP HANA的資料仍然是儲存在table中，但是它與傳統資料庫的資料儲存模型是有所區別的。列儲存的資料壓縮性更好，且讀取速度也更快，這一點毫無疑問。而要充分利用這一點，它的資料建模就要有別於傳統基於行的RDBMS，這主要是基於兩點原因：

      其一，同行式資料庫表相比，冗餘資料在HANA中並不是大問題。列式資料庫表通過提供指標來引用重複的資料，因此重複值僅會儲存一次。此外，當資料不是扁平進入一個表當中，或者在HANA的多個表中未進行標準化的時候，表連線的消耗將是相當大的。HANA提供了基於行和基於列儲存的兩種資料庫引擎，不同方式的處理會同時出現，而當資料需要物理地從一個引擎移動到另外一個進行處理的時候，表連線的消耗就會提升。所以，我們要儘量將資料處理過程保持在一個資料庫引擎中，而且最好是HANA的列式資料庫引擎。

      表連線消耗對於傳統資料庫來說影響會比較小，主要因為索引和標準化，而在HANA中它是不容忽視的，你需要監控資料庫查詢是否違反了列儲存結構的約束。如果處理過程在列式記憶體資料庫引擎中不支援的話，那麼結果就是它會物理地移動到行資料庫引擎當中，這對於效能的破壞是可想而知的。因此，在SAP HANA的配置階段，你仍然需要對資料進行建模。記住，它與傳統資料庫的資料建模設計會有很大的不同。

　　在資料建模和配置完成之後，你就需要馬上著手處理後設資料(metadata)。首先要對基於列式資料庫表中的資料供應進行“屬性”和“分析”檢視的建模，這些檢視的運轉原理同傳統資料庫的檢視很類似。屬性檢視設計用來給主資料(master data)設定上下文環境：它們提供有意義的資料值，比如ID列的描述或者實際ID值的名稱等。

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


　
      分析檢視是運算與聚合發揮作用的地方。包括屬性檢視和分析檢視在內，它們都將成為最終生成“計算”檢視的基礎。計算檢視結合並擴充套件了分析檢視與屬性檢視，這個以後設資料驅動的記憶體執行時計算模型正是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的儲存結構。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/42046/viewspace-768388/，如需轉載，請註明出處，否則將追究法律責任。

相關文章