高级压缩是面向业务全场景的数据库压缩解决方案，适用的场景主要分两类。第一类是存储类，主要为业务提供容量控制，减少业务扩容的概率和成本；第二类是传输类，主要是面向跨Region、跨AZ的业务场景如何去匹配业务的网络带宽的现实条件，为业务提供更稳定的SLA保证。这里面又有很多细分的场景，TP、AP都有。
这里面有非常多的挑战，一是压缩算法怎么设计，二是怎么做冷热判定。我们在整个存储类的压缩里用的都是选择性压缩，基于系统自动发现数据的冷热，只压缩业务中相对比较冷的数据，不去碰相对热的数据。包括实现业务的零侵入、和存储引擎的结合，有很多技术挑战。
典型场景和目标设计
有两个典型场景是我们在真实业务中碰到的。第一个场景，客户的业务来自于IBM小机，整个单库容量达到几十个TB，容量比较大。业务如果迁移到开放平台，比较大的问题是单体容量太大，整个运维窗口的时间比较长。我们有不同的选择，可以选择大家说的拆库，也就是分表分库，但拆库意味着需要做整个分布式改造，对有些业务来讲是很多年的存量的关键业务，这种改造方式整个风险是非常高的。第二个选择可以用压缩，压缩可以减少容量，但客户在业务设计的开始并没有做冷热分离，比如没有把用户的数据基于时间维度做分片，如果用压缩，客户首要的诉求是能否做到压缩对业务的影响足够低，其次才是压缩率，这是第一个典型场景。
第二个典型场景，客户业务基于分布式集群部署，容量增长得非常快，已经超过一个PB，并且还在不断增长。对于客户来讲，这是非常大的问题，需要定期做扩容。使用压缩同样可以帮助客户减少扩容的频率、变更的风险。但问题是一样的，客户数据同样没有做冷热分离，是面向扩展性来设计的，比如基于用户ID号进行分片，让不同用户的负载能够平均分配给不同的数据节点。由于没有做冷热分离，如果要用压缩，能否做到压缩对于业务的影响足够低，其次才是压缩率。这也是我们看到的非常典型的OLTP压缩的场景。
我们对这两个场景进行了分析，推导出三个基本的设计目标。首先，整个压缩方案必须是零侵入的，不能假设业务的已有数据分布，不能说建一个分区，数据一定能区分冷热，因为业务没有这样的条件。不能对业务的数据分布、逻辑模型有任何的假设，方案必须是零侵入的。第二，如果业务开启压缩，对业务的影响应该是极低的，我们定义至少10%，甚至5%，这是非常重要的。第三才是合理的压缩率，2：1或3：1，如果没有压缩率，做这些事情的价值就不存在了。这三个基本目标也决定了我们后面整个技术方案的设计和工程落地。
