Vertica性能分析

Vertica的特色簡單的說能夠總結爲：列存儲、MPP架構、技術比較新。列存儲自己帶來了數據高度壓縮的便利，MPP架構使得能夠用相對廉價的PC級服務器橫向擴展到較大規模（PB級），05年才問世使得它在引擎層面能用上近年來列式數據庫方面較新的技術，如不可見鏈接（Invisible Join）等。

和Oracle那種一個庫包治百病的方案不一樣，Vertica從設計之初就是面向分析型應用的。所以，它適合相對中低併發度，相對重載的分析查詢場景。對於在Vertica上跑的每一個查詢SQL，它老是試圖分配足夠的系統資源，在儘可能短的時間內完成，而不是追求同一時間能有較多的併發。通常而言，每節點的CPU core數就是合適的最大併發數設置。若是最大併發設置更高，根據系統的硬件和參數配置，不少查詢分配的資源可能不足，有的查詢甚至進入隊列等待，從而致使每一個SQL的平均查詢時間上升。就咱們測試的經驗，在系統負載達到必定程度後，增長併發度，系統的查詢吞吐量（單位時間內能跑完的SQL個數）基本持平甚至會降低。這個特色尤爲要注意。

 

Vertica的SQL語法和SQL92標準兼容，在Oracle上的SQL除了一些oracle特有函數以外，不多須要修改就能夠直接在Vertica上運行。具體談到到一個SQL的性能，都離不開執行計劃的分析。

有兩種方式查看執行計劃：

一、MC（management console）圖形界面

二、查詢系統視圖：Vertica提供了一系列數據字典和視圖，對於SQL性能分析最重要的有兩個。QUERY_PLAN_PROFILES提供了SQL運行時實際執行計劃的信息，execution_engine_profiles則進一步提供了SQL執行時每一步每一個節點具體的資源消耗信息，以便精確判斷瓶頸所在。有這兩個視圖的數據，基本上能夠完成全部的SQL級性能分析。

 

如何獲取特定SQL的執行計劃：

在Oracle中，通常根據SQL_ID和Plan hash value能夠惟一肯定一個SQL的執行計劃。在Vertica中，相似的能夠經過transaction_id和statement_id兩個參數惟一肯定一個執行計劃。手工測試時一般statement_id默認是1，因此上述腳本在使用時，注意抓到要分析SQL的transaction_id便可。

 

由於vertica會針對每一列選擇不一樣的壓縮算法進行壓縮，在SQL執行時不一樣數據類型的執行效率也有很大差別。因此數據類型的選擇對性能影響會相對Oracle更加明顯。

就Vertica咱們的實踐而言，數據類型的選擇能夠簡單總結爲下面幾點：

一、  能用整型就不用浮點型；

二、  長度儘可能短；

三、  能固定長度就不要變長（結合2）；

根據測試驗證，咱們某個案例中將事實表KEY/ID類型字段從浮點型改成整數，將大量金額字段的數據進度從（38,10）改成（24,4），最後查詢性能從6秒提高到4秒，提高了50%

 

Vertica有一個特別的概念projection，具體的定義和特色介紹此處再也不贅述，有Oracle經驗的同窗能夠簡單的把它理解爲相似物化視圖的功能（固然本質有很大不一樣）。