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经验的同窗能够简单的把它理解为相似物化视图的功能（固然本质有很大不一样）。