AI 之下数据库“长事务”会成为主流吗?

多客科技

作者：微信文章
本期播客

AI 之下数据库“长事务”会成为主流吗？


下面这篇文章引起了圈内的激烈讨论, 声音分为两派: AI 推理不会在数据库中功能执行, AI 训练也不会用到数据库. 另一派, AI 应该使用实时数据微调模型参数, 保持模型切片的新鲜度, 提升模型效率和精度.

《不解决这个问题, PG在AI赛道将凉凉!》

其实本质上的问题是: 基于 AI 的应用用到数据库时, 长事务是不是硬需求? 如果是, 那么 PG 就必须引入UNDO存储引擎, 否则将和 AI 赛道擦肩而过!

今天就让我们来辩论一下, “基于 AI 的应用”是否注定导致数据库“长事务”成为主流？
左右互搏 - 辩论主题： “基于 AI 的应用”是否注定导致数据库“长事务”成为主流？

🔥 正方：AI 任务的深度和广度决定了长事务是“新常态”！ (复杂任务驱动派)


各位辩友！我方立场：基于 AI 的应用，必然将数据库的“长事务”推向主流，这是 AI 任务深度和广度决定的技术逻辑！

反方辩友总停留在“查询-修改”的传统思维，完全忽略了 AI 任务的跨域性和长时间性！

第一，训练阶段：长时间数据锁定的刚需！ 请注意，大模型在进行增量训练或灾难性遗忘恢复的微调时，需要从数据库中长时间批量读取大量标注数据。为了保证训练集在整个读取过程中不被外部事务污染或修改，避免数据一致性问题，长时间的读事务甚至独占锁是不可或缺的！这种训练场景下的“数据保护期”，本身就是一种长事务的体现！第二，Agent 任务：复杂决策链的原子性要求！ 当 AI Agent 执行复杂的自动化任务时（例如：一个自动化的财务代理，需要先查询所有未支付账单，然后预估现金流，最后执行批量支付）。这个过程跨越了RAG检索、多步推理、最终写入，耗时数秒！如果用短事务切断，一旦在“执行支付”前，外部系统修改了账单数据，会导致严重的财务错乱！为了保证整个决策链的原子性 (Atomicity) ，长事务是最直接、最可靠的保障方式！第三，RAG 与状态：上下文锁定的必要性！ RAG 检索本身虽然快，但 AI 应用往往需要锁定用户或会话的历史状态（存储在数据库中），然后进行 RAG 检索和推理。这种“锁定状态 -> RAG -> 生成回复 -> 更新状态”的整个交互周期，本质上就是对数据一致性的长时间承诺！长事务不是我们想用，而是AI 决策流程的完整性所迫！

我方认为，AI 任务的复杂性和对数据一致性的高要求，使得长事务成为保障业务正确性、数据完整性的必要技术手段！在性能和正确性之间，AI 应用必须优先保障后者！谢谢！
🛡️ 反方：长事务是性能癌，短事务与解耦才是未来！ (高性能解耦派)


大家好！我方立场：基于 AI 的应用，绝不能让长事务成为主流，短事务与异步解耦才是构建高性能 AI 系统的唯一出路！

正方辩友试图用“原子性”来包装长事务的性能缺陷，这是在倒退！在当前高并发的互联网架构下，长事务就是性能癌！

第一，数据库的并发性是核心资产！ 长事务意味着长时间持有数据库锁！想象一下，一个 AI Agent 花了 10 秒钟进行推理和决策，期间锁住了关键的业务表，导致其他成千上万的用户请求和短事务全部挂起、排队！这种低效的串行化，任何一家追求高并发的公司都无法接受！我们绝不能为了一个 AI 任务的方便，而牺牲整个系统的可用性和用户体验！第二，复杂任务应由应用层而非数据库层保障！ 正方说的复杂链条，完全可以用 “SAGA 模式”、“消息队列” 和 “最终一致性” 来解决！我们将长流程分解为多个独立的短事务，通过消息机制和补偿机制来确保整体业务的成功和失败回滚。例如，Agent 在写入决策前，先用乐观锁检查数据版本，失败就重试！这叫高并发架构，不叫失败！第三，RAG/推理/训练访问应采用只读副本！ 正方提到训练和 RAG 检索的长时间读取。请问，为什么不使用数据库的只读副本（Read Replica） 或专门的数据仓库？让大模型的长时间读取任务在只读副本上执行，这样既能满足其数据一致性要求，又完全不影响主库上高并发的短事务写入！将读写分离、数据分流，才是解决 AI 负载对数据库压力的标准答案！

我方认为，长事务是低效、高风险、不可伸缩的落后技术！AI 的未来在于高性能、高并发！通过短事务、解耦、异步化和读写分离，我们可以构建出既能支持复杂 AI 任务，又不牺牲系统性能的现代数据库架构！谢谢！

你怎么看? 欢迎留言继续讨论