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经验的同学可以简单的把它理解为类似物化视图的功能（当然本质有很大不同）。