企业官网建设流程全解析

• 后端
• 人工智能
• 机器学习
• RAG
• 向量数据库

PostgresML 提供了一种独特的现代架构：它不再把机器学习能力拆散成独立服务，而是把模型训练、推理与数据统一放进 PostgreSQL 数据库内部，从而用"一个数据库"取代整套"服务化机器学习应用"。本文以官方架构文档为骨架，结合仓库源码，剖析服务化架构的性能短板、PostgresML 的进程模型与 MVCC 优势、大模型共享与 PgCat 连接池原理，并给出可直接落地的 SQL 实战与配置说明，帮助读者理解"模型与数据同处一库"为何能带来性能、易用性与数据完整性三重收益。

服务化架构：机器学习应用的传统形态及其代价

大多数现代应用都以"服务"的形式构建。极端情况下，团队会采用职责单一（single-purpose）的微服务来获得更强的关注点分离。当一个应用需要使用机器学习模型时，典型做法是：

• 由机器学习工程师使用 Python 构建、训练模型，并把模型部署成独立的推理服务；
• 为应用与模型服务之间建立独立的数据同步管道，把数据库里的数据搬运到特征存储或模型侧；
• 应用通过 gRPC、HTTP 等有状态协议之外的网络协议调用推理服务。

整个过程（见下图）意味着：每一条用户请求，都要跨越"应用 → 网络 → 推理服务 → 特征存储/数据库 → 返回"的多跳链路。

服务化架构的三大性能代价

1. 跨团队沟通成本：任何超出单一工程团队职责范围的任务（如机器学习），都需要额外的团队间协作、额外的服务构建与运维负担。
2. 有状态上下文缺失：服务间通信使用 gRPC 或 HTTP 这类无状态协议，处理每个请求时往往还要额外从数据库或缓存中重新获取上下文。
3. 序列化与网络开销：通信发生在网络上，请求与响应必须经历序列化与反序列化，每一次 RPC 都付出额外的时间和资源成本，并引入网络延迟与可靠性问题。

官方架构文档明确指出：服务化架构的扩展特性呈"亚线性"（below-linear scaling），且系统随组件增多而日益脆弱（increasing brittleness），最终会拖垮工程效率与资源利用率。

PostgresML 架构：把模型搬进数据库

PostgresML 的做法是"化繁为简"：将机器学习模型直接移动到数据库中，从而消除对以下组件的需求：

• 独立的特征存储（feature store）；
• 数据同步管道；
• 独立的推理服务；
• 需要序列化/反序列化、网络延迟与可靠性成本的 RPC 调用。

下图展示的 PostgresML 架构中，应用直接与数据库交互，模型推理发生在数据所在之处。

从仓库中的项目组织也能印证这一设计意图：核心扩展位于 pgml-extension，它声明自己是"Machine Learning and AI functions from postgresml.org"的 PostgreSQL 扩展（见 pgml.control），所有能力以 SQL 函数形式暴露给应用，任何能连接数据库的应用都可以直接使用，无需再维护一套外部模型服务。

PostgreSQL 进程模型：天然适合机器学习的基座

PostgresML 是一个 PostgreSQL 数据库扩展，运行在数据库内部，使用同一套硬件执行机器学习任务。要理解它的优势，先要理解 PostgreSQL 本身：

• PostgreSQL 是基于进程的数据库服务器。主进程处理多个连接时通过 fork 出子进程，在操作系统层面实现客户端之间的隔离。
• 主进程分配一块共享内存，并让所有客户端进程直接访问。共享内存用于缓存从磁盘读取的数据，使不同客户端可以为不同查询复用同一份数据。
• 数据访问由轻量级锁与基于事务的多版本并发控制（MVCC）控制。每个客户端在事务持续期间拥有整个数据库的一致视图。

这种"数据共享、进程隔离"的架构对机器学习几乎是最优解：数据读取（昂贵）被共享与缓存，模型加载（相对便宜）被自动化且隔离。同时，MVCC 保证了在数据库内训练模型时的一致性——训练过程中不会有新数据被插入或删除，从而避免训练集漂移。

开源扩展如何承载多租户 ML 负载

PostgresML 的开源扩展采用进程级隔离承载多租户机器学习应用：每个客户端连接加载自己的库与模型、为其提供服务，并在连接关闭时清除所有痕迹。

从源码可以进一步确认这套机制：

• 扩展初始化在_PG_init()中完成（见 pgml-extension/src/lib.rs），它注册服务器参数、激活 Python 虚拟环境（venv）并初始化项目（project）元数据；
• 算法通过统一的Bindingstrait 接入（见 pgml-extension/src/bindings/mod.rs），predict、predict_proba、to_bytes/from_bytes分别承担推理与模型序列化，支持 XGBoost、LightGBM 以及基于 Python 的 sklearn、transformers 等运行时；
• 初始化脚本 sql/schema.sql 在扩展加载时被extension_sql_file!声明（见 pgml-extension/src/lib.rs），数据库对象随扩展一起就绪。

Bindingstrait 的注释还揭示了一个务实细节：PostgresML 不依赖 Serde 序列化，因为 scikit-learn 估计器以 Python pickle 对象序列化，而 xgboost、linfa 的估计器并未完整实现 serde——扩展为此提供了统一的to_bytes/from_bytes契约（见 pgml-extension/src/bindings/mod.rs）。

大模型共享与连接池：让每个客户端共享一份 LLM

大多数经典机器学习模型很小：一个平均大小的 XGBoost 模型可能只有几 MB，每个连接进程轻松加载。但 LLM（如 Mistral、Llama）的体积在几 GB 到数百 GB 之间，大多数机器一次只能负担加载一个实例。

为此，PostgresML 借鉴 PostgreSQL 的思路，使用连接池器共享模型：连接池让成千上万个客户端复用同一个 PostgreSQL 服务器连接，该连接只加载一个 LLM 实例，并以"一次一个事务"的方式服务所有客户端。

如果机器拥有足够的 RAM 与 GPU 显存，也可以加载多个模型实例（允许多个服务器连接），PgCat 会随机路由客户端查询，在所有可用 LLM 实例间均匀负载均衡。

这个连接池器就是 PostgresML 自研的PgCat，它不仅是连接池，还支持负载均衡、分片、故障转移等企业级特性（详见 PgCat 文档）。PgCat 用 Rust + Tokio 实现，能理解 PostgreSQL 线协议，按查询特征做最优路由——例如存在主备库时，把所有SELECT发往副本、其余查询发往主库，实现读写分离；多主分片场景下则解析查询、提取分片键并路由到正确分片（见 PgCat features）。

相关配置项（源码级）

模型加载与推理的线程与安全行为可通过 PostgreSQL GUC 配置，全部在 pgml-extension/src/config.rs 中注册：

其中pgml.omp_num_threads在启动时通过omp_set_num_threads()直接作用于底层 OpenMP 运行时（见 pgml-extension/src/config.rs），因此它必须在数据库启动阶段配置；对应的测试omp_num_threads_cannot_be_set_after_startup（pgml-extension/src/config.rs）也验证了这一点。pgml.huggingface_whitelist的读写行为同样有测试覆盖（pgml-extension/src/config.rs）。

从"为什么"到"怎么做"：在数据库中完成 ML 全流程

架构上的收益最终要落到 SQL 上。PostgresML 以稳定的 SQL API 提供四类核心能力（详见 pgml 扩展文档）：

针对 LLM 与嵌入场景，扩展还提供pgml.embed()（用 Hugging Face sentence transformers 生成嵌入）、pgml.transform()（用 Llama、Mixtral 等 LLM 做文本生成）、pgml.transform_stream()（流式返回部分响应，显著缩短首 token 延迟）与pgml.tune()（基于数据库内数据对 Hugging Face 模型做微调）。

训练脚本的用法可参考仓库内置示例，例如 pgml-extension/examples/regression.sql（回归）、pgml-extension/examples/embedding.sql（嵌入）与 pgml-extension/examples/transformers.sql（LLM），完整列表见 pgml-extension/examples。这些示例与 pgml-extension/tests/test.sql 均以纯 SQL 驱动，直观展示了"训练、部署、推理全在库内"的工作流。

总结：性能、易用性与数据完整性的统一

PostgresML 的架构主张可以概括为一句话：把机器学习从"服务"变成数据库的原生能力。

• 性能：数据无需离开数据库即完成训练与推理，消除网络序列化、RPC 延迟与数据搬运；数据读取由 PostgreSQL 共享内存缓存，模型加载由进程隔离自动管理。
• 易用性：应用只需连接数据库、调用 SQL 函数，无需 ML 工程师单独用 Python 构建和部署推理服务，也无需维护特征存储与同步管道。
• 数据完整性：MVCC 保证训练期间数据视图一致；模型与数据同处事务边界之内，天然避免服务化架构中"数据在别处、模型在另一处"的一致性问题。

对于想在 PostgreSQL 上直接获得 GPU 加速 ML/AI 能力的团队，PostgresML 提供的是一条"以数据库为中心"的替代路径——更少的组件、更低的延迟、更强的数据一致性。若需进一步深入了解其内部工作原理，可继续阅读 PostgresML 架构文档 与 PgCat 连接池 相关章节。

• 后端
• 人工智能
• 机器学习
• RAG
• 向量数据库