数据分析工作负载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，网络使用）