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