前言:在能源数字化赛道上,能链作为中国充电服务第一股,连接着近2.5万座加油站、占据全网21%的公用充电枪份额,服务着上亿车主与上万家企业。当年化交易额突破1000亿元,随之而来的是海量且呈指数级增长的订单数据,每一笔“团油”的加油记录,每一次“能链智电”的充电脉冲,每一张“能程科技”的供应链流转单,都是数据资产,也是沉重的历史包袱。 如何让这些 TB~PB 级的历史账单既能低成本安家,又能随时被业务端毫秒级唤醒?

腾讯云 TDSQL Boundless 给出的答案是:用 LSM Tree 硬核技术,把数据压进30%的空间里。

以前的日子,难,真的难

在选择腾讯云 TDSQL Boundless 之前,我们为了处理海量历史订单的归档,考虑过的方案包括:

方案一:MySQL 大容量物理机归档

这是最常见的“土办法”,堆硬件。买台配着 50T 大容量的廉价磁盘、大内存的机器,搭个 MySQL 做归档库,通过 pt-archiver 或者 DTS 工具周期性归档。存储成本要求再低一点,就选择使用 tokudb 引擎进一步压缩数据。整套流程 DBA 非常熟悉,但在降本增效的大背景下,方案显得不那么舒服。归档实例平时 CPU 和内存几乎 99% 闲置,只有查数据那一下才动弹。更可怕的是,为了尽可能节约成本,我们不敢搭建从库,备份起来更费劲。一旦硬盘坏了,数据恢复周期长到怀疑人生。这不叫归档,这是"裸奔"。

方案二:购买 Serverless 实例归档至二级存储

“不用不付费的” Serverless 归档方案,有效解决了单实例低算力、大存储规格的资源匹配痛点。但在数据归档场景中,这类数据库存在两项天然短板:其一,存储成本控制能力不足,其一级存储层普遍缺乏高效压缩机制,导致海量归档数据的存储成本居高不下;其二,归档数据并非静态冷数据,客服核验、审计追溯、用户查询等场景均存在随机访问需求。而云原生 Serverless 实例在闲置状态下会自动休眠,数据随之回落至对象存储(COS);当有查询请求触发时,实例需先完成唤醒流程,同时从对象存储拉取目标数据。这种模式不仅会带来明显的查询延迟,频繁的 “休眠 - 唤醒 - 数据拉取” 循环所产生的资源调度与数据传输成本,经整体核算后,也并不具备经济性优势。

方案三:购买云 MySQL 进行归档

直接购买云厂商的 RDS 实例进行归档,方案看起来省事,其实最不划算,体现为存不下、压不住、贵得很。存不下,单个 RDS 实例撑死 32TB 或者 64TB,时间长了,又得苦哈哈的去搞分库分表;压不住,传统 InnoDB 引擎的页压缩能力有限,真金白银买的云盘,一半空间存的都是空洞;贵得很,归档数据搭配高性能云盘,成本根本降不下来。

方案四:改用MariaDB S3 引擎,把数据冻起来

那么,利用 MariaDB 的 S3 引擎把数据转存到对象存储,冻起来,行不行。尴尬在,这是一条单行道,数据先写到 InnoDB 引擎,再通过 ALTER TABLE ... ENGINE=S3 沉降到对象存储。这个转换过程慢得像蜗牛,而且一旦转成 S3 引擎,表就变成了只读(Read-Only)。想改数据?不行。想追加写入?不行。这存下的不是数据,是“标本”。迫不得已,万一要修改,则要重新跑一轮 ALTER TABLE ... ENGINE=InnoDB 改回 InnoDB 引擎。 哪些数据能归档,哪些数据不能归档,成了留给DBA和业务研发永恒的难题。

面对海量数据归档,腾讯云 TDSQL Boundless 提供给能链的方案不是妥协,而是 – 存得下(无限容量)、存得省(极致压缩)、易扩展(弹性伸缩)、查得快,还能备份、敢恢复。

硬核解密:为什么 LSM Tree 能做到 5 倍压缩

在能源历史订单归档场景的实测中,TDSQL Boundless 相比传统的 InnoDB 引擎,跑出了 5:1 的压缩比。也就是说,原本需要 100TB 存储空间的加油与充电订单,现在只需要 20TB 即可完美容纳。

这不仅仅是把文件压缩一下那么简单,这是数据结构维度的降维打击:

从 B+ 树到 LSM Tree 的进化: InnoDB 的 B+ 树为了维持查询与写入效率,页面中必然存在大量的“空洞”和碎片,尤其是在能链这种高并发随机写入场景下,空间利用率往往只有 50%-70%。 TDSQL Boundless 基于 LSM Tree(Log-Structured Merge-tree),将所有的随机写在内存中聚合,转化为磁盘上的顺序写(Append-only)。数据在磁盘上紧凑排列,没有任何“空洞”,从物理结构上就赢在了起跑线。

请在此添加图片描述

Block 级压缩 vs Page 级压缩: TDSQL Boundless 引入了更细粒度的 Block 压缩机制。结合 ZSTD 等先进压缩算法,它能对数据块进行深度去重。

前缀压缩(Prefix Encoding)与差值编码: 在能源订单场景中,大量的订单号、时间戳、用户 ID 具有极高的相似性(例如:202310010001, 202310010002...)。TDSQL Boundless 能够智能识别这些重复前缀,只存储“变化量”。这种针对特定数据类型的极致编码优化,是实现5倍压缩比的幕后功臣。

请在此添加图片描述

不止是“省”,更是“活”:无限归档与极速查询

对于我们而言,省钱只是基础,“数据在归档后依然是活的” 才是核心诉求。

腾讯云 TDSQL Boundless 为订单归档场景带来了根本性变革。当历史订单从数十TB 涨到 PB 级别,我们不再需要像以往那样采购新的 RDS 实例并启动复杂的DTS 同步流程。腾讯云 TDSQL Boundless 的数据增长对用户完全透明,按需水平扩容添加节点即可实现平滑扩容。 相比于 RDS,TDSQL Boundless 在架构上更适应海量数据的弹性扩展;相比于 Hadoop,TDSQL Boundless 免去了维护复杂的生态组件的负担,不仅内置了 Multi-Raft 的高可用机制,更提供了强大的二级索引功能,使数据访问更加高效灵活。

请在此添加图片描述

很多人担心:压缩这么狠,查起来会不会慢? 腾讯云TDSQL Boundless 利用 Bloom Filter(布隆过滤器) 和多级缓存策略,精准定位数据块。对于“查询三年前某位用户的电费明细”这种典型点查场景,性能几乎与热数据无异。 它不像 MariaDB S3 引擎那样“死板”,TDSQL Boundless 的归档表依然支持读写,依然支持事务,依然是熟悉的 MySQL 协议。

结语:给历史数据一个高性价比的家

在降本增效的大背景下,腾讯云 TDSQL Boundless 为能源行业提供了一种全新的解题思路:不再需要为了归档数据去购买昂贵的服务器做“摆设”,也不需要忍受只读引擎的笨重。通过技术红利,腾讯云 TDSQL Boundless 让每一比特的数据存储成本降低了 70% 以上,同时保留了随时挖掘历史数据价值的能力。

存得下海量过往,才算得清未来账单。

文章来源于腾讯云开发者社区,点击查看原文