Vertical简要

数据分析工作负载VS事务性工作负载证明商业和技术可靠的大规模分布式数据库,支持ACID、有效存储PB级别数据的系统

分析数据库的架构,关注与C-Store不同的点 实施和部署的经验,为什么引入那些不同 现实世界的经验可以引导未来大规模数据分析系统研究的方向
2.背景 2.1.1设计目标:分析工作负载不是事务工作负载 事务工作负载:每秒事务数多,每个事务会影响少数几个元组,大部分的事务是增加一个新行或者修改部分已存在的列 分析工作负载:每秒事务数少,每个事务检查很多表中的元组,比如分析用户的行为,行处理每秒很多
数据量级的增加,即使是小公司

最初就是设计一个分布式数据库 1、新节点加入系统性能有线性的扩展。使用共享磁盘的架构也能获得这样的扩展,但这很快会成为系统的瓶颈 2、优化和执行的引擎避免大量的网络数据传输,以避免内部互联成为系统瓶颈 3、查询和加载数据每秒都会有很多,必须关注支持高插入,否则只能有限的应用,批量的加载应该很快而又不能影响并行的查询 4、操作可在线,管理和维护任务不应该停止或暂停查询 5、易于使用是一个明确的目标。用CPU换时间,形式上减少复杂的网络和磁盘设置,减少性能的调优,自动化的物理设计和管理
3数据模型 3.1 (列)计划 属性排序子集(经过编码和压缩并按某种次序排序和分割的纵列集合) 加载过程中自动维护 每个Projection都有自己的排序,数据是完全排序的 任意数量、带有不同排序的推算或表列的子集是被允许的,可针对不同的查询进行优化。
不同排序规则,可被看成物化视图,但它们是物理数据结构,不是辅助索引。它不包含聚集、连接、额外的查询,认为它们在现实的分布式数据库中是不切实际的。

2.2连接索引,没有被实现,代价比带来的优势要少,实现复杂,执行代价在重现全元组在分布式查询时很高。 明确存储行ID,会点用很多空间,我们高效的压缩实现有助于减少这种开销,但没有计划实现它 3.3预连接推算 没有预期使用的多和重要:在小表连接操作上已经够好(高度优化的hash和合并算法),用户一般不愿意减慢 批量数据加载数据去优化查询速度。在加载数据时比连接查询时能够进行的优化机会要少,因为数据库在加载流中没有什么先验。
3.4 编码和压缩 不同列有不同的编码,同样的列在他们的每个推测中也可有不同的编码 自动:根据类型和配置,当使用场景不同确时 替换:低基数列
3.5 分区 c-store节点内水平分区,在单个节点使用并行提升性能 获得节点性并行并不需要硬盘物理分隔,在运行时逻辑分区,然后并行处理。尽管能够自动并行化,也提供根据value保持在物理上隔离 分区原因:快速批量删除(其它系统分区也是如此),否则需要查询所有物理文件要删除的行,添加删除标记,比起直接删文件慢的多 增加了存储的需求,在元组没有执行合并操作前影响查询性能。如果分区在所有推算上都一致,批量删除才是快速的,所以它是表层次的,而不是推算层次的
分区原因:增加查询性能,它保存最小值和最大值在每个ROS中,在做计划时就能够修剪容器。分区使这种技术更高效,分区使列数据不混合

3.6 分割:集群分布 可以指定列做hash到段 c-store根据projection的排序字段的第一个列分割物理存储到段 完全的分布式存储系统,分配存储元组到不同计算结点 节点内水平分区和节点外水平分区(分割) 分割对每个推算在排序方式上可能不同,推算分割提供决定把元组映射到节点,可以做许多重要的优化。( 完全本地分式连接,高效的分布式聚合,计算高基数不同的集合特别高效 复制推算在每个node上分布,分割推算一个元组在单个推算节点上存储 保持元组物理隔离为本地段,以方便集群的在线扩展与收缩
3.7读写优化存储 写在内存中,读在磁盘中 读:完整的依据推算排序排序的元组,列存储为一系列文件,两个文件1真实列数据2列数据索引 (大约1/1000,包含MetaData,如,开始位置,最大,最小值,固定不变故没有采用B-Tree) 写:内存,行列格式无关紧要,无编码和压缩,为缓冲数据操作(增、删、改)保证操作有足够多的行数以减少写的代价, 会随时间在行列模式下切换(和性能无关,只是软件工程考虑) 但它会以推算的分段表达式进行分段 3.7.1数据修改删除象量 不直接修改,当U和D操作时,创建D象量,它是要删除行的位置的列表,可能会有多个 DVWOS-》DVROS 高效的压缩 修改=删除+插入
4、无组移动:提高数据存储和查询效率 异步把数据从写优化到读优化,当WOS饱和mover操作没有完成之前,加载的数据直接入ROS,直到WOS重新获得足够的能力。mover平衡工作,避免产生小的ROS 读优化文件合并,减少ROS文件数量 写填满-》自动开始移动操作(随后的数据直接写到读优化,直到写有足够的空间)-》移动操作不能过多也不能过少 小文件影响压缩、减慢查询,需要更多文件句柄、seek和更多的全并排序文件的操作。 合并操作:回收已标记为删除的元组 没有限制ROS Containers大小,但它不会创建超过一定大小的(当前2T),足够大(每文件开销分摊,管理不笨重) ROS层在Node间是私有的,不会在集群内协调
5、修改和事务 每个元组都和提交时间关联(纪元)(隐式64bit的列或删除象量) 所有节点在事务提交都同意其包含的纪元,就相当于有了全局的一致性快照,读无需要加锁 有一个分析工作量的表锁定模式 不使用传统的两阶段提交 共享锁:限制并发修改表,用来实现序列化隔离 插入锁:插入数据时到表使用,和自己兼容,支持匹量插入和加载同时发生,以保持高插入加载速度。但仍然提供事务语义 共享插入锁:读写 独占锁:删改 元组移动锁:和所有锁兼容除了X锁,在元组移动同时操作删除象量时 使用锁: 拥有锁:
分布式和组成员协议来协调集群内结点之间操作,使用广播和点对点来保证所有控制消息成功送达所有node提交在集群中成功如果它在选定数据的结点上成功,ROS与WOS创建的事务完成后其它事务才能看到

5.1纪元管理 纪元模型:纪元包含给定时间窗口所有提交了的事务 Last Good Epoch:所有数据都成功从WOS移动到ROS Ancient History Mark:
5.2宽容失败 Vertica的数据复制通过使用Projection分段机制,以提供容错 每个Projection,必须至少有一个伙伴projection含有相同的列和分割以确保任何行被存储在同一样节点的Projection,当节点故障,伙伴projection会做为故障节点的源。 不需要传统的事务日志,数据+纪元自己就做为过去系统活动日志。vertica使用这些历史数据,去重放节点丢失的DML。节点会从正常的伙伴projection数据段恢复数据,
恢复,更新,重新平衡和备份都是在线操作;在执行这些操作同时可进行数据的加载和查询。影响的只是计算和带宽资源。

5.3 以元数据目录在节点间管理状态,它记录着表、用户、节点、纪元等的信息。 没有保存在数据库表中,因为它的表设计无法恰当的通过catalog访问和修改。它采用自定义的内存结构中,然后通过它自己的事务机制保存到磁盘中。 k-safety:当有小于或等于K个节点故障,集群仍然可用。 数据库projection必须确保有K+1个每个段的拷贝在不同的节点上。当有一半节点故障,集群会保护性关闭。集群必须保证有n/2+1个节点确保脑裂后的两个集群继续提供服务。
6 查询的执行 私有扩展标准的SQL声明的查询语言。 Vertica的公司扩展设计使可轻松地查询在SQL时过于繁琐或不可能的时间序列和日志型数据。
6.1查询操作符和计划格式 执行引擎为完全天量化,并且在同时查询一块行数据而不是同时查询单一行 标准操作树,每个操作执行一个特定的算法。一个操作者的输出做为下面操作者的输入。 执行引擎是多线程和流水线的 在一个时间请求一块行数据而不是请求一条数据。 使用上拉处理模型,直到一个操作从磁盘或网络读到数据。 扫描、分组(有多个算法依据性能最大化、内存需求、操作是否必须产生单独的组决定使用那个,并且实现了管道聚合方式可选择是否保持数据编码)、连接(实现了hash join和merge join算法,能够在必要时外部化)、表达式执行、排序、分析、发送/接收
特别处理和复杂的实现,确保可直接操作未解码的数据,这对于扫描、joins、低级聚集操作很重要。

SIP:Sideways Infomation Passing,侧面消息传递,采用在查询计划中尽可能早的过滤数据来优化join性能。(可在优化查询计算时就构建SIP filter,然后在执行时使用。在执行时,扫描操作会扫描join的hash table,SIP会用来判断outer key值在hash 表中是否存在。)

运行期间分析数据调整算法(内存不够hashtable->sort-merge join;生成预处理操作,并发执行,最后根据它们的结果生成最终数据)

晚物化、压缩的成本和估算、流聚合、消除排序、合并连接、不可见索引(每列按选择性排序,不需要索引来减少IO和更快查找值),数据die dai(L2缓存,更好的利用二级缓存和多核并发的特性)

使用pipeline执行引擎带来挑战是共享公共资源,可能造成不必要的yi chu到磁盘。vartica会把计划分成多个不会在同一时间执行的区,下游操作会回收上游操作的资源。

不同表的projection的数据被复制到所有节点上或者在join key上分割相同的范围,使得计划可以在每个节点的内部执行,然后结果发送到客户端连接的结点。

6.2 优化

选择和连接projections,保证scan和join更快(保证之后join的数据被减少)

收集性能数据(压缩I/O,CPU,网络使用)

Leave a Reply

Your email address will not be published. Required fields are marked *