夏天了，和Doris一起减肥吧！

❝

你有没有发现，数据库和人一样，都有发胖
的烦恼？ 

年初的时候，数据库还是个苗条的"小鲜肉"，几个T的空间绰绰有余。

半年过去，它已经变成了一个200斤的"胖子"，硬盘空间告急，查询速度慢得像蜗牛爬行。 

更要命的是，删数据就像减肥一样痛苦——每一条记录都舍不得删，就像每一块肥肉都有它存在的"理由"。 

好在，Doris的减肥教练
出现了，它有一套独特的"瘦身秘籍"，能让你的数据库在不节食的情况下成功减重。

减肥的第一步：了解"肥胖"的原因

人会发胖，往往是因为吃得多、动得少、新陈代谢慢。数据库"发胖"的道理也差不多。

传统的行式存储
好比胡吃海塞的减肥失败者，什么都往肚子里塞：张三的姓名、年龄、工资混在一起存，李四的信息又是另一堆。

这种存储方式就像把不同食物胡乱混合，既不好消化，也不利于"减重"。

Doris采用的列式存储
就像科学的营养搭配，把相同类型的数据分类存放：所有的姓名放一起，所有的年龄放一起，所有的工资放一起。

这就像把蛋白质、碳水化合物、维生素分开管理，既有利于"消化"，也更容易"瘦身"。

Doris的3种"减肥方法"

正如减肥有跑步、游泳、瑜伽、节食等不同方法，Doris提供了常用的3种不同压缩算法，每种都有自己的"减肥理念"：

LZ4：快速减肥法

LZ4很像那种"7天瘦10斤
"的快速减肥法，效果立竿见影。

虽然减重幅度不是最大的，但是速度奇快，是Doris的默认首先。

ZSTD：明星减肥法

ZSTD则是那些明星用的高端减肥
方案，既要效果好，又要速度快，还要能根据不同需求调整"减肥强度"。

你可以选择温和的"减肥模式"保持速度，也可以选择激进的"暴瘦模式"追求极致的压缩效果。

Snappy：懒人减肥法

Snappy信奉"减肥不是目的，健康才是目标
"的理念。

它不追求极致的压缩比，但是解压速度超快，就像那种"不用节食不用运动"的懒人减肥法，虽然减重效果一般，但是毫不痛苦。

而在Doris里给数据库"减肥"就像下载一个减肥APP一样简单：

CREATE TABLE example_table (
    idINT,
    nameSTRING,
    age INT
)
DUPLICATEKEY(id)
DISTRIBUTEDBYHASH(id) BUCKETS 10
PROPERTIES (
    -- 设置压缩算法
    "compression" = "zstd"
);

这和在减肥APP里设置"目标体重"如出一辙，一个简单的compression
配置，就能让你的数据库开始"瘦身"之旅！

数据的"体质"决定减肥效果

但在现实生活中，有些人"喝水都胖"，有些人"怎么吃都不胖"，不同类型的Doris数据减肥效果也大不相同。

有序数据：易瘦体质

时间戳、递增ID这类有序数据就像那些"天生丽质"的瘦子，稍微运动一下就能看到明显效果。

10086, 10087, 10088...这种规律性强的数据，压缩算法一眼就能找到规律，轻松实现"减重"。

重复数据：减肥潜力股

重复值多的数据就像那些"虚胖"的人，看起来很大只，实际上都是"水分"。

员工表里的部门字段，可能就那么几个值重复出现，压缩算法会说："这不就是换汤不换药吗？我用几个代号就搞定了。"

乱序数据：顽固性肥胖

随机分布的数据则是那些"顽固性肥胖"患者，怎么减都减不下来。

比如一些加密后的字符串这些毫无规律的数据，压缩算法表示"臣妾真的做不到啊
"。

空值数据：负卡路里食物

空值（NULL）在数据压缩里真就是芹菜在减肥食谱里的地位——消化它们消耗的能量比它们提供的还多。

数据表里空值越多，压缩效果越好，和吃负卡路里食物一样，越吃越瘦。

当然，在数据压缩成功后，类似减肥成功一样，需要持续的"维持"。

Doris的按页压缩
会通过"少食多餐"的维持策略，把大块的数据分成小页面，每个页面独立压缩。这样既保证了压缩效果，又避免了"一口气吃太多"导致的性能问题。

并且会在压缩前进行编码预处理
，好比减肥前的"排毒"，先把数据整理成最适合压缩的形式，并在减肥前先调理肠胃一样，事半功倍！

结语

Doris数据压缩和人类减肥有着惊人的相似性：都需要科学的方法，都要根据自身情况选择合适的策略，都需要持之以恒的坚持。

下次当你的数据库又"发胖"的时候，不要再纠结删哪些数据了。

让Doris来帮你的数据库"科学减肥"吧，毕竟，谁不想要一个既苗条又健康的数据库呢？