前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >CDB for MySQL 8.0列存引擎CSTORE介绍

CDB for MySQL 8.0列存引擎CSTORE介绍

作者头像
腾讯数据库技术
发布2020-08-25 16:40:15
2.1K0
发布2020-08-25 16:40:15
举报

「 第一部分 概述 」

数据库中存在两种典型的业务访问场景,一种以在线事务处理为主,称为OLTP(On-Line Transaction Processing);另一种以在线分析处理为主,称为OLAP(On-Line Analytical Processing)。下面具体介绍他们的区别。

1.1 OLTP

OLTP业务的主要特点是有较多的增删改查操作,并且在大部分业务中,写相对于读的比例还很高。并发的事务数较多,而且事务的响应时间要求比较高。此外,每个增删改语句通常只操作少数几行数据;每个查询语句通常也只返回较小的结果集。查询大多数时候为点查询(例如:SELECT 列 FROM 表WHERE 主键=值)和小范围的查询(例如:SELECT 列 FROM 表WHERE 列 >=值 AND 列 <= 值),较少涉及大量数据的聚合和JOIN操作。

OLTP业务虽然每次访问的数据量不大,但是经常访问一个表的全部字段或大多数字段。因此,传统上,几乎所有的数据库管理系统都采用了按行存储的形式,将数据分成定长的页面,在外存和内存中保存数据。同一个页面的数据,逻辑上可以将其视为下面的一个二维的表格。

1.2 OLAP

OLAP业务的主要特点是有较多的查询操作,写操作占比很低,并且大多数写操作是数据的批量导入和数据的批量删除或更新。并发的事务数相对OLTP要少很多,而且事务的响应时间要求相对比较低。但是查询语句要访问的数据量很大,例如访问全表数据做数据的聚合等统计分析,进行多表JOIN等等。与OLTP不同,查询语句的形式比较多样;很多查询语句是按需产生的,业界一般将其称为Ad Hoc查询。

OLAP业务每次访问的数据量很大,但是多数时候只需要访问表中的少数列,而且OLAP业务的表经常有几十、几百列甚至更多。按行存储就会导致每次访问很多不需要的列的数据,大大增加IO代价。因此,针对OLAP优化过的数据库管理系统常常将数据按列保存,并且将同一个列中连续的多行记录保存在同一个逻辑页面之中。其存储结构可以视为下面的多个一维表格。

CDB for MySQL 8.0是腾讯TEG云架构平台部推出的新一代MySQL产品。它继承了Oracle原生MySQL 8.0版本的所有改进,并以此为基础,集成了我们研发的诸多新特性,其最重要的特点是支持原生的INNODB引擎和我们研发的CSTORE引擎。INNODB引擎更适合OLTP业务,CSTORE引擎更适合OLAP业务。

本文档主要介绍列存引擎CSTORE的架构特点、适用场景、功能和性能指标。也会在需要的时候和MyISAM以及INNODB做一些类比,以便理解其架构和功能特点。

「 第二部分 CSTORE的架构特点 」

CSTORE的架构特点可以概括为:提供高速数据加载、支持高压缩比,具备稀疏索引、延迟物化等查询优化和执行技术的列存引擎。

CSTORE的整体架构如下

CSTORE作为一个列存引擎,架构上有一些明显区别于INNODB的特点。首先,CSTORE的所有数据都按列组织,同一列的数据中每固定行(称之为DataGroup)组织为一个逻辑页面。每个页面内的数据都统一通过压缩再写入到文件中。其次,CSTORE没有INNODB那样的二级索引,它为每列自动维护了稀疏索引等元信息来加速查询。典型的稀疏索引信息包括每个逻辑页面中的最大值、最小值、SUM值、空值个数、NULL个数、记录条数等。

CSTORE假设数据的修改不太频繁,而且多数时候是大批量的数据写入或修改,因此在做DELETE、UPDATE的时候,速度会稍慢于INNODB。但是针对大量数据的写入做了专门的加速优化,可以充分发挥多核处理器的计算能力。

CSTORE的查询引擎吸收了MySQL查询引擎的优点,又针对列存的特点做了优化。因此,MySQL原生支持的大部分查询都可以不修改而继续运行,并且带来性能的提升。

「 第三部分 CSTORE核心技术 」

3.1 快速加载

CSTORE采用多线程技术,将每一列的固定行数的数据定义为一个数据包(DataGroup),对每一个数据包的加载作为一个子任务,由各个线程并行执行。整体处理流程如下:

3.2 晚期物化查询

不同于传统的行存引擎,CSTORE采用晚期物化策略,将物化操作尽量推后,中间结果采用位图表示命中的记录,从而解决了大数据量下查询的内存消耗问题。整体处理流程如下:

3.3 作为备机的异步复制机制

随着业务的发展,云上的传统使用INNODB用户业务的数据量的不断增大,导致严重的查询缓慢和磁盘空间消耗问题。同时传统业务又不能降低高TPS的需求。将INNODB作为主机,CSTORE作为备机是保证业务顺利进行的最优选择。CSTORE通过MySQL的主从复制接入,通过采用基于生产者/消费者模型、多线程技术、数据合并技术等,将主备延时极大降低。通过当前某大客户业务的大数据线上实践,主备延时基本为零,同时保证了高效率查询和高压缩比(平均数据存储是原来的1/9)。整体异步处理流程如下:

「 第四部分 典型优势和场景 」

4.1 典型特性和优势

(1)数据加载速度快

CSTORE可以发挥多核处理器的计算能力,在数据加载时通过将数据的解析分块、数据格式转换、数据压缩、数据写入等多个阶段的流水线和并行处理。在加载数据时可以跑满多个处理器核心,做到多线程接近线性的加速,加载速度可以达到INNODB的5到10倍。

(2)数据压缩比高

CSTORE的数据采用列存格式,同一列的数据相似度更高,因此可以做各种压缩策略的组合,从而获得较大的压缩比。例如对于取值总是递增的整数,可以只保存其最小值以及其他每个值与它的差值,从而减少需要存储的字节数,然后再用通用的压缩算法再次压缩。加载后的数据与原始文本数据的压缩比可以高达10倍。

(3)聚合查询速度快

类似于MAX、MIN、SUM、AVG、COUNT等聚合查询可以直接通过元信息的简单查询和计算获得结果,而不会造成实际数据块的IO,从而可以立即获得结果。

(4)复杂查询速度快

只要查询上有合适的过滤条件,查询执行不是全表或全列扫描,查询就可以通过元信息和智能索引进行过滤,只访问可能命中的数据块,而避免访问不会命中的数据块,从而减少大量的数据块IO。查询执行过程中对于中间结果,会尽量延迟物化,而不是每个操作都产生大量的临时表。

(5)全面兼容MySQL生态

CSTORE引擎作为MySQL的一个内置引擎,全面兼容原来的MySQL生态,应用程序可以继续使用之前的开发接口和大部分功能而无需修改。

4.2 典型应用场景

CSTORE适合于OLAP类的场景,INNODB更适合于OLTP类的场景。在CSTORE所针对的OLAP业务中,典型应用场景包括:

(1)流水日志或历史数据查询分析

这一类的数据大多需要批量入库,并做较多的查询分析。大量数据入库可以充分发挥CSTORE快速数据加载的特点,以及高压缩比的优势。

(2)大数据计算产生的结果数据入库和查询分析

这一类的业务会通过大数据平台计算处理大量数据,但是产生的最终结果数据往往不是特别大,可以用MySQL进行存储和查询。这类业务可以利用MySQL开发生态的完备性以及高性价比。

(3)采用MyISAM或INNODB做分析的场景

很多业务因为采用了MySQL做OLTP类业务处理,因为考虑到开发便捷性等原因,而将MyISAM引擎或INNODB引擎用做查询分析类业务。这类业务只需要将存储引擎切换到CSTORE就可以立即体验高效的写入和查询。

「 第五部分 性能指标 」

TPC-H是OLAP领域常用的标准测试集,它定义了8张表,包含22个典型的复杂查询。我们以TPC-H定义的表结构来做数据的加载,并执行其中的典型查询,来验证对比CSTORE和INNODB在数据加载性能、数据压缩比、查询性能。以下测试都在48核机器下进行。

5.1 数据加载性能

加载大约600万行LINEITEM表的记录,对比不同引擎的数据加载速度。可以看到,CSTORE的加载速度最快,大约为INNODB的9倍,MyISAM的5倍。

5.2 典型数据压缩比

加载大约600万行LINEITEM表的记录,对比不同引擎的数据大小。可以看到,CSTORE的压缩比最高,接近原始数据的7分之一。INNODB和MyISAM的数据占用空间比较大,一是因为它采用行存格式,另外是因为它还要保存二级索引。在启用压缩算法后,它们的压缩比还是要差于CSTORE。

5.3 查询性能

针对上述加载的数据,进行TPCH的22条查询可以发现,多数查询的性能都有较大提升。

「 第六部分 未来规划 」

6.1 数据类型完善

支持BLOB和JSON数据类型,使CSTORE支持的数据类型与INNODB一致。

6.2 支持向量化、并行查询

对于单条查询,CSTORE还是只利用单核处理,虽然单核条件下的查询性能已经大大领先INNODB了,但CSTORE的性能提升还有很大的提升空间,即向量化和并行查询技术。通过采用该技术,在16核机器上,将查询提升10倍以上还是很轻松的。

6.3 分布式CSTORE集群,即MPP(Massively Parallel Processing)

传统的分析型数据库都是MPP集群结构,比如GreenPlum、Impala、HAWQ和ClickHouse等。随着数据量的增大,单机已经支撑不了更大分析场景,CSTORE最终的形态也是一个集群结构。通过分布分表、分布式查询、一致性协议等技术实现CSTORE集群的高可用。架构参考如下,虚线部分为一个CSTORE实例(Node),数据分片存储采用哈希、随机等方式:

「 总结 」

至此,对列存引擎CSTORE,我们都有大概的了解。 未来,我们会持续对列存引擎CSTORE进行完善并尽快正式发布给大家使用,敬请期待~

腾讯数据库技术团队对内支持QQ空间、微信红包、腾讯广告、腾讯音乐、腾讯新闻等公司自研业务,对外在腾讯云上依托于CBS+CFS的底座,支持TencentDB相关产品,如CynosDB、CDB、CTSDB、MongoDB、CES等。腾讯数据库技术团队专注于持续优化数据库内核和架构能力,提升数据库性能和稳定性,为腾讯自研业务和腾讯云客户提供“省心、放心”的数据库服务。此公众号旨在和广大数据库技术爱好者一起推广和分享数据库领域专业知识,希望对大家有所帮助。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-08-24,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 腾讯数据库技术 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1.1 OLTP
  • 1.2 OLAP
  • 「 第二部分 CSTORE的架构特点 」
  • 「 第三部分 CSTORE核心技术 」
    • 3.1 快速加载
      • 3.2 晚期物化查询
        • 3.3 作为备机的异步复制机制
        • 「 第四部分 典型优势和场景 」
          • 4.1 典型特性和优势
            • 4.2 典型应用场景
            • 「 第五部分 性能指标 」
              • 5.1 数据加载性能
                • 5.2 典型数据压缩比
                  • 5.3 查询性能
                    • 6.1 数据类型完善
                      • 6.2 支持向量化、并行查询
                        • 6.3 分布式CSTORE集群,即MPP(Massively Parallel Processing)
                        相关产品与服务
                        云数据库 SQL Server
                        腾讯云数据库 SQL Server (TencentDB for SQL Server)是业界最常用的商用数据库之一,对基于 Windows 架构的应用程序具有完美的支持。TencentDB for SQL Server 拥有微软正版授权,可持续为用户提供最新的功能,避免未授权使用软件的风险。具有即开即用、稳定可靠、安全运行、弹性扩缩等特点。
                        领券
                        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档