RSS TiDB Blog 精选发布 2026-07-31 00:31 收录于 08-12 38

Agentic AI 架构为何需要数据库，不只是向量存储

TiDB工程师在SCaiLE Europe 2026上论述，单独的向量数据库并非AI应用的必要代价，而是数据同步约束下的变通方案。每个新增AI组件都会复制一份数据，带来独立的接入路径、运维和同步任务，导致栈越堆越复杂。TiDB通过同一Raft流同步行存储、列存储、向量索引和全文索引，由SQL优化器决定查询走哪个存储。文章认为分布式SQL原生支持向量搜索与分析能力，可减少数据漂移和多系统运维成本。

推荐理由：数据从业者关注的多系统同步与数据一致性痛点，本文给出分布式数据库一体化方案，对构建Agentic AI数据栈有参考价值。

Data Agent 平台AI化湖仓PingCAPTiDB

译文 AI 逐段翻译

关键要点

AI 技术栈中加入的每个系统都保存着同一份数据的副本或切片，而每个副本都需要自己的摄取路径、自己的操作符和自己的同步任务。
向量是编码为数字的语义。逐一比较十亿个向量是负担不起的，这就是近似最近邻索引存在的原因。
TiDB 通过保持行存储一致性的同一条 Raft 流，向其列式存储、向量索引和全文索引提供数据。
SQL 优化器决定哪个存储回答查询的哪一部分。开发人员不需要标记存储引擎，也不需要编写查询计划。
写时复制分支在不复制数据的情况下，为代理提供生产数据的可写副本。

在现有技术栈中添加向量数据库。同步它。维护它。当它出现漂移时调试它。构建代理应用程序的团队在很大程度上已经接受了这一序列作为使用嵌入的入场券，而第四步是值得停下来思考的。漂移不是等待修复的偶发错误。它是将相同数据存储在独立更新的两个系统中的可预测结果。

在 2026 年 TiDB SCaiLE 欧洲大会上，TiDB 首席软件工程师 Mattias Jonsson 提出观点：独立的向量存储并非使用 AI 构建的代价。它是针对一个已经转变的约束的变通方法。这个论点分为两部分：多系统技术栈的实际成本远高于表面看起来的，涉及同步管道、运维专业知识和开发人员困惑；而向量搜索、列式分析和全文搜索都是分布式 SQL 数据库现在可以原生拥有的能力，由已经在其下运行的复制协议保持一致。

为什么 AI 技术栈会陷入数据同步地狱

问题不在于其中任何一个系统本身不好，而在于它们相互重叠。相同的数据或其片段落在所有这些系统中，这产生了三项成本，随着每次添加而成倍增加。

首先是同步。数据通过不同的摄取路径到达每个系统，通常是脆弱的提取-转换-加载管道，沿途添加、移除或分解数据。这些管道必须保持正确，因为涉及多个系统的查询必须返回一个答案。没有人希望一个系统反映刚刚写入的更新而另一个系统没有的结果。

第二是运维负担。每个系统需要自己的专业知识才能良好运行。四个系统意味着要么工程师深入了解所有四个，要么四个团队各自了解一个，外加负责它们之间管道的额外人员。更改一个系统，它的管道也会改变，这将工作传播到下游的每个系统。

第三是开发人员决策瘫痪。哪个系统持有这个问题的答案？此更新发往何处？谁保持其一致性？结果是弗兰肯斯坦式技术栈：一组组件组装成能运行的东西，但没有人能完全理解它。总拥有成本在许可、基础设施和运维方面上升，并且随着每个新系统的加入，它是成倍增加而非简单相加。

什么是向量以及为什么穷举比较无法扩展

向量是编码为数字的语义。嵌入模型接受输入（短语、图像或文档），并返回固定长度的浮点值列表。由于给定模型的每个输出具有相同的形状，比较变成了算术运算，这是计算机擅长的事情。最大的 OpenAI 嵌入模型每个对象产生大约 3,000 个维度。

这之所以重要，是因为仅靠文本比较在语义上会失败。“哪辆汽车速度最高”和“哪辆车最快”问的是同一个问题，但几乎没有任何共同字符。字面字符串比较找不到任何东西。向量弥补了这一差距，这就是为什么相似性搜索位于 AI 应用的基础而非边缘。

向量搜索也可以在纯 SQL 中运行。一个普通的 SELECT 按距离（通常是余弦距离）对结果排序，将问题的嵌入与存储在每个候选行中的嵌入进行比较，并返回最接近的匹配项。

问题在于规模。对少数行来说，每次比较大约 3,000 个数字是微不足道的。一百万行按生产标准来说是小数据库，而大数据库从十亿行开始。跨 3,000 个维度的十亿次比较在计算和时间上都很昂贵，而精确索引无法解决这个问题，因为高维向量数据无法像整数列那样被精确索引。有效的替代方法是近似。近似最近邻算法（其中 HNSW 是其中之一）接受了结果集可能遗漏一个元素或返回第六个最接近的匹配而不是第四个，以换取跨十亿行的高效搜索。

为什么向量搜索应该属于已经保存数据的数据库

一旦近似索引使向量搜索变得实用，架构问题就变得显而易见。生产数据已经在 SQL 数据库中。如果向量也存储在那里，技术栈的大部分成本就会消失。

写入变成对单一存储的单一写入，没有管道，也没有需要同步的内容。查询变成单一语言中单一连接上的单一查询，而不是使用图查询语法查询一个系统、使用定制 API 查询向量存储以及手工构建胶水来组合来自每个系统的部分结果。数据始终是最新的，因为只有一个副本。全文搜索可以放在同一个地方。每移除一个管道，也就移除一个故障表面，这在生产环境中的重要性远高于架构图上的表现。

最重要的是，开发人员不再是查询规划者。在多系统栈中，必须有人决定先访问哪个系统、如何组合返回的数据、步骤是否可以并行运行，以及当数据尚未到达某个系统时该怎么办。这就是查询优化，手动执行，没有事务保证。SQL 的设计初衷正是为了消除这类工作：查询请求的是结果，而不是指定如何检索结果，优化器生成执行计划，组合和排序数据，并在事务一致性视图上完成这些操作。

优化器也是数据库中最难构建的组件，这正是会议上用来让观点落地的玩笑：

“如果你在数据库优化器课程中不及格，那就是我们把你送去搞火箭科学的时候。” – Mattias Jonsson，TiDB 首席软件工程师

在四个系统之间手工重建一个更差的版本，是一种倒退，而非架构进步。

TiDB 如何保持行、列、向量和全文存储的一致性

TiDB 的答案是，所有这些访问模式都由一个系统提供服务，并通过一个机制保持一致。行存储是事务性存储，普通索引位于其中，默认通过 Raft 协议进行三副本复制。

解锁其余部分的关键洞察是，Raft 已经携带了每个变更的流。该流可以馈送给额外的存储，每种存储针对不同类型的问题而设计：

列式存储 用于分析，可以快速扫描十亿行中的单个列，并处理没有索引适用的聚合和扫描。
向量索引，它是一个子系统，而非按行的结构，维护自己的近似索引以进行相似性搜索。
全文索引，基于相同的模式构建。

由于它们都由相同的复制流馈送，因此它们都呈现相同数据的一致性视图。而且由于 SQL 层知道哪个存储回答查询的哪一部分，单个查询可以同时利用其中多个存储，而无需应用程序标记引擎或提示存储方式。开发人员编写 SQL，优化器进行路由。

TiDB X 如何将架构迁移到对象存储上

TiDB X 是 TiDB Cloud 背后的架构，它将这些组件重新组织为基于对象存储的服务，以对象存储作为事实来源，具有几乎无限的带宽。查询处理位于其上，行和列引擎将活动数据本地缓存，并将冷数据留在对象存储中。

结构性收益在于，维护工作移出了查询路径。行存储使用日志结构合并树，需要压缩以保持最新并回收空间。以前，这项工作在每个副本内部运行，同时它们还在服务查询。使用对象存储后，这项工作只需运行一次，在仅当任务存在时才存在的节点上运行，并将结果缓存回来。这同样适用于模式变更和统计信息收集：ALTER TABLE 直接读写对象存储，然后将完成的索引交给新查询，执行这些工作的服务仅在操作期间存在。

从上一代迁移到 TiDB X 的客户成本大约降低了一半，同时获得了更好的性能和更低的延迟，并且该架构可以在无任务运行时将计算资源缩放到零。