Vertica的特點簡單的說可以總結為：列存儲、MPP架構、技術比較新。列存儲本身帶來了數據高度壓縮的便利，MPP架構使得可以用相對廉價的PC級服務器橫向擴展到較大規模（PB級），05年才問世使得它在引擎層面能用上近年來列式數據庫方面較新的技術，如不可見連接（Invisible Join）等。
和Oracle那種一個庫包治百病的方案不同，Vertica從設計之初就是面向分析型應用的。因此，它適合相對中低並發度，相對重載的分析查詢場景。對於在Vertica上跑的每個查詢SQL，它總是試圖分配足夠的系統資源，在盡量短的時間內完成，而不是追求同一時間能有較多的並發。一般而言，每節點的CPU core數就是合適的最大並發數設置。如果最大並發設置更高，根據系統的硬件和參數配置，很多查詢分配的資源可能不足，有的查詢甚至進入隊列等待，從而導致每個SQL的平均查詢時間上升。就我們測試的經驗，在系統負載達到一定程度后，增加並發度，系統的查詢吞吐量（單位時間內能跑完的SQL個數）基本持平甚至會下降。這個特點尤其要注意。
Vertica的SQL語法和SQL92標准兼容，在Oracle上的SQL除了一些oracle特有函數之外，很少需要修改就可以直接在Vertica上運行。具體談到到一個SQL的性能，都離不開執行計划的分析。
有兩種方式查看執行計划：
1、MC（management console）圖形界面
2、查詢系統視圖：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我們的實踐而言，數據類型的選擇可以簡單總結為下面幾點：
1、 能用整型就不用浮點型；
2、 長度盡量短；
3、 能固定長度就不要變長（結合2）；
根據測試驗證，我們某個案例中將事實表KEY/ID類型字段從浮點型改為整數，將大量金額字段的數據進度從（38,10）改為（24,4），最后查詢性能從6秒提升到4秒，提升了50%
Vertica有一個特別的概念projection，具體的定義和特點介紹此處不再贅述，有Oracle經驗的同學可以簡單的把它理解為類似物化視圖的功能（當然本質有很大不同）。