GaussDB技术解读系列：高级压缩之OLTP表压缩

关注

原创 2023-08-23 17:08:54 1k 阅读 AI 写同款· GEO 优化 ›

本文分享自华为云社区《DTCC 2023专家解读 | GaussDB技术解读系列：高级压缩之OLTP表压缩》，作者：GaussDB 数据库。

8月16日，第14届中国数据库技术大会（DTCC2023）在北京国际会议中心顺利举行。在GaussDB“五高两易”核心技术，给世界一个更优选择的专场，华为云数据库GaussDB首席架构师冯柯对华为云GaussDB数据库的高级压缩技术进行了详细的解读。

以下为演讲实录：

各位嘉宾，大家下午好！很高兴由我开始给大家带来今年GaussDB一系列新特性的技术解读。我解读的是第一个特性，高级压缩。

GaussDB高级压缩全景

高级压缩是面向业务全场景的数据库压缩解决方案，适用的场景主要分两类。第一类是存储类，主要为业务提供容量控制，减少业务扩容的概率和成本；第二类是传输类，主要是面向跨Region、跨AZ的业务场景如何去匹配业务的网络带宽的现实条件，为业务提供更稳定的SLA保证。这里面又有很多细分的场景，TP、AP都有。

这里面有非常多的挑战，一是压缩算法怎么设计，二是怎么做冷热判定。我们在整个存储类的压缩里用的都是选择性压缩，基于系统自动发现数据的冷热，只压缩业务中相对比较冷的数据，不去碰相对热的数据。包括实现业务的零侵入、和存储引擎的结合，有很多技术挑战。

典型场景和目标设计

不同的场景对于压缩算法，包括压缩率、业务影响、业务侵入容忍度是不一样的。这里要介绍的，是我们第一个发布的OLTP表压缩的技术细节。讲这个之前，先讲一下OLTP表压缩究竟解决的是什么样的客户场景，这决定了我们整个技术目标。

有两个典型场景是我们在真实业务中碰到的。第一个场景，客户的业务来自于IBM小机，整个单库容量达到几十个TB，容量比较大。业务如果迁移到开放平台，比较大的问题是单体容量太大，整个运维窗口的时间比较长。我们有不同的选择，可以选择大家说的拆库，也就是分表分库，但拆库意味着需要做整个分布式改造，对有些业务来讲是很多年的存量的关键业务，这种改造方式整个风险是非常高的。第二个选择可以用压缩，压缩可以减少容量，但客户在业务设计的开始并没有做冷热分离，比如没有把用户的数据基于时间维度做分片，如果用压缩，客户首要的诉求是能否做到压缩对业务的影响足够低，其次才是压缩率，这是第一个典型场景。

第二个典型场景，客户业务基于分布式集群部署，容量增长得非常快，已经超过一个PB，并且还在不断增长。对于客户来讲，这是非常大的问题，需要定期做扩容。使用压缩同样可以帮助客户减少扩容的频率、变更的风险。但问题是一样的，客户数据同样没有做冷热分离，是面向扩展性来设计的，比如基于用户ID号进行分片，让不同用户的负载能够平均分配给不同的数据节点。由于没有做冷热分离，如果要用压缩，能否做到压缩对于业务的影响足够低，其次才是压缩率。这也是我们看到的非常典型的OLTP压缩的场景。

我们对这两个场景进行了分析，推导出三个基本的设计目标。首先，整个压缩方案必须是零侵入的，不能假设业务的已有数据分布，不能说建一个分区，数据一定能区分冷热，因为业务没有这样的条件。不能对业务的数据分布、逻辑模型有任何的假设，方案必须是零侵入的。第二，如果业务开启压缩，对业务的影响应该是极低的，我们定义至少10%，甚至5%，这是非常重要的。第三才是合理的压缩率，2：1或3：1，如果没有压缩率，做这些事情的价值就不存在了。这三个基本目标也决定了我们后面整个技术方案的设计和工程落地。

关键挑战一：如何判定业务的冷热数据？

确定完目标，有三个比较关键的问题需要解决。一是怎么判定业务的冷热数据，二是判定完之后怎么和现有的压缩引擎结合，对压缩后的数据有效地存储，第三点才是怎么实现有竞争力的压缩算法。

我们做冷热判定，首先是确定判定的粒度。可以按照表、分区、块来判定，也可以按照行来判定。判定的粒度越细，意味着对业务的侵入越低，对业务整个数据分布没有任何假设，当然实现的挑战也越大。基于我们定义的技术目标，在做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性能峰值仍然能够开启压缩并且性能基本不下降的产品。

下一步计划：语义压缩

我们已经打破了数据编码和压缩算法的边界，但对压缩算法的使用本质上没有变化，即把整个数据看成是一维的字节流。但关系数据是两维的、结构化的数据，所以在数据的行与行之间、列与列之间存在非常丰富的关联。这种关联主要来自两种场景，一种是业务本身在做建模时引入的关联，比如为了消除连接，数据模型设计成扁平化或低范式化，这会引入非常常见的关联。第二种是业务服务化改造进行服务的分层，数据在不同的服务分层之间被不断传递而造成的一种关联。我们通过一些算法自动发现这种结构化数据之间的关联，发现这些关联不是用于商品推荐或者服务治理，而是希望通过消除这些关联达到压缩的目的。在很多场景里，这种基于语义的关联消除技术会比通用算法提供更好的压缩效能，这是我们后面会重点去构建竞争力的地方。