vertica MySQL_Vertica数据库简介

、Vertica WLM资源控制、scheduler任务计划对接kafka等如Teradata(NCR来自美国)一样，在真正使用它之前，是不知道有它的存在的

Vertica(HP来自美国)是我所处的数据仓库环境用来替换原有的Teradata(主仓)和DB2(集市)通过招标引进的，正如我前面文章所述，这类产品为了打入中国市场，特别三大运营商的市场，在不知道其产品力如何的情况下，几乎都是靠降低成本取胜，好在其产品力确实不错，后期的使用中也较为顺利和稳定，下面简单来介绍介绍。

当下我所在的数仓环境使用的是Vertica enterprise Mode(Vertica Eon Mode存储计算分离架构)，后面介绍都基于enterprise Mode展开，后续会有文章介绍Vertica Eon Mode。

1.无Maste MPP

Vertica数据库属于无Master的MPP架构，所有节点均可访问使用，当然其也提供了负载均衡，以保障节点的合理使用

MPP并行计算

2.列式存储

Vertica为列式存储，加上高压缩性能，IO能力不再是OLAP场景的瓶颈。自然列式存储成为了现在数仓的首选

在Vertica日常使用中，内存的爆满溢出倒是成为了首当其冲的问题

3.高可用性

Vertica 使用类似RAID 的功能为数据库提供高可用性。在Vertica的术语中叫KSAFE安全性，其实现确如RAID

KSAFE 1≈RAID 1，即一份数据落实到数据库会按照两副本的形式存放，在最简单的场景中节点1与节点2映射，节点2与节点3映射，依次类推呈现环装

节点1故障，仍能满足数据库对于数据完整性的需求，股数据库仍能有效运转(ksafe 0相关操作无法实施)

在如此映射关系中，只要保证相邻节点不同时出现故障，数据库仍能有效运转(ksafe 0相关操作无法实施)

如果出现映射节点同时故障，那数据库便无法有效运转，停止提供访问了

当然，在实际环境中，我们会根据物理机架的规则，构建fault group，构建更为复杂的节点映射关系，防止因机架断电导致数据库无法使用的情况，尽可能提高数据库集群的高可用。

4.可扩展性

这里没用高可扩展性的说法，是因Vertica Enterprise Mode架构的扩展效率局限性较大，扩展的过程实施较为方便，但Rebalance操作却较为费时费力，Vertica Enterprise Mode架构下只有扩充现有节点的倍数才能提升扩展效率，反之数据Rebalance将十分耗时，对于数仓环境(数据量较大)确实不太友好。

按2倍扩展，性能最佳

只扩充1个节点最不合算

在Vertica Eon Mode中就不存在这个顾虑了，因为数据存放在共享存储中，数据Rebalance靠共享存储实现，与Vertica无关

5.自动数据库设计

Vertica在这一块做的确实很好，数据库环境部署完成后，近乎不需要再调整任何数据库参数(只有负载均衡、连接上限等需要根据实际环境定义)便可充分利用服务器的资源

6.较完善的应用集成

Vertica集成了DBD分析引擎(实际场景这块用的不多)

Vertica MC控制管理平台Vertica MC

Vertica资源池配置WLM资源池配置WLM

Vertica scheduler调度microbatch消费kafkascheduler调度microbatch

7.Vertica特别组件

这里就不特别写文字了，偷懒拿了张给项目组培训的ppt贴一下了

Vertica数据导入

•AUTO :Initially loads data into WOS, suitable for smaller bulk loads.

•DIRECT:Loads data directly into ROS containers, suitable for large (>100 MB) bulk loads.

•TRICKLE:Loads data only into WOS, suitable for frequent incremental loads.

后续的版本中Vertica在慢慢弱化WOS的存在

8.Vertica projection

Vertica数据库与其他RDBMS不一样，数据库的物理层对象为projection(其他RDBMS为table)，且Vertica projection均是有序存放(规范建表必须显示指明order by否则默认取前30列升序入库)

9.Hash Joins Versus Merge Joins

•Merge join is used when projections of the joined tables are sorted on the join columns. Merge joins are faster and uses less memory than hash joins.

•Hash join is used when projections of the joined tables are not already sorted on the join columns. In this case, the optimizer builds an in-memory hash table on the inner table's join column. The optimizer then scans the outer table for matches to the hash table, and joins data from the two tables accordingly. The cost of performing a hash join is low if the entire hash table can fit in memory. Cost rises significantly if the hash table must be written to disk.

Vertica的数据有序存放，故而在大多数情况下我们希望执行计划能走MERGE JOIN，减少对内存的消耗，特别在数仓环境大量表项数据量较大，在HASH JOIN中HASH MAP消耗大量内存资源，影响可想而知

10.数据分布

在MPP架构环境中，数据分布的合理性是老生常谈，Vertica同其他MPP关系型数据库一致，需要模型设计人员指定数据分布键，分布键的合理选择能尽可能保障数据的均匀分布，降低数据倾斜，提升读写效率(数据倾斜是MPP的常见的短板)

对常用的维表采用：全节点复制

其他事实表采用：分段存放

关于Vertica的相关介绍这里就先告一段落了，后续有其他考虑的地方再做补充分享，表述不当之处还望批评指正