。

在GaussDB“五高两易”核心技术#xff0c;给世界一个更优选择的专场#xff0c;华为云数据库GaussDB首席架构师冯柯对华为云GaussDB数据库的高级压缩技术进行了详…

8月16日第14届中国数据库技术大会DTCC2023在北京国际会议中心顺利举行。

在GaussDB“五高两易”核心技术给世界一个更优选择的专场华为云数据库GaussDB首席架构师冯柯对华为云GaussDB数据库的高级压缩技术进行了详细的解读。

GaussDB高级压缩全景

高级压缩是面向业务全场景的数据库压缩解决方案适用的场景主要分两类。

第一类是存储类主要为业务提供容量控制减少业务扩容的概率和成本第二类是传输类主要是面向跨Region、跨AZ的业务场景如何去匹配业务的网络带宽的现实条件为业务提供更稳定的SLA保证。

这里面又有很多细分的场景TP、AP都有。

这里面有非常多的挑战一是压缩算法怎么设计二是怎么做冷热判定。

我们在整个存储类的压缩里用的都是选择性压缩基于系统自动发现数据的冷热只压缩业务中相对比较冷的数据不去碰相对热的数据。

包括实现业务的零侵入、和存储引擎的结合有很多技术挑战。

典型场景和目标设计

不同的场景对于压缩算法包括压缩率、业务影响、业务侵入容忍度是不一样的。

这里要介绍的是我们第一个发布的OLTP表压缩的技术细节。

讲这个之前先讲一下OLTP表压缩究竟解决的是什么样的客户场景这决定了我们整个技术目标。

有两个典型场景是我们在真实业务中碰到的。

第一个场景客户的业务来自于IBM小机整个单库容量达到几十个TB容量比较大。

业务如果迁移到开放平台比较大的问题是单体容量太大整个运维窗口的时间比较长。

我们有不同的选择可以选择大家说的拆库也就是分表分库但拆库意味着需要做整个分布式改造对有些业务来讲是很多年的存量的关键业务这种改造方式整个风险是非常高的。

第二个选择可以用压缩压缩可以减少容量但客户在业务设计的开始并没有做冷热分离比如没有把用户的数据基于时间维度做分片如果用压缩客户首要的诉求是能否做到压缩对业务的影响足够低其次才是压缩率这是第一个典型场景。

第二个典型场景客户业务基于分布式集群部署容量增长得非常快已经超过一个PB并且还在不断增长。

对于客户来讲这是非常大的问题需要定期做扩容。

使用压缩同样可以帮助客户减少扩容的频率、变更的风险。

但问题是一样的客户数据同样没有做冷热分离是面向扩展性来设计的比如基于用户ID号进行分片让不同用户的负载能够平均分配给不同的数据节点。

由于没有做冷热分离如果要用压缩能否做到压缩对于业务的影响足够低其次才是压缩率。

这也是我们看到的非常典型的OLTP压缩的场景。

我们对这两个场景进行了分析推导出三个基本的设计目标。

首先整个压缩方案必须是零侵入的不能假设业务的已有数据分布不能说建一个分区数据一定能区分冷热因为业务没有这样的条件。

不能对业务的数据分布、逻辑模型有任何的假设方案必须是零侵入的。

第二如果业务开启压缩对业务的影响应该是极低的我们定义至少10%甚至5%这是非常重要的。

第三才是合理的压缩率21或31如果没有压缩率做这些事情的价值就不存在了。

这三个基本目标也决定了我们后面整个技术方案的设计和工程落地。

确定完目标有三个比较关键的问题需要解决。

一是怎么判定业务的冷热数据二是判定完之后怎么和现有的压缩引擎结合对压缩后的数据有效地存储第三点才是怎么实现有竞争力的压缩算法。

我们做冷热判定首先是确定判定的粒度。

可以按照表、分区、块来判定也可以按照行来判定。

判定的粒度越细意味着对业务的侵入越低对业务整个数据分布没有任何假设当然实现的挑战也越大。

基于我们定义的技术目标在做OLTP表压缩时第一个目标就是冷热判定必须是行级别的这样对业务的侵入是最小的。

我们利用了GaussDB现有存储引擎已有的机制。

GaussDB现在的存储引擎和其他引擎一样在整个数据上除了存放用户数据之外还存放元数据元数据里有事务信息这个事务信息通常是用来实现事务的可见性里面记录了最后一次修改的事务ID号。

当这个事务ID号足够老对于当前所有事务都可见这个时候我们把事务ID号替换成物理时间戳这个物理时间戳可以用来表达这行数据最后一次修改的时间是什么时候如果这个时间足够早、足够老真正达到了冷的条件那么我们就可以对它进行压缩用户可以用非常简单的逻辑实现冷热的判定。

第二个例子是用户可以自定义冷热条件这个行如果长时间没有做任何修改系统就可以把它压缩掉否则不要碰这是一个非常简单的策略。

如果客户业务中有一些字段有非常清楚的冷热属性比如交易的时间、交易的完成状态那可以指定这个字段进行冷热判定。

或者客户大部分的交易数据都满足3个月前的交易是冷数据但其中某些特殊类型的交易像担保交易可能没有办法满足这个约束这时候也可以自定义冷热条件。

比如交易状态必须是完结的或者交易类型不能是特定类型通过自定义条件和最近修改时间的组合可以灵活地定义什么样的数据应该压缩。

这是第一点怎么做冷热判定。

第二点压缩后的目标数据怎么存。

根据总体设计目标我们希望做到对业务的侵入越低越好。

我们选择了直接做块内的压缩把一个块内所有满足冷热判定的行一次性压缩完把压缩后的数据包就存放在当前数据块内。

这样做从压缩率上讲并不是最优选择但从对业务的影响上讲是一个更好的选择。

因为业务即使定义了冷热判定条件我们仍有一定的概率会访问冷数据我们希望通过块内压缩的实现来保证访问冷数据的代价有一个确定性的上限这是块内压缩的基本思考。

为什么做选择性压缩很简单没有任何一个压缩算法能做到数据压缩之后对业务没有影响今天没有这样的黑科技这是我们基本的技术判断所以要去平衡压缩率和对业务的影响。

我们首先做的是选择性压缩业务数据分布满足典型的80-20分布政策80%的数据占有80%的存储容量但只消耗了20%的算力。

比如银行交易随着时间的推移整个订单的访问频率会迅速降低这是非常典型的满足冷热特征的业务。

如果做选择性压缩那么只压缩那些占用80%存储容量但只消耗20%算力的冷数据就意味着我们在节省存储成本方面达成了80%的目标而不去压缩那些只占用20%的存储容量但却消耗80%算力的热数据就意味着我们在降低对用户的业务影响方面达成了80%的目标这是非常简单的技术选择。

压缩算法我们也看了一些比如LZ4是现在性能最好的算法我们一开始用的就是这个算法但比较大的问题是压缩率相对较低。

如果仔细去分析算法原理LZ4是基于LZ77算法的一种实现是把压缩的数据看成一个连续的字节流从当前开始寻找匹配的字符串找到字符串长度和偏移进行编码来代替被匹配的字符串从而实现压缩的效果。

LZ77算法从原理上讲非常适合于长文本相对不太适合像结构化数据这样的里面有大量的数值类型和短文本这是数据库的特征。

我们做了很多优化比如对数值类型做了差值编码所以压缩框架实际上有两层第一层对数据做编码第二层用LZ77算法。

原生LZ77算法有很多优化是面向长文本的包括3字节的编码我们做了非常多的工程优化使它更容易面向短文本比如两字节短编码包括内置行边界。

这里我们无法给出很多细节主要的优化背景其实就两个一个是通用压缩算法并不特别适合于关系型数据库结构化数据的场景二是我们所做的这些工程优化从通用的压缩场景来讲并不一定是最优的但它们是特别适合关系型数据的。

竞争力评估

最后有一个简单的评估是通过TPCC和TPCH测试对目前的商用数据库O*进行的压缩率评估。

O*和我们的GaussDB一样也提供了完整的冷热判定能力但由于发展原因它实际上先做了数据压缩再做冷热判定所以整个压缩算法的压缩率是比较低的我们使用了标准的TPCH的数据测试表明我们的压缩率相对于O*平均提高了50%这些数据可以被直接验证。

其他的一些厂商像开源数据库还有国内的厂商都提供了压缩的解决方案但共同问题是没有做冷热判定对用户来讲可以指定一个表或一个分区里面的数据要么都被压缩要么都不压缩。

压缩意味着存储成本节省但性能会下降不压缩则是另外一个选择。

这个看上去简单的选择对客户来讲反而是最难的这也是为什么我们看到今天有很多压缩的解决方案但用户却不会去用因为谁也不知道开启压缩之后有什么后果这是比较大的问题。

这里我们也做了一个标准的TPCC的测试评估基于GaussDB单机版本进行选择性压缩。

根据TPCC的语义所有已经配送完成的订单就不会再变更但仍有一定的概率被访问到这是非常贴近于真实业务场景的访问模型。

所以我们的压缩算法选择了压缩流水类数据比如订单数据而一些状态类的数据比如库存、账户等没有去压缩在流水数据里我们也只压缩已经配送完成的订单不压缩没有配送完成的订单。

从最后的结果看整个压缩之后对于业务的影响在1.5%左右。

我们相信我们是业内第一个在150万tpmC性能峰值仍然能够开启压缩并且性能基本不下降的产品。

下一步计划语义压缩

我们已经打破了数据编码和压缩算法的边界但对压缩算法的使用本质上没有变化即把整个数据看成是一维的字节流。

但关系数据是两维的、结构化的数据所以在数据的行与行之间、列与列之间存在非常丰富的关联。

这种关联主要来自两种场景一种是业务本身在做建模时引入的关联比如为了消除连接数据模型设计成扁平化或低范式化这会引入非常常见的关联。

第二种是业务服务化改造进行服务的分层数据在不同的服务分层之间被不断传递而造成的一种关联。

我们通过一些算法自动发现这种结构化数据之间的关联发现这些关联不是用于商品推荐或者服务治理而是希望通过消除这些关联达到压缩的目的。

在很多场景里这种基于语义的关联消除技术会比通用算法提供更好的压缩效能这是我们后面会重点去构建竞争力的地方。

第一、是在性能敏感场景在提供合理的压缩率的前提下对业务的影响越小越好实现业内领先。

第二、是在成本敏感的场景在提供合理的压缩解压性能的前提下压缩率越高越好实现业内领先。

第三、大家可能注意到冷热判定本身不仅可以做数据压缩还可以做很多别的工作比如多存储介质、负载的感知我们希望对于整个冷热判定包括模型及方法在能够支持的业务领域的广度方面能够做到业内领先这是我们做高级压缩特性的一个基本目的。