The Vertica Analytic Database: CStore 7 Years Later

<style></style>

 

Vertica作为C-Store项目的商业化实现，所有前置论文C-Store要先看下

The Vertica Analytic Database (Vertica) is a distributed massively parallel RDBMS system that commercializes the ideas of the C-Store[21] project.

 

 

Vertica完成是为了AP设计的，

只能给出，TP和AP场景的不同，TP是高QPS，但是每个Transaction都只会操作少量的数据；AP是QPS较低，但是每条查询都会扫描大量的数据

 

 

核心设计

首先和C-Store一样，在物理上，Vertica也是以projections的形式存储的

这里有意思的是，Projections是一种受限形式的物化视图，这就部分解释了为何要用projections

因为在实际中，物化视图会包含聚合，join等，在实际系统中成本是无法接受的，至少现在没有那个开源数据库支持物化视图的

所以Vertica这里其实是用projections模拟轻量的物化视图

 

之前C-Store为了让projections之间可以join成行，增加join index，这个设计明显在实际应用中，成本很高

所以在Vertica中干脆放弃这个设计，直接默认增加super projection，包含所有column

数据库设计都是要normalized，但这样会导致join，所以理想情况是，逻辑上normalized，但在物理存储上denormalized，但是这很少用，因为这个很明显会降低loading的数据，得不偿失

可以看出，Vertica大部分的优化思路都是空间换时间，尽量避免join发生

基于列的encoding和压缩，是列存的关键，因为如果要用空间换时间，那空间的成本就需要控制在合理范围

 

这里描述两种数据划分，都是水平划分

一种是intra-node，节点内的，称为Partitioning，这样可以提升单节点的并发；并且带来的额外的好处，可以快速删除，比如按天，如果按天partition的话，可以优化查询，因为可以根据统计prune partitions

另一种是inter-node，节点间的，称为Segmentation，好处会把相同id的tuple都放到相同的node上，这样做聚合和join，会很方便；一个问题会造成热点，怎么解？

 

 这里可以看一个segmentation的例子，

 

这里是列存的核心设计，

如果要支持实时写入，

就需要有一个WOS，并且用Tuple Mover，定时把数据move到ROS，大部分列存都是参考此种设计

Ros中，包含一些ROS containers，我个人理解，一个container包含一个projection排序后的数据，每个column会有一个独立的文件

除了数据问题，还有一个position index文件，放的是元数据和统计信息

Vertica并没有实现C-Store论文里面用的B-tree

虽然Vertica支持多个列存一个文件，column famliy的概念，这种称为Hybrid row-column的方式一般不会使用，因为影响压缩

WOS，完全在内存中，所以行存和列存，在性能上没有差异，都可以，也不用特意做encoding和compress，因为这些操作是用cpu换disk IO，在内存中没有必要

同样对于AP场景，一般不会做update，而且倾向于append，这个也是影响深远

append就需要解决，update和delete的问题，如果update变成delete和insert，所以只需要解决delete问题

这里给出的方法也是，经典方法，deleted vector，标记哪些行被删除

你可以认为deleted vector就是一种特殊列，所以在内存中，先DVWOS，在被move到磁盘中，DVROS

 

Mover是链接WOS和ROS之间的桥梁

主要做两件事情，Moveout，从WOS到ROS

Mergeout，把小的ROS合并成大的ROS，太多小的ROS会有很多问题，所以Mergeout对于这种架构是必须的功能，用于提升性能

 

 

Vertica有个特点，他也支持Transaction的能力

引入epoch概念，逻辑时间戳，每次commit或delete的时候，都会带上这个逻辑时间戳

因此，Vertica实现snapshot isolation，因为如果所有的节点都确定该epoch内的Transaction都已经完成提交，那么这个epoch就代表一个Globally Consistent Snapshot，有意思的想法！！！

那么Vertica默认就支持，Read Committed，因为你只要读epoch-1就好

 

那么如果每次只能读epoch-1，用户会觉得很奇怪，因为读不到最新的数据

那所有Vertica做的优化是，

当commit Transaction，如果包含DML或变更数据的DDL，就自动advances epoch；而不等leader定时触发advance；这样的代价，epoch会很多，而且epoch在advance的时候，是要保证epoch中所有Transaction都成功的，这样写入效率会降低

Vertica会记录两种Epoch，

LastGoodEpoch，记录哪个Epoch已经成功写入ROS中

Ancient History Mark，等同于low watermark，小于LWM的数据可以被过期掉

 

为了故障恢复，每个Projection，至少要有一个buddy projection包含相同的columns，然后segmentation保证存到不同的node上

 

Vertica是append模式，所有append模式都不需要另外记录WAL，因为append本身就是log

然后恢复过程分为，Historical Phase和Current Phase，分别对应于磁盘中数据和内存中数据

如果buddy projections的排序相同，那么可以直接copy ROS containers，如果不同排序，就需要从新排序，所以就是select insert过程

Vertica除了restore，还有refresh，rebalance和backup

backup过程，会先对meta catalog做snapshot，然后对数据文件做hard link，防止backup过程中文件被删除，copy数据，最后删除hardlink

backup不考虑WOS的？

 

 

 

总结，本篇文章就C-Store如何实现做了阐述，还是比较有借鉴意义的

 

标签：join,Analytic,Later,Vertica,epoch,Database,ROS,数据,Store
来源： https://www.cnblogs.com/fxjwind/p/12095868.html