数据库即产品：AI记忆设备规模化时什么会崩

编者注：本文最初发表于 The New Stack，经许可转载。原始版本可在此处查看此处。

关键要点

• 将元数据（MySQL）与内容（S3）分离且没有共享事务边界，会把一致性问题推入应用层。
• 在约 3 亿行数据量时，模式变更需要维护窗口，让数据库决定了发布节奏。
• 在 AI 记忆产品中，每一次交互都是一次数据库操作，因此架构债务会变成产品故障。
• 将其元数据层迁移到 TiDB 后，Plaud 获得了在线 DDL、约 10 倍的 QPS 余量，以及低于 10 毫秒的 P95 延迟。

想象一下，你刚结束一场两小时的会议。你身上戴着一个小的 AI 工作伴侣，它承诺会捕捉对话、将其结构化，并让你之后可以就它提问。会议结束两小时后，你打开应用，请求获取文字记录。你等待着。加载图标转个不停。你购买这个设备的全部理由，就是再也不用记住一场会议，而现在它承诺要做好的唯一一件事——回忆说过的话——却正是让你等待的原因。

这就是让我对 AI 硬件产品着迷的故障模式，因为这不是模型问题。转录很完美。摘要也很好。真正磨损的，是没人会宣传的那部分：在用户请求的那一刻，把正确的字节从磁盘取出并显示到屏幕上。这是一个数据问题。而对于一个全部承诺就是记忆的产品来说，数据问题就是产品问题。

我想详细讲一个真实的版本，因为遇到这个问题的团队 Plaud 制造了市场上最受欢迎的 AI 笔记工具，而坏掉的架构几乎是这个类别中每个团队起步时都会采用的架构。它在发布时看起来很合理。它在规模化时变成负担。而其中的原因，值得你在发布之前而不是之后去理解。

首先，哪些部分最初构建是正确的

把这件事讲成“他们犯了一个错误”会很容易。他们没有。最初的架构是一组明智的决策，在我剖析出错在哪里之前，我想把这一点讲清楚，因为教训在于“合理”与“规模化时正确”之间的差距，而不在于任何人的能力。

Plaud 的产品每次录音都会生成两种截然不同的数据。有结构化元数据：谁录制的、什么时候、多长时间、哪些标签、处理流水线处于什么状态。还有非结构化负载：音频文件及其文字记录，每次会话可能达到数十兆字节。团队做了教科书式的事情。他们把结构化元数据放在 MySQL 中，因为关系查询和事务在那里成本很低；他们把大对象放在 S3 中，因为那里的存储便宜且实际上无限。

如果你构建过系统，你就做过完全相同的选择。用对象存储放 blob，用关系数据库放所有需要查询的内容。它出现在每一张架构图里。它是默认选择。而且在产品生命周期的很长一段时间里，它运行得很好。

问题不在于这个决策是错的。问题在于它包含了一个隐藏假设：元数据和内容可以存在于不同系统中，因为它们永远不需要彼此实时保持一致。对大多数应用来说，这个假设成立。对于一个核心交互是“现在就把我录下的东西原样还给我”的产品来说，它不成立。而这两个世界之间的差距，正是一切开始失败的地方。

文字记录边车

在我关于RAG 检索的文章中，我指出了一种反模式，我称之为向量边车：习惯性地在主存储旁边再立一个独立的向量数据库，结果却发现这两个系统无法共同回答一个查询。Plaud 的架构具有相同的形态，只是应用在 AI 硬件产品上。可以称之为文字记录边车。

文字记录边车就是当你把结构化元数据与非结构化内容拆分到两个没有共享事务保证的系统时所得到的东西。元数据说某条录音存在、完整且已就绪。内容存在别处，需要通过一次单独调用才能到达，并有其自己的延迟和故障模式。没有任何东西把两者绑定在一起。没有一个事务边界能跨越“表明这条文字记录已就绪的那一行”和“包含这条文字记录的那个对象”。

这会产生三个不同的、相互叠加的问题。

• 检索延迟不是网络问题；它是数据局部性问题。S3 是出色的对象存储。它不是数据库。当你让对象存储在并发负载下成为数十兆字节负载的主要检索路径时，你是在用数据库的一致性和延迟保证，换取 blob 存储的简单性。在轻负载下，这种交换是看不见的。在重并发负载下，S3 的检索延迟及其波动性就变成了用户对你产品的体验。
• 一致性缺口会在两个独立失败的系统之间打开。MySQL 中的行可能会在 S3 对象可持久访问之前的一刻就表明某条录音已就绪，或者副本可能滞后，导致用户看到的元数据与他们获取的内容不一致。没有共享事务，应用层就继承了掩盖这个缺口的任务，需要重试、轮询和协调逻辑，而这些每季度都会变得更复杂。
• 模式会在最糟糕的时刻变得不可移动。更多内容见下文，但简短版本是：元数据存储撞上了规模上限，在那里更改模式需要维护窗口。对于一个仍在演进功能集的产品来说，这等于数据库在支配路线图，而不是反过来。

统一的洞见就是我在整个系列中反复回到的那一点：每当你把数据拆分到可能独立失败的系统之间时，你就把一致性问题交给了应用层；在那里，问题与其说是被解决，不如说是被管理，而且会随着时间不断叠加。

当数据库支配路线图时

Plaud 故事中最令人玩味的失败点不是延迟，而是 schema 冻结，因为这是团队最意想不到、感受却最强烈的问题。

在约 3 亿行数据的情况下，团队的 MySQL 设置已经发展到这样的地步：诸如添加列或更改索引这类 schema 变更——任何成长中产品的常规演进——再也无法在不冒风险的情况下在线执行。在如此庞大的表上、在那样的架构下执行 DDL 操作，意味着锁表、复制压力，以及停机的真实可能性。因此变更不得不被批量安排进维护窗口。

仔细想想这意味着什么。为 schema 变更安排的维护窗口，就是数据库允许产品团队发布的时间。路线图如今要围绕数据库的局限来弯折。需要新列的功能要等到下一个窗口。产品的节奏由数据层的运维脆弱性所决定。大多数团队不会注意到这种倒置，因为它发生得渐进，然后某一天产品经理问为什么一个小改动要花两周，答案是“数据库”。

3 亿行的天花板是一种强迫函数，团队撞上它的时间比他们预期的要晚，而本应比他们实际撞上的时间更晚。说“预期”，是因为单实例 MySQL 在它不再感觉无限之前，一直感觉无限。说“本应”，是因为把你带到 3 亿行的架构，很少是能带你越过 3 亿行的架构，而且在 3 亿行时做迁移，比在 3000 万行时破坏性大得多。天花板是真实存在的；它是可预测的，而大多数团队只有在撞上它之后才为它做规划。

更改架构实际修复了什么

Plaud 的解决方案是将元数据层整合进一个分布式 SQL 数据库（他们迁移到了 TiDB），这消除了单实例天花板，并恢复了在线 schema 变更。我将使用他们的数字，但不是作为产品宣传。我要把它们作为证据，来支撑一个关于这类产品中架构债务去向的论断。

数字依据 Plaud 所报告的迁移结果。

QPS 余量和尾延迟很重要，但我首先要指出的是在线 DDL。恢复在不需维护窗口的情况下更改 schema 的能力，正是把路线图交还给产品团队的关键。数据库不再支配发布节奏。这不是能放进基准图表里的性能胜利，但它是产品组织每周都能感受到的那一个。

还要注意这个修复没有做什么：它没有试图把 30 兆字节的音频文件存进数据库。大型对象仍然可以存储在对象存储中。重点从来不是“为了单一系统本身而把所有东西都放进一个系统”。重点是元数据层——那个必须实时保持一致、可查询、可演进的部分——需要真正像一个大规模数据库那样运作，而不是成为分裂大脑架构中脆弱的那一半。

架构债务去了哪里

这就是 Plaud 的数据所支撑的论断。当数据库就是产品时，架构债务不会积累在某个只有平台团队感受得到的中后台系统里。它积累在产品体验中，每个用户都能感受到。

这就是 AI 笔记工具与比如说内部数据分析工具之间的结构性差异。对于这样的产品，每一次有意义的用户交互都是一次数据库操作。录制会创建行和对象。转写会更新状态。检索是一次读。编辑是一次写。搜索是一次查询。产品的任何部分，底下都是数据库在做某件事。架构问题会一对一地浮现为产品问题。一致性缺口会变成短暂缺失的转录文本。缓慢的检索读起来就是一个记东西很慢的产品。冻结的 schema 意味着功能迟到。

没有用户会提交这样的错误报告：“你的元数据存储和对象存储缺少共享事务边界。”如果不加以解决，这类债务会表现为：产品恰恰在有人依赖它的时候感觉不那么可靠。对于一个全部价值主张就是“相信我会记住”的产品，这种债务落在承诺本身上。这就是为什么 Plaud 在其所处时机决定重构架构很重要。团队在失败变得对用户可见之前修复了数据层。

这就是为什么我说数据库就是产品。不是作为口号。而是作为对产品质量在何处被决定的一种字面描述。你可以拥有同类中最好的转写模型，却仍然交付一个感觉不可靠的产品，因为这类产品的可靠性是一种数据架构属性，而不是模型属性。

陷阱在于等待整个品类

AI 硬件正逢其时。笔记工具、可穿戴设备、环境录音器、吊坠、徽章——每一个都建立在这样的前提上：设备会记住，所以你不用记。这个品类正在增长，产品在大家都在谈论的部分上越做越好：模型、外形、电池续航。

但在底层，几乎所有这些产品都从 Plaud 起步时相同的架构开始，因为那是合理的默认选择。结构化元数据放在单实例关系型数据库中。大型内容放在对象存储中。没有共享事务边界。一个在 1000 万行时容易更改、在 3 亿行时冻结的 schema。陷阱一模一样，而且它在这个品类每个团队的增长曲线上同一个位置等着他们。

能够做得出色的团队，是那些很早就认识到这一点、明白对于一个记忆产品而言，元数据层不是后台管道，而是用户体验的脊梁，并按照他们想要达到的规模而非当前所处的规模来规划数据架构的团队。Plaud 的迁移是值得在你达到 3 亿行之前研究的模式，而不是在之后。从别人的 3 亿行中学习这一课，比从你自己的 3 亿行中学习代价更低。

当你的数据库和你的产品是同一回事时，你就不能把数据库当作别人的问题来对待。它就是产品。像打造产品一样打造它。

Plaud 触达了 3 亿行的天花板，并在用户有所感知之前就重新架构了其元数据层。想了解该团队如何规划和执行那次迁移，请阅读完整的 Plaud 案例研究。

文章 数据库即产品：当记忆设备扩展时什么会崩塌 首次发表于 TiDB。