当前位置：首页 > news >正文

AI时代云原生数据库一体机的思考

news 2025/9/19 6:03:28

本文整理自 IvorySQL 2025 生态大会暨 PostgreSQL 高峰论坛的演讲分享，演讲嘉宾：唐成，中启乘数科技 CTO，资深 PostgreSQL 专家。

引言

AI 技术正从训练转向推理与应用，数据基础设施面临新的挑战。传统数据库难以满足 AI Agent 对实时性、多模态检索和弹性扩展的需求。PostgreSQL 因其扩展性成为 AI 时代的数据基石，云原生数据库一体机通过存算分离和多模融合实现全场景覆盖。本文探讨 AI 时代数据库一体机的演进路径、关键技术及对智能应用的支撑作用。

我们当前的 AI 时代

训练的时代接近尾声，但训练本身的问题依然存在，尤其是在存储层面 HOW225。
Inference（推理）：如何以高效、低成本的方式透出模型能力。
Database for Al Application：db4aia，如何支撑上下文管理、向量检索、数据调用与语义理解等数据层能力。
Agent 数量快速增长，数据底座成核心支撑。
Al Agent 正在大量创建数据库。
Inference（推理）和数据应用正在成为新焦点。
PostgreSQL：新兴数据库的共识基石。

AI 时代的 MCP 技术

MCP 起源于 2024 年 11 月 25 日 Anthropic 发布的文章：Introducing the Model Context Protocol。

MCP （ Model Context Protocol ，模型上下文协议）定义了应用程序和 AI 模型之间交换上下文信息的方式。这使得开发者能够以一致的方式将各种数据源、工具和功能连接到 AI 模型（一个中间协议层），就像 USB-C 让不同设备能够通过相同的接口连接一样。MCP 的目标是创建一个通用标准，使 AI 应用程序的开发和集成变得更加简单和统一。

MCP 的核心组件

模型（ Model ）：LLMs 是这个框架的引擎，负责生成最终的输出。用户可以通过“客户端”（如 Claude 桌面应用、IDE 或聊天机器人）访问模型。
上下文（Context）：这是模型回答问题时所需的额外信息，存储在“服务器”中。服务器可以是 Google Drive、GitHub 仓库、邮箱或 PDF 文件等。
协议（Protocol）：这是一套规则，允许模型访问不同的外部工具和 API，以获取与查询相关的上下文信息。

AI 时代的 RAG 技术

RAG 技术解决大模型的不精确问题，RAG 系统的工作流程可以分为以下几个步骤:

查询（Query）：用户的输入作为 RAG 系统的查询。
检索（Retrieval）：在 LLMs 生成回答之前，RAG 系统会检索与查询相关的知识库，找到最相关的信息。
增强（Augmentation）：将检索到的相关信息与原始查询结合，形成增强后的输入。
生成（Generation）：LLMs 根据增强后的输入生成更准确、更相关的回答，并将结果反馈给用户。

RAG 为 LLMs 提供了更丰富的知识，那么 MCP（Model Context Protocol，模型上下文协议）则赋予了 LLMs 行动的能力。2024 年，Anthropic 推出了 MCP，而在 2025 年，它终于得到了全世界的认可。MCP 允许 LLMs 实时连接外部工具、API 和数据源，这一开放标准让 LLMs 不再局限于文本生成，而是能够执行操作、触发工作流，并获取最新信息以支持决策。

RAG 的系统架构

RAG 架构通过将用户查询与从知识库中检索到的相关信息相结合，再输入大语言模型生成响应，显著提升了输出的准确性和可靠性。

RAG 技术与 MCP 技术的比较

Google Agent To Agent

A2A 是 Google 推出的一个开放通信协议，旨在让 AI 代理(Agent)之间可以互相沟通、协作、派发任务，并同步结果。它解决的核心问题是：“多个智能体如何像一个团队一样配合工作？”想象你是一个项目经理（AI Agent A），你指派另一个人（AI Agent B）去完成任务、实时查看进度、获取结果。

A2A 提供了一整套标准化接口与数据结构，主要包括：

任务发送（Task Initiation）：任何 Agent 都可以通过 tasks/send 或 tasks/sendSubscribe 向另一个 Agent 发出任务请求。
任务状态跟踪（Lifecycle & Streaming）：任务有完整的状态生命周期（如：submitted → working →completed)。若使用 sendSubscribe，Agent 可以订阅 SSE（Server-Sent Events）接收状态更新。
获取结果（Artifacts）：任务完成后，执行方返回一个 artifact 对象，内部是若干 part 组成的内容单元（文本、结构化数据、文件等）。
Agent 能力暴露（AgentCard）：每个 Agent 都需要提供一个标准的能力描述文件 /.well-known/agent.json，用于被发现和访问。其中包含：
- 支持的方法
- 身份验证方式
- 输入输出格式
- streaming/push 支持与否等

A2A 使用总结：

发现对方 Agent（通过 agent.json）。
发起任务（send /sendSubscribe）。
订阅状态流/等待同步返回。
获取结果/交互补充。
完成或失败。

在大模型时代，Agent to Agent 与 MCP 架构正推动 AI 向智能体协同演进。其核心在于 AI 可自主调用外部系统获取实时准确信息，例如查询天气或企业数据时，不再依赖模型自身生成，而是通过语义解析后实时接入专业接口或数据库返回结果。当前这两种架构仍处于竞争与发展阶段，未来每个应用均可能以智能体形态运行，实现更高效可靠的外部系统集成与多智能体协作。

数据库一体机：数据库的超融合

第一代：Exadata 一体机。
第二代：云时代和超融合架构的一体机。
第三代：AI 时代的数据库一体机。

传统时代的数据库一体机

数据库一体机

数据库一体机是一种集成了数据库管理系统、服务器和存储设备于一身的硬件设备。传统上，企业需要单独购买和维护数据库服务器和存储设备，然后安装和配置数据库软件，这个过程非常繁琐。而数据库一体机的出现，将这些组件进行了集成，极大地降低了部署和管理的复杂性。其特点是：

一体化设计。
高性能。
可扩展性。
易用性。
高可用性。

数据库一体机的优势

相比传统的数据库部署方式，数据库一体机具有以下几个明显的优势：

快速部署：数据库一体机提供一键式部署，省去了繁琐的硬件和软件配置过程，缩短了部署周期，快速上线。
高性能：数据库一体机采用专用硬件和优化软件，提供了卓越的性能表现，能够满足大规模数据处理和高并发访问的需求。
成本节省：数据库一体机的一体化设计和集成化管理，减少了硬件设备的购买和维护成本，降低了人力资源的投入。
易于管理：数据库一体机提供统一的管理界面和工具，简化了数据库的配置和管理流程，减少了运维人员的工作负担。
可靠性高：数据库一体机采用冗余设计和自动故障恢复机制，保证了系统的高可用性和数据的安全性，降低了业务中断的风险。

数据库一体机的架构

传统时代一体机的任务：去 IOE

在推进去"IOE"的过程中，国产存储架构实现了从封闭走向开放的重要转型。早期采用数据库一体机来替国产存储通过去"IOE"实现从封闭走向开放。早期用数据库一体机替代小型机和高端存储，突破传统集中存储的性能瓶颈与扩展限制。现在基于国产服务器和 100G 网络的分布式存储，采用 SSD/NVM 介质，实现高性能、弹性扩展和开放兼容，支撑数据库云化，完成从专用到通用的转型。

传统时代一体机的任务：解决性能问题

RDMA：高性能 RDMA 访问协议，高 IO，低 CPU 开销。
ROCE：RDMA 的一种通用实现。
Infiniband：高性能、高带宽、高吞吐、低时延的 IB 底层网络通道。
NVME：高性能闪存 SSD、NVME，高 IO，高效存储。

高性能的存储软件是关键

需要提供跨机器的多副本。
基于 Oracle 的数据库一体机，多副本是依赖于 Oracle ASM 技术。
部分一体机是使用改造的 ceph。
高性能是关键。

实现情况

ceph：基于 tcp/ip 的性能最低。

优点：可以建快照和 clone。
iSCSI：性能低。

优点：非常成熟，对硬件无要求，只要能满足 TCP 网络时，就可以使用此 10 模式。稳定可靠。

缺点：延迟高，在大吞吐下消耗 CPU 高。
iSER：性能中等。

优点：非常成熟，延迟相对低。

缺点：要求 RDMA 网络可以使用 RoCE 或 infiniband。性能达不到极致。
NVME OF Fabric：性能高，延迟低。
SPDK：性能高，延迟极低。对 CPU 核的完全占用。

云时代的数据库一体机

云时代一体机的任务：提高资源利用率

在云时代，存储架构的核心任务从解决性能问题转向提升资源利用率。存储架构的核心任务从提升性能转向提高资源利用率。早期通过数据库一体机实现去 IOE，替代了传统烟囱式架构的小型机和高端存储。如今采用分布式存储和资源池化技术，打破了资源隔离，实现了弹性扩展和高资源利用率，支持数据库云化，完成从烟囱式架构到资源池的战略转型。

云时代一体机：需要增加云管平台

过去要实现数据库高隔离，得靠物理机、虚拟机，或在数据库里做受限于自身的多租户。但现在云时代，资源池化能按负载选隔离模式，多租户也能在高效用资源时保障数据隔离，轻松平衡隔离性与资源效率。

资源池化：根据负载支持 3 种隔离模式。
弹性资源：动态扩展应对潮汐系统请求。
多租户：资源最大化同时保证数据隔离。
多数据库支持：支持多个数据库集中管理。
性能水平扩展：数据库读写能力的水平扩展。
统一运维：统一规范、简化运维。

云时代的技术

这个时代的数据库一体机就是一朵云：

计算虚拟化：数据库跑在虚拟机中。
存储虚拟机：更灵活的存储。如对象存储。
网络虚拟化：虚拟网络。

狭义的云原生定义

云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。
Cloud 表示应用程序位于云中，而不是传统的数据中心；Native 表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
Native 表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
云元素的四要素：微服务、容器化、DevOps、持续交付。

云时代的数据仓库

云时代数据仓库正向 HTAP 架构演进，实现数仓与分析业务融合。关键技术包括：

基于对象存储的存算分离技术。
更高效的 CDC。
流式实时计算和批计算融合。

云时代催生了云原生数据库

云时代催生了云原生数据库的快速发展，其中 serverless 技术成为公有云平台的典型特征。与传统扩容需要阶梯式增加节点不同，serverless 实现了资源的平滑弹性扩缩，这是云时代给数据库架构带来的重要变革。结合容器技术，云原生数据库实现了真正的弹性能力，彻底改变了传统数据库的运维模式。

AI 时代的数据库一体机

AlloyDB For PostgreSQL

AI Agent 正在大量创建数据库：需要云模式的一体机。
Agent 数量快速增长，数据底座成为核心支撑：需要一体机。
这一场景要求数据库支持多模查询。

AI 时代对数据库查询的变化

AI workflow 从数据库、应用日志、埋点系统、摄像头、视频等来源收集数据；传统数据通过清洗与转换进行加工进入数据库；对于图片、视频、语音的数据经过向量化处理进入向量数据库。加工后的数据然后由数据工程师或算法专家进行探索与分析，做出参数调整等关键决策。当这些数据准备充分后，结合大模型的能力，便可实现下一阶段的重要能力。

Multi-Modal Retrieval 的核心含义是：在数据检索过程中，不再局限于某一种查询方式，而是融合结构化、半结构化、非结构化以及向量检索等多种方式，实现更智能、更全面的查询体验。这项能力对于 AI 应用尤其重要。因为 Agent 面对的问题往往不是“查一条信息或者一个向量"，而是需要对多个模态、多维数据进行理解、关联和调用–这就需要底层数据库具备原生的多模处理能力。

以“亚运会智能巡逻检查"为例，我们需要在监控系统中检索指定的巡逻车或人在城市的范围内进行巡逻，最基础的方式可能仅涉及向量检索——比如通过图片或视频帧进行巡逻车和人的相似度匹配，以获得巡逻的数据，仅获得巡逻数据还是不行的，我们还需要检索结构化的数据库中的数据，进行智能比对，以便于我们分析巡逻的覆盖面以及巡逻的弱点，以及如何做好优化。同时可能还会结合舆情，进行调整。

AI 多模式查询的挑战

多模态检索对架构提出了更高要求，实现 Multi-Modal Retrieval 意味着系统必须同时处理结构化数据、半结构化数据(如 JSON)、向量数据，将多种模态数据统一存储与检索，消除系统间的分割，让多模态查询变得自然、实时且可扩展。

数据库一体机的方向

AI 技术正在重塑应用架构，大语言模型的出现颠覆了传统范式。这种变革进一步传导至数据库层面，推动着面向 AI 时代的云数据库一体机的演进。未来所有应用将主要对接两个核心接口：Data API 和 AI API。

为适应这一趋势，云数据库一体机需具备以下特性：

灵活性、可扩展性和弹性。
资源池化。
快速弹性伸缩。
按需自助服务。
广泛的网络访问。
可度量的服务。

AI 时代不会淘汰高级程序员和高级 DBA

AI 时代的到来并不会淘汰高级程序员和高级 DBA。正如 PC 时代 VB、Delphi、MFC 等可视化开发工具的出现没有取代程序员一样，当前虽然出现了大量调参工程师、Call API 专家、用库包能手和拼组件达人，但技术人员很快会在新领域找到发展空间。

互联网时代的兴起催生了后端开发、网络、分布式、数据库、海量服务、容灾防错等新方向。PC 时代的基础设施是控件库，互联网时代的基础设施是云，AI 时代也将诞生新的基础设施概念。

时代发展会催生新的技术概念（量变积累成质变），但底层逻辑始终不变。坚持第一性原理，保持高内聚、低耦合的设计理念，才是技术人员的核心竞争力。

需要理解的背后原因

本地部署的传统应用往往采用 c/c++、企业级 java 编写，而云原生应用则需要用以网络为中心的 go、node.js 等新兴语言编写。
本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。
本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。
本地部署的传统应用对网络资源，比如 ip、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。
本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。
本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。
本地部署的传统应用有些是单体（巨石）应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。

AI 时代 PostgreSQL 成为新宠

为什么 PostgreSQL 会成为事实上的行业标准?

PostgreSQL 非常标准和规范，除了 SQL 本身就覆盖了 OLTP 和 OLAP 的需求外，其最大的优点就是有强大的可扩展性。它允许用户通过扩展（Extensions）来增强数据库功能（全文检索，向量检索，地理信息检索，时序处理等等），而无需修改核心代码。
PostgreSQL 提供了原生的 pgvector 扩展，可以直接支持向量数据的存储与检索；而在 MySQL 标准中，缺乏可扩展性接口与生态，MySQL 数据库系统往往需要自行定义向量数据存储和检索的 API，导致实现千差万别，缺乏标准。这也是为什么越来越多的 AI 公司，特别是 OpenAl、Anthropic、Notion 等大型 AI 初创项目，都选择 PostgreSQL 作为其核心数据引擎。
非官方的一则报道：OpenAI 内部的一个 PostgreSQL 只读从库就部署了近 50 个实例。虽然目前 OpenAI 尚未采用分布式数据库架构，但随着业务规模的持续扩张，这或将成为其未来必须应对的架构挑战。

PostgreSQL 成 AI 智能体首选数据平台

AlloyDB for PostgreSQL：在 Google I/O 上，谷歌发布了 AlloyDB for PostgreSQL，这是一个完全托管的、与 PostgreSQL 兼容的数据库，用于要求苛刻的企业级事务和分析工作负载。弹性存储和计算、智能缓存和 AI/ML 支持的管理。
Agent Talk to MCP：PostgreSQL 是默认选项之一。
MCP 这个概念最早由 Anthropic 提出，而在其官方文档中，明确列出的第二个支持平台就是 PostgreSQL。
这进一步印证了 PostgreSQL 在 AI 应用工作负载中的关键作用——它不仅是一种数据库，更是 AI 系统与数据交互的中枢平台。

多模态数据库：AI 时代的核心基础设施

未来 AI 应用层将越来越依赖数据库，多模态数据库将成为核心基础设施。

这里举个例子:

如果你正在开发一个基于 AI 的 Agent，它势必需要与各种数据系统和应用系统交互。按照传统架构的分工模式：

事务性数据放在关系型数据库中。
数据的横向水平分布式扩展用 MongoDB 或 HBase。
搜索功能用 Elasticsearch（ES）实现。
分析需求用 ClickHouse。

这意味着，一个企业仅在数据底层就要维护至少 4 个不同的 MCP（Model Context Protocol）服务。这对大模型来说是个巨大的挑战。理论上它可以理解这些差异化的服务，但实际运作中非常复杂，对其“智力”构成高强度负荷。能对接 1 个 MCP，谁还要对接 4 个呢?这也正是为什么越来越多的 AI 初创公司选择 PostgreSQL，而未来大型企业在面向 AI 场景进行数据库选型时，也一定会倾向选择支持多模态的数据库平台。

基于 PostgreSQL 的热点数据库

IvorySQL 数据库是一款基于 PostgreSQL 数据库。
Neon Database 由 PostgreSQL 核心开发者创立，提供基于 PostgreSQL 的 Serverless 云服务。其采用存算分离架构，支持类似 Git 的 Branc 和 Time Travel 功能，允许开发者在独立数据库分支上并行开发。架构模式与 Google AlloyDB、Azure Socrates 及华为 Taurus 类似，均为计算节点、存储服务和日志服务分离的云原生方案。该公司于 2022 年获得 3000 万美元 A 轮融资。

AlloyDB for PostgreSQL 在 Google I/O 上，谷歌发布了 AlloyDB for PostgreSQL，这是一个完全托管的、与 PostgreSQL 兼容的数据库，用于要求苛刻的企业级事务和分析工作负载。弹性存储和计算、智能缓存和 AI/ML 支持的管理。
Supabase 同样是构建在 PostgreSQL 之上的数据库平台，它与 Neon 构成了直接的竞争关系。但与 Neon 相比，Supabase 提供了更为丰富的功能集，包括身份验证、对象存储、实时订阅、边缘函数等服务，几乎可以看作是“开源版的 Firebase”，定位为开发者的一站式后端服务平台。

AI 时代对数据库一体机的挑战

AI 时代传统数据架构的痛点

Legacy Data Architecture(传统数据架构)。它已经难以适配 AI 时代日益增长的实时性、统一性和智能化需求。

事务型数据库：用于实时写入与查询（如订单、行为日志）。
文本搜索引擎：处理非结构化关键词匹配（如全文搜索）。
向量搜索引擎：支撑语义检索。
分析引擎：进行数据分析（如行情分析、指标监控、报表）。

痛点问题：

系统运维复杂：需管理多个技术栈，版本依赖、部署、运维压力大。
数据割裂严重：数据需在多个系统间反复同步、复制，口径难统一。
性能和响应链路长：查询需跨系统拼接，影响响应时间和稳定性。

统一多模数据架构

通过统一架构，将多模态数据能力深度集成于单一平台，以更简洁高效的方式支撑复杂 AI Workflow。该架构并非多个引擎的简单拼装，而是从底层实现事务处理、全文搜索、向量检索与实时分析的有机融合，真正实现“一套系统，全场景覆盖”。

具体能力包括：

支持行存表、列存表及行列混存表，适应不同业务场景的存储与访问需求。
提供 OLTP 全局二级索引：倒排索引满足文本搜索、列存索引优化分析查询、JSON 索引提升半结构化数据的访问效率。

构建统一数据底座

只有构建一个满足实时性、融合性、高并发与易用性的数据平台，才能真正释放大模型和 Agent 的智能潜力。

数据库：擅长处理 Fresh Data（数据新鲜性）和 Instant Retrieval（即时检索），适用于实时写入和快速查询场景。但其大多基于单机或简单主从架构，难以支撑大规模的高并发访问。
数据仓库（如 ClickHouse）：在分析性能（Fast Analytics）和使用简洁性（Simplicity）方面表现出色，但它们普遍不适合高频写入或低延迟响应场景。
数据库一体机：将 Data Warehouse 与 Database 融合于一体，构建统一的数据底座，以全面支撑 AI 工作流中从数据采集、加工、分析到检索的全过程。

构建支持 AI 应用的云原生数据库一体机

拥有云能力的数据库一体机有效支持了 AI 应用。在可观测性场景中，弹性能力至关重要：系统正常运行或行情平稳时可能仅需支持少量用户；一旦出现系统问题或金融行情波动，用户量会急剧增加，容易导致系统崩溃。因此，云上的弹性扩缩容能力成为关键支撑。

采用领先的存算分离架构的 Data Warebase 能够在业务无感的情况下实现秒级弹性扩缩容，满足瞬时高并发需求。同时，该架构具备多模能力与精简架构（Simplicity），兼顾了可观测性场景所需的简洁性和实时决策（Instant Decision）能力。

在金融领域的 Trading 、Fraud Detection 、车联网领域的信号收集、检测与报警，以及 Ads、Search 和 Recommendation 等场景中，均需要此类能够提供即时决策支持的一体化数据平台。

AI 时代的工作流技术

AI 工作流，从数据获取到结果交付，必须满足五大核心能力:

CData 是 AI 时代的数据库

相比传统的数据库部署方式，数据库一体机具有以下几个明显的优势:

部署方式：支持在物理机上、虚拟机上、容器中部署数据库。在同一个物理机或虚拟机中还可以部署多个数据库实例（使用 cgroup 做资源隔离）。
高性能：CData 支持 iSER、NVMe over Fabric、SPDK 等多种 IO 传输模式，提供了卓越的性能表现，能够满足大规模数据处理和高并发访问的需求。
成本节省：支持云化部署，支持基于共享存储和数据库自身主库方式的高可用方案。支持负载均衡。支持完善的监控和告警功能。
多模查询：可以运行支持多模查询的数据库 PostgreSQL 或 HighgoDB，配合 pgvector 可以提供向量查询，本身可以提供全文检索、JSON 搜索等文本搜索。
可靠性高：CData 支持跨机器的 Raid1、Raid10、Raid5、Raid6、Raid50、Raid60 等冗余设计，保证数据的可靠性。

总结

AI 时代的数据库一体机已从性能优化工具发展为智能应用的核心基础设施。云原生架构、多模态检索和弹性扩展技术解决了数据割裂、运维复杂和响应延迟等问题。PostgreSQL 生态、MCP 协议和 Agent 协作框架进一步强化了数据库作为 AI 与数据交互中枢的角色。随着多模查询、实时决策和资源池化技术的成熟，数据库一体机将持续支撑大模型与 Agent 的智能应用。

查看全文

http://www.dtcms.com/a/389086.html