MySQL · 实现分析 · HybridDB for MySQL 数据压缩

概述

数据压缩是一个把输入数据集按照一定的算法变换成更小的数据集的过程,解压是压缩的逆过程。如果算法对数据本身的语义了解得越多,则越可能利用语义信息进行针对性的处理,获得更好的压缩效果。数据库系统中用得比较多的压缩算法可以分为两大类:基于块的压缩、基于值的压缩。前者更为常见一些,在 OLTP 以及 OLAP 系统中都会用到,例如 InnoDB、TokuDB、HybridDB 中的块压缩;后者更多的用在 OLAP 的列存引擎内,例如 HybridDB for MySQL 中的列压缩。为了区别它们,这里把块压缩简称为压缩(Compression)、而把基于值的压缩称为编码(Encoding)。此外,在存储系统中比较常见的重复数据删除功能也可以被视为一种特殊形式的压缩。不过它不属于本文要考虑的范围。

通常来说,列存格式对压缩要更友好。大概而言,行存的数据压缩率一般为3:1(采用通用压缩算法);列存的数据压缩率为10:1(采用编码以及通用的压缩算法)。

无论是哪种形式的压缩,衡量算法本身是否适用的指标主要有:
1. 压缩率,也就是压缩前后数据大小的比率。
2. 吞吐量,也就是压缩和解压的速度。典型单位为 GB/s。
3. 资源消耗,压缩解压一般是计算密集型的算法,因此主要考虑的是 CPU 消耗。

压缩

压缩算法可以说是无处不在。常见的例子如各种文件压缩工具背后的压缩算法,包括 zip、rar 等等;各种图片格式对应的压缩算法,包括 png、jpeg 等等。数据库系统中用的都是无损压缩,图片压缩则可以采用有损压缩。很多算法都属于 lz 系列,例如:lz、lzo、quicklz 等等。多年以前 Google 推出的 Snappy ,虽然压缩率不是特别出众,但是吞吐量比较大、资源消耗比较小,因此获得了广泛的应用。最近几年 Facebook 推出的 zstd 算法具有类似的特征,也获得了很多应用。zstd 的主页上有一些测试的数据,可以作为参考:

编码

编码则是利用数据的语义信息进行更加有针对性的压缩。当然,很多算法也在通用的压缩算法中被采用了。常见的编码算法有:行程编码(Run Length Encoding)、字典编码(Dictionary)、差值编码(Delta)、变长整数编码(Varint)、位变换(Bit Shuffle)、前缀编码(Prefix)、异或(XOR)等等。甚至可以说有多少种数据的规律就可以发明出多少种编码算法。例如:InfoBright 就可以对一系列的数字除以最大公约数,获得更小的数字,从而达到数据压缩的目的。

产品

下面让我们来看一看典型的几个 OLAP 产品对压缩算法的支持。

Apache Kudu

Apache Kudu 是一个比较有意思的项目,它支持多副本、列存,试图解决实时分析的需求。下图是它支持的编码/压缩方法:

相对其他系统而言,Kudu 编码中比较特殊的一种是 BitShuffle 编码。假设输入的是类型 T 的一个数组,该编码的算法是:先保存每个值的 MSB 位(最高位),然后下一个 bit 位,一直到最后的 LSB(最低位);然后对数据进行 LZ4 压缩。该编码适合与重复值较多的列或者列值变化不大的情况。除了上述的编码之外,Kudu 也支持通用压缩算法,例如:lz4、snappy、zlib。默认情况下,列是不压缩的。而且 Bitshuffle 编码后的列总是自动采用 lz4 压缩。

Amazon RedShift

Amazon RedShift 支持的编码/压缩算法如下:

从图中可以看出,RedShift 支持 Delta、字典、RLE、Mostly、Text255 等编码。比较特别的是 Text255 和 text32k,它们适合与单词重复出现的 VARCHAR 列。实际上,它就是对每个 1MB 块中的单词创建了一个字典。字典容纳 245 个唯一的单词,数据实际存储的时候用一个字节的索引代替对应的单词。

Pivotal GPDB

Pivotal GPDB 的 Append Only Table 也支持压缩算法 。

相对而言,GPDB 支持的编码和压缩种类要稍少一些。但是它允许设置算法的压缩级别以及块的大小。

总结

不同的通用压缩算法在压缩率和速度以及资源消耗之间做了不同程度的权衡,有些算法(例如 zlib)还提供了一些压缩级别的参数可供调整。针对不同的数据集合,压缩率也存在较大的区别。例如:在采用某个特定数据集的测试中,snappy 的压缩率接近 3,而 zlib 和 zstd 的压缩率大约为 4。编码算法的压缩率对数据集的类型和取值更为敏感,例如 delta 算法对整数类型,并且相邻数据之间差别较小的情况下(例如自增列),压缩比就很好。对于浮点数而言,提高要缩率更为困难,Facebook 等曾经做过一些针对性的优化。

如果想要了解数据压缩的基本背景,请参考:Data compression tutorial 。如果想要获得对列存系统的更多知识(包括列存对数据压缩的优化),则建议移步:Column store tutorial 。

参考资料

1.Snappy
2.Zstd
3.Apache Kudu
4.Amazon RedShift
5.GreenPlum Database
6.Gorilla
7.Data compression tutorial
8.Column store tutorial

时间: 2024-10-22 08:30:41

MySQL · 实现分析 · HybridDB for MySQL 数据压缩的相关文章

MySQL · 特性分析 · 浅谈 MySQL 5.7 XA 事务改进

关于MySQL XA 事务 MySQL XA 事务通常用于分布式事务处理当中.比如在分库分表的场景下,当遇到一个用户事务跨了多个分区,需要使用XA事务 来完成整个事务的正确的提交和回滚,即保证全局事务的一致性. XA 事务在分库分表场景的使用 下图是个典型的分库分表场景,前端是一个Proxy后面带若干个MySQL实例,每个实例是一个分区. 假设一个表test定义如下,Proxy根据主键"a"算Hash决定一条记录应该分布在哪个节点上: create table test(a int p

MySQL性能分析系统

对于MySQL慢查询日志的分析,现已由多种工具来提供:最原始的mysqldumpslow,功能比较齐全的 mysqlsla和percona的 pt-query-digest:以上工具大大提高了DBA来分析数据库的性能效率,减少了过多的猜测过程: 如果能实现定时分析SQL并且进行可视化展示呢? 适用过Query-Digest-UI-master 这个UI插件,在配合 percona的 pt-query-digest工具,只是简单做到一个可视化的结果:如果对于多个服务器的分析,这个表现的就很吃力:

MySQL性能分析和优化-part 1

MySQL性能优化 平时我们在使用MySQL的时候,怎么评估系统的运行状态,怎么快速定位系统瓶颈,又如何快速解决问题呢? 本文总结了多年来MySQL优化的经验,系统介绍MySQL优化的方法. OS性能分析 使用top观察top cpu/memory进程 ~ top top - 09:34:29 up 10 days, 20:11, 1 user, load average: 0.61, 0.59, 0.60 Tasks: 208 total, 1 running, 207 sleeping, 0

如何支撑HTAP场景——HybridDB for MySQL系统架构和技术演进

随着DT时代的到来,企业占有的数据越来越多,其规模可能达到上百TB甚至PB级,如何以合理的成本管理并维护这样一个数据库也成为各个企业IT管理中的核心问题.HybirdDB for MySQL是基于HTAP资源的数据库,同时支持OLTP,在一份数据上做事务,又支持实时分析.10月12日的云栖大会·HTAP技术专场中,阿里云高级专家王骞探讨如何如何支撑HTAP场景,并重点分享了如何利用RDS技术实现HTAP业务,以及HybridDB for MySQL的系统架构和技术演进. 技术现状 首先看看技术现

TokuDB · 引擎特性 · HybridDB for MySQL高压缩引擎TokuDB 揭秘

HybridDB for MySQL(原名petadata)是面向在线事务(OLTP)和在线分析(OLAP)混合场景的关系型数据库.HybridDB采用一份数据存储来进行OLTP和OLAP处理,解决了以往需要把一份数据多次复制来分别进行业务交易和数据分析的问题,极大地降低了数据存储的成本,缩短了数据分析的延迟,使得实时分析决策称为可能. HybridDB for MySQL兼容MySQL的语法及函数,并且增加了对Oracle常用分析函数的支持,100%完全兼容TPC-H和TPC-DS测试标准,从

HybridDB for MySQL 实现在线与离线数据分离的实践

本文将重点介绍HybridDB for MySQL 实现在线与离线数据分离的实践,特别推荐! 核心业务简介 任务中心汇聚了集团的所有工作流任务,并提供统一的入口给用户处理集团的工作任务. 面临主要问题 1.单表存储量超高目前已有4千万的数据,并且在急速的增长.预计年增长在200%以上. 2.业务需要大范围的查询由于业务需要查询多张表,比如查询在线,再查离线表.而且频率和复杂度在提升.会导致慢sql的出现. 如何架构改造 在线数据与离线数据隔离,在数据访问层面不相互影响  在线数据到离线数据必须实

分布式HTAP数据库PetaData(HybridDB for MySQL) —— OLTP与OLAP一站式解决方案

一.前言       在大数据推动行业发展的年代,大型企业级应用往往选择多种数据库产品,分别支持在线交易.报表生成.日志存储.离线分析等,用以驱动业务的高速发展,但这种组合式解决方案,需要精细的控制不同产品间的数据流转和一致性问题,使用难度颇高,每个数据库产品间的数据同步和冗余,也带来了很高的成本开销,进一步限制了企业级应用的发展.       近年来Gartner提出了HTAP数据库概念,一个数据库既能支持OLTP(在线事务处理),又能支持OLAP(在线分析处理),涵盖大部分企业级应用的需求,

【沉淀】实例迁移、Insert和写入性能——数倍,甚至数十倍提升,HybridDB for MySQL负责人王骞谈自己经历和收获

<沉淀>是展示专家风采的人物栏目.它呈现每个专家独一无二的人生经历.认识和感悟的同时,也能帮助你沉淀技术,收获对技术和人生的判断.我们的想法是:"若你想精进为一个很厉害的人,不妨细细品味这些技术牛人背后的沉淀."如果你想了解这些云栖专家更多分享时,请点击云栖专家频道,当然我们也欢迎你往前走一步,成为我们的云栖专家(https://yq.aliyun.com/expert),与技术大牛一起"煮酒论英雄". 技术人是怎样的一群人?一千个人,或许有一千个答案.

基于HybridDB for MySQL的企业ODS方案

随着DT时代的到来,数据的价值日益凸显.企业积累的数据越来越多,数据库的规模也达到成百上千个实例,数据的规模更可能达到上百TB甚至PB级.如何以合理的成本管理并维护海量实例,利用尽可能短的时间窗口进行挖掘分析,成为各个企业IT管理中的核心问题. 当前方案,在线处理和离线分离,系统架构详见下图  常见业务场景 1.为了满足分析需要,ETL策略为ELT(Extraction-Loading-Transformation),将全量数据同步到大数据平台中(MaxCompute.EMR.或自建Hadoop