ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

为什么选择 PostgresML:用单个数据库替代机器学习服务化架构的架构与实践

为什么选择 PostgresML:用单个数据库替代机器学习服务化架构的架构与实践 后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载PostgresML 提供了一种独特的现代架构它不再把机器学习能力拆散成独立服务而是把模型训练、推理与数据统一放进 PostgreSQL 数据库内部从而用一个数据库取代整套服务化机器学习应用。本文以官方架构文档为骨架结合仓库源码剖析服务化架构的性能短板、PostgresML 的进程模型与 MVCC 优势、大模型共享与 PgCat 连接池原理并给出可直接落地的 SQL 实战与配置说明帮助读者理解模型与数据同处一库为何能带来性能、易用性与数据完整性三重收益。服务化架构机器学习应用的传统形态及其代价大多数现代应用都以服务的形式构建。极端情况下团队会采用职责单一single-purpose的微服务来获得更强的关注点分离。当一个应用需要使用机器学习模型时典型做法是由机器学习工程师使用 Python 构建、训练模型并把模型部署成独立的推理服务为应用与模型服务之间建立独立的数据同步管道把数据库里的数据搬运到特征存储或模型侧应用通过 gRPC、HTTP 等有状态协议之外的网络协议调用推理服务。整个过程见下图意味着每一条用户请求都要跨越应用 → 网络 → 推理服务 → 特征存储/数据库 → 返回的多跳链路。服务化架构的三大性能代价跨团队沟通成本任何超出单一工程团队职责范围的任务如机器学习都需要额外的团队间协作、额外的服务构建与运维负担。有状态上下文缺失服务间通信使用 gRPC 或 HTTP 这类无状态协议处理每个请求时往往还要额外从数据库或缓存中重新获取上下文。序列化与网络开销通信发生在网络上请求与响应必须经历序列化与反序列化每一次 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.rspredict、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.venvstring空Python 虚拟环境路径_PG_init()时会激活该环境pgml.huggingface_whiteliststring空允许从 Hugging Face 下载的模型白名单pgml.huggingface_trust_remote_codebooloff是否允许模型执行远程代码pgml.huggingface_trust_remote_code_whiteliststring空当pgml.huggingface_trust_remote_code on时允许执行远程代码的模型白名单pgml.omp_num_threadsint1OpenMP 底层线程数仅接受正整数且须在启动时设置GucContext::Backend其中pgml.omp_num_threads在启动时通过omp_set_num_threads()直接作用于底层 OpenMP 运行时见 pgml-extension/src/config.rs因此它必须在数据库启动阶段配置对应的测试omp_num_threads_cannot_be_set_after_startuppgml-extension/src/config.rs也验证了这一点。pgml.huggingface_whitelist的读写行为同样有测试覆盖pgml-extension/src/config.rs。从为什么到怎么做在数据库中完成 ML 全流程架构上的收益最终要落到 SQL 上。PostgresML 以稳定的 SQL API 提供四类核心能力详见 pgml 扩展文档函数用途pgml.train()在 PostgreSQL 表或视图上训练回归、分类、聚类模型支持 Scikit-learn 算法以及 XGBoost、LightGBM、CatBoostpgml.predict()使用pgml.train()训练好的模型对线上应用数据做推理pgml.deploy()按自己的精度指标部署pgml.train()训练出的特定模型版本pgml.load_dataset()加载 Scikit-learn 玩具数据集或任意 Hugging Face 数据集针对 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.sqlLLM完整列表见 pgml-extension/examples。这些示例与 pgml-extension/tests/test.sql 均以纯 SQL 驱动直观展示了训练、部署、推理全在库内的工作流。总结性能、易用性与数据完整性的统一PostgresML 的架构主张可以概括为一句话把机器学习从服务变成数据库的原生能力。性能数据无需离开数据库即完成训练与推理消除网络序列化、RPC 延迟与数据搬运数据读取由 PostgreSQL 共享内存缓存模型加载由进程隔离自动管理。易用性应用只需连接数据库、调用 SQL 函数无需 ML 工程师单独用 Python 构建和部署推理服务也无需维护特征存储与同步管道。数据完整性MVCC 保证训练期间数据视图一致模型与数据同处事务边界之内天然避免服务化架构中数据在别处、模型在另一处的一致性问题。对于想在 PostgreSQL 上直接获得 GPU 加速 ML/AI 能力的团队PostgresML 提供的是一条以数据库为中心的替代路径——更少的组件、更低的延迟、更强的数据一致性。若需进一步深入了解其内部工作原理可继续阅读 PostgresML 架构文档 与 PgCat 连接池 相关章节。赞分享后端人工智能机器学习RAG向量数据库【免费下载链接】postgresmlPostgres with GPUs for ML/AI apps.项目地址https://gitcode.com/gh_mirrors/po/postgresml点击查看免费下载相关推荐为什么选择PostgresML数据库内机器学习的8大核心优势解析为什么选择PostgresML数据库内机器学习的8大核心优势解析 PostgresML是一个开源的PostgreSQL扩展它将强大的机器学习能力直接集成到P后端人工智能机器学习RAG向量数据库Flink 物化表 SQL 语句实战指南CREATE / ALTER / DROP MATERIALIZED TABLE 语法详解与实现原理Flink 物化表 SQL 语句实战指南CREATE / ALTER / DROP MATERIALIZED TABLE 语法详解与实现原理 本文围绕 Fli后端人工智能机器学习RAG向量数据库CoreDNS与传统DNS服务器对比为什么现代DNS服务选择插件化架构CoreDNS与传统DNS服务器对比为什么现代DNS服务选择插件化架构 在当今云原生时代DNS作为网络基础设施的核心组件正经历着从传统BIND向现代化解决后端网络云原生上一篇【亲测免费】 探索Docx-Templates新一代Word文档生成工具下一篇Vert.x监控与指标收集构建高性能应用性能监控的完整方案创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表