打造次世代分析型数据库（二）：这，不只是列存表
作者介绍
作者介绍：marklv（吕夫洋），腾讯云数据库高级工程师，专注于数据库存储、事务、高可用方向，具有多年的数据库内核研发经验。曾供职于华为2012高斯实验室；加入腾讯后负责CDW PG数据库全新存储引擎的设计和研发工作。
Effective Storage Engine设计背景
传统数据库按行进行表的存储和访问。由于表中每行的数据连续地存储在一起，对于交易性业务（OLTP）这样频繁以行作为单位存储表中数据的负载，行存储性能较好。
但是对于分析性业务（OLAP）这种经常对表中某些列进行查询计算的负载，行存储会将不相关的列数据读入内存中，导致性能欠佳。列存储模型通过将表中的列连续地存储在一起，能够很好地解决这个问题，减少不必要数据的读取与解析带来的磁盘I/O代价、数据压缩解压代价以及CPU执行代价，提高磁盘存储和使用效率，从而提升查询性能。
在混合的业务负载（Hybrid transaction/analytical processing，HTAP）场景下，针对OLTP优势的行存与针对OLAP优势的列存都无法很好地同时应对两种类型的业务，大多需要牺牲其中一种场景下的表现，或是最终造成两种场景下的能力都无法达到业务的预期。
应对两种完全不同的业务负载的实现往往无法避免以下问题：
- 需要额外的系统资源（存储资源、计算资源）；
- 难以兼顾数据的实时性和强一致性；
- 需要业务/应用层面针对特殊配置进行识别和适配。
为了满足CDW PG在OLAP传统数仓场景超大集群下的目标业务负载，并且具备能够良好处理数据混合负载的能力，Effective Storage Engine（下文简称“Estore”存储引擎）应运而生。
Effective Storage Engine基础架构设计
Estore的基础“三角形”组
Estore表基础架构由元信息表(“registry”表)、列文件（”silo”组成的文件）以及临时区表（”stash”表）组成。
在创建表create table时于reloptions “orientation”处填写”column”即可创建，创建后以上基础组成部分会自动创建。
- Silo是Estore表中基本的数据存储单元，承载存储数据的基本职责。 每个Silo包含一组数据中其中一列的数据，方便系统对其进行批量操作、压缩、存储。Silo自身存储与行存储的数据页面不同，不是固定的存储空间，而是存储固定的行数，实际存储空间大小可变。 Silo存储的是一组数据中的一列内容，同列数据能够提供更接近的数据特征以及更好的数据筛选，进而提供更好的压缩率。同时由于Silo的概念是固定行数而不是固定空间的概念，因此在尽量满足Silo填充至上限的情况下，Silo可以为压缩提供更大的上下文空间，以便提高数据的压缩率。 同时，Silo可以根据自身的数据类型、数据特征以及表级别/列级别，指定使用最合适的压缩算法或压缩算法的组合。
- registry表实际上是一张行存表，承担一张Estore表的存储引擎的主体组织结构与核心角色，存储了一张表中承载数据的各个Silo的相关信息。
- stash则是为了应对碎片数据、流数据以及混合负载下OLTP负载而准备的一张行存表，也可以认为是一个使用行存储承载数据的临时区域。
Effective Storage Engine 混合负载
混合负载设计背景
在分析性数据库的使用场景中，除去分析型业务常见的大数据量批量导入操作（bulkload）之外，数据库也常常会承接来自用户应用逻辑、数据管道或者ETL工具端的碎片化增量数据，亦或是流数据的持续输入。不同于批量数据操作中单个事务内GB-TB数量级的数据规模，碎片化的增量数据往往由多个小事务组成，每个事务中仅含有KB以下的数据量。
同时，在部分客户的应用场景中，用户逻辑会针对特定数据/近期数据/部分热数据进行类交易型的调用与处理，包括频繁的增删改；在完成相关业务后，又希望针对这部分数据或针对全部历史数据进行进一步的BI分析。
业界常见的支持混合负载的数据库，大部分都是采用两套或更多套存储引擎或组件来实现，中间通过COW或Raft协议副本的方式来进行数据的同步。有没有办法可以用一份数据搞定两种业务呢？
以Stash表为核心的混合负载基础理念
Stash表的设计初衷即是应对以上场景。Stash表是Estore表创建后同步创建的一张行存表，与原表有着相同的表定义，但使用行存表作为存储。Stash表的作用是充当Estore表的“临时区“角色，针对单次行数在一定阈值下的操作，其相关数据会先被放入Stash表中，以行存储的形式存储起来，避免碎片化数据对Estore表的registry/silo存储模式的直接冲击。
同时，由于放在Stash表中的都是近期单条/小批量插入或更新的数据，Stash表也就在实际上起到了Estore表类似“热数据分片”的概念。通过Stash表作为行存储的机制支持，Estore存储引擎自身就可以为混合负载中的OLTP部分提供良好的支持，而不需要额外在其他存储方式上创建副本。后续按照用户配置或通过用户主动执行，用户可以按照自己的应用逻辑将Stash表数据合并入registry/silo的存储模式中，获得更好的分析性业务负载性能。
用户操作中对数据的归属性质不进行感知，即发起query或DML时无需对stash进行特殊处理，底层逻辑会自动扫描registry/silo以及stash中的数据。
Stash表的“自动沉降“ —— Auto Stashmerge
为了保证表中数据能够借助高效存储组织结构以及各类优化对应用提供优秀的分析性业务负载性能，Estore存储引擎在数据库实例中实现并封装了Estore表的自动合并机制，定期合并stash数据至silo中。用户可以根据不同应用场景对“沉降”进行配置，业务无需感知, 后台进程的动作也不会影响用户对表正常的增删改查。
Stash表的“手动沉降” —— Vacuum Stashmerge
适用于部分用户或业务在交易性与分析性间存在较为明确的分水岭的场景，执行时会将指定表或库中所有Estore表的Stash全量数据合并至其对应的registry/silo存储结构中，可以近似地理解为系统中“flush buffer”一样的操作。
总结
综上，为大家介绍了CDW PG的新型列存储引擎Effective Storage Engine的整体设计，以及Estore引擎如何同时为传统的OLAP数仓场景以及HTAP混合负载的业务提供稳定且优质的存储支持与保障。
推荐阅读
关注腾讯云大数据公众号
邀您探索数据的无限可能
点击“阅读原文”，了解相关产品最新动态
↓↓↓