北京
数据库工程领域长期围绕一个问题展开：如何在不牺牲作为数据权威来源的系统记录的前提下，扩展 OLTP 负载。谷歌数据库方向的工程副总裁 Amit Ganesh 和 Sailesh Krishnamurthy 在最新发布中，介绍了 AlloyDB 面向智能体时代的新数据库架构，并同步开放了 AlloyDB PostgreSQL for agents 的预览。
过去的几种解法及其取舍
围绕这个问题，业界先后给出过几套方案。Exadata 把查询下推到数据库下方的横向扩展存储层，消除网络瓶颈；Azure SQL Hyperscale 用共享块服务器，扩展到数十个只读副本；Aurora 把日志应用卸载到分布式存储节点，把读扩展到数十个 PostgreSQL 节点。
还有一类新兴架构，把数据持久化在传统对象存储里，前面架一层预置缓存，热数据延迟被拉回来，但每一次缓存未命中都会留下一条高延迟的尾巴。
这些架构各自被三个属性中的至少一个卡住：扩展性、延迟、隔离性，有时甚至同时被两个卡住。比如基于缓存或共享块服务器的架构，I/O 最终会堵在块服务器上，扩展性因此受损；副本流量一冲高，生产负载就被限流，隔离性也一并牺牲。
这些取舍在当年其实是合理的，满足了企业数据库负载四十年的需求。但在智能体时代，这些妥协不再可接受。
智能体负载为什么不一样
智能体负载是动态生成的，无法提前审查，因此把它与关键业务系统隔离开来，成了业务连续性的硬要求。同时，智能体负载需要低延迟，而这种低延迟只有数据库引擎的全部能力加上全部索引才可能实现。
更棘手的是规模。发布中描述了一种此前从未在单一数据库上尝试过的弹性：一群智能体在几秒内要求 1000 个计算节点，并且可能在一分钟内就跑完。
谷歌由此提出，真正的智能体数据库架构必须同时满足三条准则，缺一条就不算数。
- 隔离：按设计隔离，但保留实时数据访问。智能体必须通过一条不与主集群共享数据库组件的数据路径，读取亚秒级新鲜度的生产数据。实时指的是精确到秒，不是陈旧副本或分支。这是物理隔离，不是配额——共享分配意味着共享命运，边界一直延伸到存储层。
- 延迟：亚毫秒级基线 I/O。计算节点用 DRAM 和本地 SSD 加速，但凡是抵达远程存储的缓存未命中，无论来自应用还是智能体，都必须在一毫秒内完成。会退化成数量级性能悬崖的架构，智能体根本用不了。
- 规模：智能体级计算与 I/O。计算节点要能在几秒内拉起、扩展到数千、短时爆发运行、任务完成后自动缩到零。由于智能体的动态特性，预置资源在整个栈上都行不通，无论是计算、存储 I/O，还是中间的任何缓存层。
三条准则必须同时成立。做到这一点，智能体就能直接对着实时运营数据工作，也就是企业的真实数据，而不影响生产稳定性。
AlloyDB 怎么落地这三条
谷歌称 AlloyDB 的新架构是第一个同时满足三条准则的系统，并且是从存储、网络、计算到数据库整体重新设计的。
隔离上，事务型生产集群跑在专用的预置基础设施上，与智能体负载完全隔离。智能体通过 MCP（模型上下文协议）接入一个独立的、临时的微虚拟机 AlloyDB 节点池，这些节点直接读取专用的 Colossus 存储段，与生产所用的存储段分开。
延迟上，每一次存储读取都由谷歌的 Colossus 存储系统直接服务，继承其亚毫秒级基线延迟，从而消除冷缓存未命中时的性能悬崖。
规模上，智能体节点池可以从零快速扩展到数千个节点，应对突发性的智能体活动，并在任务完成的瞬间缩回零。
智能体以亚秒级新鲜度查询生产数据，并可调用完整的 PostgreSQL 引擎能力——点查、索引遍历、向量、全文与空间搜索、列式扫描，以及跨湖仓的联邦查询——来支撑其推理循环。
谷歌表示，开发者可以通过加入 AlloyDB PostgreSQL for agents 的预览，在任意规模上让智能体直接对生产数据运行。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
