RSS TiDB Blog 发布 2026-08-06 03:20 收录于 08-12 33

开源数据层将赢得AI未来

AI改变了重写应用代码的成本，但持久化数据层的迁移成本依然高昂。封闭数据平台会让路线图、定价和部署选择受制于人，而开源数据层能保留关键控制力。TiDB 已被 Kimi、Pinterest、Atlassian、Dify 等用于生产负载，证明开放性与规模化并非取舍。

推荐理由：数据从业者可借此评估AI时代数据平台选型，理解开放数据层在避免锁定和保持控制权方面的战略价值。

平台AI化PingCAPTiDB

译文 AI 逐段翻译

关键要点

AI 改变了重写应用程序代码的成本，而不是移动持久化状态的成本。数据层才是控制真正持续存在的地方。
封闭的数据平台让你的路线图、定价和部署选项成为他人的决定，集成越深入，逆转就越困难。
开源不仅是防止被锁定的保障，更是构建优势的场所。
Kimi、Pinterest、Atlassian 和 Dify 在 TiDB 上运行生产工作负载，这表明开放性和规模并非不可兼得。

在云时代的大部分时间里，基础设施决策遵循着熟悉的模式：选择最快上线的路径，接受一些专有依赖，然后优化。AI 打破了这种模式。编码代理现在可以在几小时内重塑应用程序，而模型、框架和工作负载形态在其下不断变化。

这使数据层成为公司最不能放弃控制的领域。其上的一切重写成本低廉，但持久化状态并非如此。这就是开源数据层的理由：在可选择性最重要的层面上保留可选择性。

你的数据层是你的控制平面

模型、应用框架和主导的代理架构都会改变。但 AI 应用程序的持久化状态保持不变：客户上下文、权限、事务、嵌入、对话历史、工作流状态和操作遥测都存在于数据层中。

这使数据库不仅仅是基础设施，它是应用程序记忆和行为的控制平面。

分层图显示 AI 模型、框架和代理架构是可互换的层，位于包含客户上下文、权限、事务和嵌入的持久化开源数据层之上。

图 1. 数据层之上的一切现在替换成本很低，但其中的状态并非如此。

封闭的数据平台将该控制平面置于一个供应商定义的边界之后。你继承了其路线图、定价、部署限制和架构假设。当你的业务需要供应商不支持的功能时，你只能等待，通过支持合同升级，或围绕限制进行重新设计。你不能自己解决问题，也不能将技术带到供应商未优先考虑的地方。集成越深入，你保留的控制就越少。

为什么开源数据层会改变权力平衡

开源数据层并不会消除切换成本，而是将硬依赖转化为一种选择。你可以阅读实现、自行运行、在不同环境间迁移、影响其方向，或选择不同的提供商，而这些选项都不需要供应商的许可。

无需等待路线图即可诊断和扩展

你也可以根据业务的具体需求来塑造数据层。你的工程师可以添加功能、优化热点访问模式或消除瓶颈，而不是提交功能请求。随着 AI 对稀缺算力的需求增加，削减 CPU、存储或数据移动的工作负载特定优化将直接反映在利润率上。

调试方式也发生了变化。当出现故障时，诊断不会止步于供应商的边界。你的工程师可以追踪失败路径、重现问题、部署临时解决方案或准备补丁，而不必在支持队列中等待。商业支持仍然重要，但它成为加速器，而不是获取答案的唯一途径。

这些改进会积少成多，形成建立在开放基础之上的专有技术：更快的产品、更低的成本结构或竞争对手无法快速复制的功能。开源不仅是防止被锁定的保障，更是构建优势的场所。

编码代理使开放性更有价值

编码代理提高了开放系统的回报。代理可以追踪代码库中的行为、诊断不兼容性、生成迁移工具、提出优化方案或构建缺失的集成。每一个可见的接口、测试、问题和实现细节都成为工程师及其代理的有用上下文。

封闭系统只暴露供应商选择记录的內容，而开放系统暴露了整个机制。随着软件创建变得更加自动化，检查并修改栈中每一层的权利变得更加珍贵，而不是相反。

AI 工作负载拒绝局限于单一环境

AI 应用通常从关系模式或文件系统开始。几个月内它就需要聊天记录、租户隔离、全文和向量搜索、工作流状态、分析以及快速增长的操作数据。代理会产生突发、并发、有状态且难以预测的工作负载。

数据层必须跨用户、事务、数据类型、区域和访问模式进行扩展，而无需强制重构应用程序。仅靠许可并不能实现这一点，架构才能。

TiDB：无上限的开源数据层

TiDB 是一个开源分布式 SQL 数据库：一个水平可扩展的系统，支持 SQL 并在节点间保持 ACID 事务。它提供与 MySQL 兼容的接口，并支持混合事务和分析处理（HTAP），允许事务和分析查询在同一系统中对相同数据运行。

TiDB Cloud 还提供了对代理友好的文件系统 API，为代理提供了两种处理相同数据的方式：通过 SQL 或通过熟悉的文件系统操作。这结合了文件系统的可访问性与关系数据库的结构、一致性和查询能力。代理可以通过自然的面向文件的界面导航和操作数据，而不会放弃底层数据库的保证和功能。

无状态 SQL 层独立于存储进行扩展。TiKV 使用 Raft 共识在存储节点之间复制数据并自动处理故障转移。TiFlash 在同一数据上提供列式分析读取，而 PD 管理放置和调度。TiDB 架构文档解释了这些组件如何协同工作。

这种组合是关键。没有运维成熟度的开放性无法在生产环境中生存，而缺乏可移植性的规模仅仅是换了一种形式的锁定。TiDB赋予组织机构按照自己的方式运行和修改技术的自由，其架构设计旨在无需重复修改应用程序即可扩展。它的MySQL兼容性为开发者和编码代理提供了他们已经理解的界面，而其文件系统API使同一数据库对代理来说更加自然、易于访问和使用。

生产部署展示了什么

讨论已经从理论走向生产。四家面临不同扩展问题的公司——AI原生托管、成熟的互联网规模、极端的多租户以及碎片化技术栈——都汇聚到同一个开源数据层上。它们公开发布的结果如下：

公司	问题	TiDB结果
Kimi（月之暗面）	Kimi的AI代理平台将提示转化为实时托管的应用程序，为每个生成的站点创建数据库需求。	亚秒级数据库供应，空闲时每站点零计算成本，单集群支持数千万并发的租户站点。
Pinterest	传统的图服务分散在HBase和MySQL中，应用层索引，积累了十年的技术债务。	使用TiDB重建为PinGraph：p99延迟降低高达10倍，基础设施成本降低超过50%，无需手动分片。
Atlassian	数百万的Forge租户，元数据爆炸，庞大的分片PostgreSQL体系。	750多个PostgreSQL集群整合为16个全球集群，一个系统中有超过300万张表，每个集群支持50万个并发活动连接。
Dify	将近五十万个隔离的数据库容器，涵盖向量、文档、聊天历史和关系数据。	统一系统，基础设施成本降低80%，运维开销减少90%。

Pinterest将TiDB的开源许可作为其选择标准之一。Manus大约在两周内迁移到TiDB Cloud，并在此之上运行代理上下文持久化。Plaud用TiDB Cloud替代了MySQL和Amazon S3，消除了转录文件块和元数据之间的应用层协调。所有这些公司的模式相同：工作负载超出了架构的承载能力，而检查和重塑数据层的能力缩短了解决问题的路径。