拆解腾讯云 TDSQL Boundless 的底层逻辑

大家好，我是德哥。我刚看完2026 腾讯全球数字生态大会上潘安群老师的演讲《多模一体：AI 数据底座》，核心提到通过 TDSQL Boundless 这个产品的一套内核，统一承载事务、宽表、分析、检索、向量、冷存。

今天想跟大家聊聊我对 TDSQL Boundless 这个产品底层逻辑的理解。

一、先看"病因"：负载形态裂开了

要拆解这个产品的底层逻辑，必须先找到这个产品瞄准的目标场景，毫无疑问是AI，TDSQL Boundless 要成为AI时代的数据底座。

所以潘老师开场就提到了AI时代数据在"急剧分化"。这话听着平淡，但你细品 —— 过去数据库的世界是二元的：OLTP管交易，OLAP管分析，负载曲线是平滑的、可预测的，今天跟明天差不多，波动了就是异常，要报警。

现在，企业级Agent可能瞬间指数级爆发。同一个底座上，过去可能是阶段性"几乎零访问"，现在是"瞬间爆量"。

这会让用户在做预算时陷入一个死结：你按峰值配资源，那99%的时间在烧钱；你按谷值配资源，峰值来了直接跪。所以潘老师说产品一定要具备这样的能力"最小的时候把成本降到最低，增长的时候快速扩展" —— 这不是一句口号，这是被负载形态逼出来的刚性约束。

所以我的个人理解是 TDSQL Boundless 的逻辑起点在这儿，后面所有的架构设计都是为解这个死结。

二、第一刀：把存储和计算彻底劈开

要同时满足"零访问时几乎不花钱"和"爆量时秒级扩展"，传统那套"存算一体"的架构根本没戏 —— 你的数据躺在计算节点的本地盘上，想缩到零？占着空间和计算资源呢，物理条件不允许。想扩？得搬数据。

所以 TDSQL Boundless 的第一刀非常精准：基座换成对象存储COS。好处是"任何一个指令形态的计算机都可以访问到"，"数据在COS上面不需要在不同的引擎之间做搬迁"。一旦原始数据在COS上"定居"了，计算引擎就变成了纯粹的无状态打工仔 —— 来活了就拉起，没活就缩到零（即Scale to zero）。

OK，既然计算引擎是无状态的、可插拔的，那"一个引擎包打天下"的执念就自动破产了。关系型引擎建B树索引，向量检索建向量索引，全文检索建全文索引，各干各的，都在COS那份原始数据上建自己的索引。

三、第二刀：为什么要用开放格式？因为要"让客户放心"

潘老师反复强调 TDSQL Boundless 采用了开放标准格式 —— Parquet、Iceberg，接入层用开放协议。他给的理由很坦诚："客户在使用腾讯数据库的时候他也是放心的，他完全可以迁移到其他地方去。"

这就是格局啊，你想把数据格式开放了，迁移成本就低了。开放格式降低的是不仅仅是用户的使用、学习成本，同时也降低了"退出成本"。

四、第三刀：宽表引擎，暴露了AI数据的真实形状

TDSQL Boundless 支持上万列的宽表引擎：这一万列不是一次性写进来的。举个例子，一辆车不同传感器在不同时间点、不同请求里分别写入，最后查询时却要"以一行方式读出去"。

传统数据库的行式存储根本做不到，得不断 update ，造成一堆的问题。怎么办？TDSQL Boundless 的解法是追加写 + 底层合并 + 按列裁剪读取。写的时候不断追加，读的时候只扫客户要的那几列，"需要什么只扫那几列，不会多余列"。

仔细想想，你就会发现宽表引擎设计背后的逻辑链：AI 数据天生是稀疏的、异步到达的、列粒度访问的（自动驾驶每帧成千上万的标签、Agent的访问轨迹）。所以存储组织方式必须跟着数据的真实形状走，而不是让数据去迁就引擎的舒适区。这跟前面"每种数据都是一等公民"的总结是同一个逻辑的两面 —— 不是把多模态数据硬塞进关系模型，而是让底层为每种数据形态留出它该有的位置。

五、第四刀：冷热分层到"字段级"，这是成本逻辑推到极致

我看过太多做冷热存储的产品了，基本上都是按表、按时间冷却数据，但冷却都是按行进行的。

字段级冷热分离我还头一回听说，但是，这不是炫技特性，这是真实存在的需求。

AI场景里那个存对话消息、掺着大量图片的字段，可能占了整张表90%以上的空间。传统做法是整表降冷，但元信息字段还得热着做分析。TDSQL Boundless 把这一个字段单独扔进对象存储，其他字段留在本地盘，一条SQL搞定生命周期管理。

这刀砍下去，逻辑还是前面那条链的延伸：既然存储基座是COS、数据是开放格式、引擎是无状态的，那"冷热分层"的粒度凭什么只能到表、行？粒度可以细到字段，因为拆分和重组在存算分离架构里本来就只是元数据层面的操作。成本从"队列存储和本地盘差10倍"这个数字看，字段级拆分省下来的钱是实打实的。这就是把"极低成本"这个目标从口号推到了工程实现的末梢。

六、总结：一体化不是拼装，是"元数据统一、索引各管各"

一体化"并不是一个简单的拼装，必须构建出统一的体系"。怎么统一？元数据统一放一处，索引各引擎自建。

COS存原始数据（统一）、开放格式（可互操作）、多引擎各建索引（按垂直场景专业化）、存算分离（弹性）、字段级冷热分层（成本）。统一的是"数据的家"和"数据的身份证"（元数据），分散的是"查数据的最优路径"（索引）。这个切分之所以合理，是因为元数据统一解决了"搬家"问题，索引分散解决了"效率"问题。

听完潘老师的分享，我对 TDSQL Boundless 设计理念终于有了深刻的理解：TDSQL Boundless 这套东西，不是"在旧数据库上加 AI 功能"，而是"因为 AI 负载把旧架构的假设全推翻，底层重做"。负载从平滑变尖峰、数据从结构化变多模态、应用从稳定变突发 —— 三个变化各自逼出一个架构决策：存算分离、多引擎开放格式、字段级弹性分层。最后造就了 TDSQL Boundless 的"元数据统一、索引分散"一体化体系。