xiaohack's Blog - PostgreSQL
type: channel
link: https://blog.xiaohack.org/tag/PostgreSQL/
items: 我花了一天时间，拆了一下 OpenTeleDB 的 XStore，到底解决了 PG 的哪根老筋？
items: 教程：构建基于 Coreflux MQTT 与托管数据库的IoT数据管道
items: 基于分层协作多智能体的数据库参数调优——OceanBase 校企研究
items: 【文档悬赏令】第2号：数据库巡检手册征集，上传文档赢好礼！
items: 内存一年疯涨 170%，云账单里的“隐性成本”该算清了
items: SQLShift V6.0 发布！函数迁移&达梦适配一步到位！
items: PHP 网站重构， Rust/ Python + PostgreSQL + astro+solid，大家觉得怎么样子
items: 奥特曼小号泄密：OpenAI 代码工作 100% 交给 Codex！工程师才揭底 Codex“大脑”运行逻辑，碾压 Claude 架构？
items: Spring Boot 3 集成 Apache Calcite：多数据源查询的终极解决方案
items: 拥抱 PostgreSQL 支持 UI 配置化

我花了一天时间，拆了一下 OpenTeleDB 的 XStore，到底解决了 PG 的哪根老筋？
type: item
date: 2026-02-04T20:09:36+08:00
description: 这两年数据库圈有点像3年前的云原生圈："分布式"、"新一代内核"、"重构存储引擎"这些词突然又密集起来了。前几天刷群，看到有人转了 OpenTeleDB 的开源消息，说是"基于 PostgreSQL 的新一代内核"。说实话，我第一反应是：又一个魔改 PG？但看到里面提到一个点：原位更新 + Undo 引擎（XStore），我还是没忍住下了源码。 因为这恰好戳中我这些年被 PG 折磨得最狠的痛点：表膨胀、autovacuum 抽风、性能像心电图一样忽高忽低。所以这次我没看 PPT，也没看宣传稿，直接跑到机器上拆了半天，想看看它究竟动了 PG 的哪根"老筋"。一、先说结论：XStore 不是快，而是"稳"我装的是 OpenTeleDB 的 17.6 内核版。 创建方式很直观：SELECT relname, amname FROM pg_class c JOIN pg_am a ON c.relam = a.oid WHERE relname = 'test_xstore';这一步其实就已经很有意思了------它不是 fork 了一套新引擎，而是作为插件挂进去的。 这个思路我很认可：不绑死 PG 版本能跟着大版本升级出问题可以随时回退像 Citus、openHalo 这些"成功插件化路线"的项目，本质都是这个思路。二、打开数据目录，我第一次意识到：它真不是换皮在 $PGDATA 下面，多了一个非常显眼的目录：drwx------ 2 postgres postgres 4096 Nov 3 20:15 undo这就是 XStore 的核心： 它不是靠多版本链来维护 MVCC，而是靠 Undo 日志回滚。这点和 Oracle、MySQL InnoDB 的逻辑更像。也正是它敢说"原位更新"的底气来源。三、插入测试：它不快，但很"诚实"我用同样的参数，在同一台机器上跑了两组：INSERT INTO test_xstore (name, value) SELECT md5(random()::text), (random()*1000)::int FROM generate_series(1,10000000);INSERT INTO test_heap (name, value) SELECT md5(random()::text), (random()*1000)::int FROM generate_series(1,10000000);结果是：写慢了将近一倍。这点我反而觉得真实：因为 XStore 在写数据页的同时，还要写一份 Undo。物理写入翻倍，吞吐下降是必然的。如果一个系统告诉你"原位更新 + Undo 还更快"，那我反而会不太信。四、创新实验：模拟1千万数据的存储膨胀对比我设计了一项创新实验：在 1000 万条级别的大数据量下，评估 XStore 与 Heap 表在高频更新下的空间膨胀、索引稳定性以及查询性能表现。该实验主要有两个创新点：大规模数据模拟使用 generate_series(1,10000000) 生成 1000 万条数据，保证数据量级对存储膨胀影响明显。初始数据包括 id、name、value 和 updated_at 四列，与前期实验一致，但数据量增加十倍，以模拟真实大规模 OLTP 系统负载。多维度空间分析不仅监控表总大小，还分别统计索引占用和 TOAST 表空间。每轮更新后，通过 pg_relation_size、pg_total_relation_size 和 pg_indexes_size 获取精细化指标。引入 可视化趋势分析，绘制表空间增长曲线，以直观展示 XStore 与 Heap 的差异。4.1 实验设计表结构CREATE TABLE xstore_large ( id SERIAL PRIMARY KEY, name TEXT, value INT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) USING XSTORE; CREATE TABLE heap_large ( id SERIAL PRIMARY KEY, name TEXT, value INT, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );初始化 1000 万条数据INSERT INTO xstore_large (name, value) SELECT 'name_' || g, g FROM generate_series(1, 10000000) AS g; INSERT INTO heap_large (name, value) SELECT 'name_' || g, g FROM generate_ser…

教程：构建基于 Coreflux MQTT 与托管数据库的IoT数据管道
type: item
date: 2026-02-03T16:06:19+08:00
description: 使用托管数据库部署 Coreflux MQTT 代理MQTT 代理 通过发布-订阅消息模式连接物联网设备和应用程序，使其成为现代 物联网 基础设施的重要组成部分。Coreflux 是一个 低代码 MQTT 代理，增加了实时数据处理和转换功能，让你可以直接与 DigitalOcean 托管数据库（包括 MongoDB、PostgreSQL、MySQL 和 OpenSearch）集成，而无需编写自定义集成代码。你将学到什么： 本教程将引导你部署一个完整的物联网数据管道——从在 DigitalOcean 上设置托管数据库集群和 Coreflux MQTT 代理，到配置安全的 VPC 网络、使用 Coreflux 的物联网语言 (LoT) 构建数据转换模型，以及自动将处理后的物联网数据存储到你选择的数据库中。最终你将获得一个可用于生产环境的设置，能够处理物联网应用的实时消息传递和持久存储。关键要点在深入了解分步部署过程之前，以下是你将学到的关键点：在 DigitalOcean 上部署托管数据库集群（PostgreSQL、MongoDB、MySQL 或 OpenSearch），用于可扩展的物联网数据存储。使用 Marketplace 镜像或 Docker 在 DigitalOcean Droplet （DigitalOcean的VPC）上设置 Coreflux MQTT 代理。创建安全的 VPC 网络以连接你的 MQTT 代理和数据库，无需公开暴露。使用 Coreflux 的物联网语言 (LoT) 构建实时数据管道，实现低代码物联网自动化。自动转换和存储物联网数据，从 MQTT 主题到数据库表、集合或索引。验证端到端数据流，从模拟传感器通过转换模型到数据库存储。本教程为需要实时消息传递结合持久数据存储以及搜索、分析或关系查询等高级功能的物联网应用提供了一个可用于生产环境的基础。你将构建什么在本教程结束时，你将得到：一个用于可扩展存储的托管数据库集群（PostgreSQL、MongoDB、MySQL 或 OpenSearch）一台运行 Coreflux MQTT 代理的 DigitalOcean Droplet一个用于安全 物联网通信的虚拟私有云 (VPC) 网络使用 LoT Notebook 扩展进行的实时数据模拟低代码数据转换模型和数据库集成路由用于 物联网自动化 的完整 数据集成与转换 管道Coreflux 与 DigitalOcean 合作Coreflux 通过物联网语言编程语言在 DigitalOcean 云平台上提供轻量级 MQTT 代理和数据管道工具，以实现高效的物联网通信。什么是 MQTT？MQTT（消息队列遥测传输）是一种轻量级的、发布-订阅网络协议，在物联网生态系统中被广泛采用。专为受限设备和低带宽、高延迟或不稳定的网络设计，MQTT 能够在带宽受限的环境中实现高效、实时的消息传递。关于 CorefluxCoreflux 提供了一个轻量级 MQTT 代理，以促进物联网设备与应用程序之间的高效、实时通信，包括每个用例所必需的实时数据转换功能。为可扩展性和可靠性而构建，Coreflux 专为低延迟和高吞吐量至关重要的环境量身定制。无论你是构建一个小型物联网项目还是部署工业监控系统，Coreflux 都能处理设备之间的消息路由和数据流。在 DigitalOcean 云平台上使用 Coreflux，你将获得：数据处理： 在你的数据所在之处集中处理你的数据处理需求，确保实时数据处理。数据集成： 轻松与其他 DigitalOcean 服务（如托管数据库 PostgreSQL、MongoDB、MySQL 或 OpenSearch）集成，确保为你的所有数据需求提供一个单一且简单的生态系统。可扩展性： 轻松处理不断增长的数据和设备数量，而不会影响性能。可靠性： 确保在所有连接的设备之间进行一致且可靠的消息传递。准备工作在开始本 MQTT 代理 部署教程之前，你需要：一个 DigitalOcean 帐户，可在DigitalOcean.com注册，支持绑定信用卡、支付宝或数字货币了解 MQTT 协议概念和 物联网 架构Visual Studio Code（用于 LoT Notebook 扩展）预计时间： 本教程大约需要 30-45 分钟完成，具体取决于数据库配置时间（通常每个数据库集群需要 1-5 分钟）。步骤 1 — 为物联网自动化创建网络基础设施为安全的 MQTT 通信创建 VPC 网络首先，你将创建一个虚拟私有云 (VPC)，以确保你的 物联网 服务和 MQTT 代理 之间的安全通信，无需公开访问。登录你的 DigitalOcean 控制面板从左侧导航栏进入 网络 → VPC点击 创建 VPC 网络为物联网自动化配置你的 VPC：名称…

基于分层协作多智能体的数据库参数调优——OceanBase 校企研究
type: item
date: 2026-01-29T15:26:06+08:00
description: 摘要：OceanBase联合成都信息工程大学的数据库缺陷实证研究，被软件工程顶刊IEEE TKDE录用。研究聚焦复杂工作负载下数据库参数自动调优的效率与泛化能力问题，提出一种分层协作的多智能体框架，通过创新的训练机制与协同策略，有效破解传统调优方法的瓶颈，为数据库性能优化和预测提供了兼具理论创新性与工程实用性的技术方案。近日，成都信息工程大学与 OceanBase 研发团队合作完成的研究《CMA+DB: How to Automatically Tune Database Parameters through Collaborative Multi-Agents》，被《IEEE Transactions on Knowledge and Data Engineering》（TKDE，CCF A 类、SCI 一区）录用。研究聚焦复杂工作负载下数据库参数自动调优的效率与泛化能力问题，提出一种分层协作的多智能体框架，通过创新的训练机制与协同策略，有效破解传统调优方法的瓶颈，为数据库性能优化和预测提供了兼具理论创新性与工程实用性的技术方案。以下为论文介绍：研究背景与挑战随着分布式与云计算技术的发展，数据库工作负载日趋多样化、复杂化。从高并发的在线交易场景（TPC-C），到随机读写的云服务场景（YCSB），再到高实时性的社交互动场景（Twitter），不同场景对参数配置的需求差异显著。传统调优方式逐渐难以适配这些实际需求：人工调优高度依赖 DBA 的专业经验，不仅需要耗费大量时间梳理参数关系，而且无法应对动态变化的工作负载，往往出现 “调优即过时” 的问题；搜索式调优方法依赖启发式规则，在简单场景下表现尚可，但面对多参数交互的复杂场景时，搜索空间急剧扩大，调优效率大幅下降；贝叶斯优化方法需要手动筛选关键参数，若参数定义不全面，难以找到最优配置；现有强化学习调优方法多采用单智能体设计，仅能对参数进行粗粒度调优，无法充分挖掘不同类型参数间的深层交互影响，调优精度和泛化能力受限。如何实现参数调优的自动化、精准化与高效化，成为数据库领域亟待解决的关键问题。图1 数据库参数调优主要步骤核心理论创新：CMA+DB 多智能体协作框架CMA+DB 框架以 “分类协作、分层训练” 为核心设计理念，构建了三级递进式训练机制，整合单智能体预训练模型 SAPM、多智能体联合训练模型 MATM 与基于概率选择的联合训练模型 PJTM，既保障了单个参数类别内的调优深度，又实现了跨类别参数的协同优化。三个子模型并非孤立存在，而是以级联方式递进工作，前一阶段的训练成果直接作为后一阶段的输入，形成 “基础专精—交互探索—精准强化” 的完整调优链路，确保框架在参数交互捕捉、调优效率与泛化能力之间实现最优平衡。图2 CMA+DB 模型工作原理在技术实现上，CMA+DB 基于深度确定性策略梯度（DDPG）与多智能体深度确定性策略梯度（MADDPG）构建核心算法架构，采用 Actor-Critic 网络结构实现智能体的决策与优化。每个智能体都具备独立的观测空间与动作空间，通过与数据库环境的持续交互获取反馈，不断优化参数调优策略。图3 多智能体 Actor 和 Critic 网络结构在第一阶段，提出单智能体预训练模型 SAPM。训练初期，每个 Agent 负责调优一类功能或参数级别相似的参数，目的是探究单个 Agent 对数据库性能的影响，进而优化其网络，使得其神经网络偏向于调节重要参数。该过程 Agent 之间相互不影响。与传统的单智能体模型相比，SAPM 模型的优点在于更深入地探究相似参数之间的关系，也更容易识别出一些重要参数。这一阶段对于识别关键参数和实现快速收敛至关重要。通过使智能体能够初步掌握参数调整策略，SAPM 为后续更复杂的多智能体训练奠定了坚实的基础，并减少后续阶段的耦合干扰，从而提高了整体效率和效果。在第二阶段，提出多智能体联合训练模型 MATM，在 MATM 模型训练阶段，使用组合算法将多个 Agent 的预测动作组合并映射为一组数据库的推荐配置，要求 Agent 之间不能存在相同的数据库参数。这种协作方法不仅增加了可调参数的数量，还显著增强了模型的表现力和调整能力。此阶段虽然存在耦合，但通过联合训练，能够让智能体逐步适应彼此的行为模式，实现协同优化。在第三阶段，提出了联合动作概选模型 PJTM，在 SAPM 和 MATM 模型训练之后进行训练，算法为每个 Agent 设置了一个概选因子 Pi， Agent 根据 Pi，随机地参与联合动作推荐。当一个 Agent 控制的数据库参数对数据库性能的提升微乎其微时，就可以根据 Pi 减小该 Agent 的动作参与，进而降低其对其它 Agent 所做动作的负面影响。这一机制有效减少了低影响智能体对整体调优过程的干扰，…

【文档悬赏令】第2号：数据库巡检手册征集，上传文档赢好礼！
type: item
date: 2026-01-29T12:16:00+08:00
description: 墨天轮社区举办的 【文档悬赏令】系列活动，每次聚焦一个主题，征集真实、可操作的第一手文档，希望能扩充社区文档资源、为更多人提供有用的参考资料，让技术学习少走弯路！第2号悬赏令活动主题：数据库巡检方案实践数据库巡检是保障业务稳定运行的核心运维环节，更是DBA日常工作的重中之重。当前数据库类型、场景十分丰富，多数从业者需耗费大量时间整理巡检清单、调试巡检流程。墨天轮社区第二期【文档悬赏令】活动特围绕这一主题发起有奖征集活动，诚邀您上传实用、可落地的数据库巡检文档，和社区众位DBA们互帮互助，让巡检工作更高效、更标准！一、活动时间2026 年 1 月 26 日 - 3 月 28 日二、文档要求1、主题范围本次征集聚焦 “数据库巡检” 核心主题，覆盖国内外主流数据库，基础巡检、专项巡检、自动化巡检等多类实用方案等均可，具体范围如下：巡检主题细分（包含但不限于）：基础巡检：日常运维巡检表/巡检清单/巡检手册专项巡检：性能监控与优化巡检/灾备状态巡检/单机or集群巡检方式：手动巡检标准化文档/自动化巡检/脚本命令/巡检工具数据库不限：商业数据库：Oracle、SQL Server等国产数据库：达梦DM8、人大金仓KingbaseES、OceanBase等国产库开源数据库：MySQL、PostgreSQL、Redis等开源库2、合格要求与格式文档内容需明确巡检目的、适用场景、巡检流程等，包含巡检相关代码（部分敏感信息可隐去）。页数要求：≥5 页必加标签：上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类（如 Oracle、OceanBase） 两个标签支持格式：优先推荐 .doc、.pdf、.ppt、.md、.txt 格式（可支持前 5 页预览，下载率更高）；也可上传 .zip （需附内容说明）；以下文档将被判为不合格：1）主题无关：非“数据库巡检”相关主题2）内容搬运：直接上传电子书或产品官方文档、他人演讲PPT，或直接复制抄袭、全文搬运网站其他文章/文档内容（已发布的文章内容不可以同时上传成文档参与活动，但如果是您曾发在其他网站的内容则可以上传参与）3）流水账或凑字数：文档页数需≥5页，但不可通过凑字数、使用大量无关图片占篇幅等4）作者刷量：不可刷数据-我们鼓励作者自发宣传自己的文档，但不可使用人工刷量、注册小号刷量等方式提高下载量；不可将文档拆分多份上传，导致单份内容无实际意义、缺乏完整性5）重复文档：重新上传以前发布的文档系统会自动识别判定为重复仅自己可见，也不可删除旧文档后重新上传三、上传步骤登录上传：登录墨天轮账号后，点击链接直达上传页：https://www.modb.pro/docUpload，或在首页下拉框点击 “传文档”；填写信息：标题：建议明确标注 “数据库种类 + 巡检场景”（如《MySQL数据库巡检手册》《Oracle数据库常规巡检项目和命令》），帮助他人快速判断主题标签：上传时需在 “标签” 栏填写 “数据库巡检” + 数据库种类（如 Oracle、OceanBase） 两个标签墨值设置：支持免墨值 / 5 墨值 / 10 墨值 / 25 墨值 / 50 墨值 / 100 墨值，设置墨值后，他人下载时支付的墨值将实时计入您的账户（ps：一般来说墨值越低下载门槛越低，被下载可能更高）提交：确认信息无误后点击 “提交文档”即可。于 “控制台-内容管理-我的文档” 处可查看您所有文档明细，若您遇到“仅自己可见”“转换失败”等状态可询问墨天轮小助手（VX：modb666）询问具体原因。四、奖励设置本次活动奖励分为 “合格奖”“有效助人奖”“巡检先锋奖” 三类1、合格奖每位用户每日首次上传≥5 页的合格文档，可自动触发 “每日任务” 获 5 墨值。此外，本次活动奖励额外可叠加，根据用户合格文档数量发放不同等级的墨值奖励，具体如下：合格数量墨值0-3个10墨值/份3个以上15墨值/份2、有效助人奖根据单个文档下载数发放不同等级的墨值奖励，每个用户最多可有5个文档获得本项奖励：被下载数墨值30＜被下载数 ≤ 5050墨值50＜被下载数 ≤ 100100墨值100＜下载数 ≤ 150200墨值150＜下载数 ≤ 200300墨值下载数＞200500墨值3、巡检先锋奖将综合评估用户上传的合格文档的内容质量及总下载量，评选出 “既多产、又优质” 的核心贡献者，发予相应奖励：奖项等级奖励内容第 1 名1000 墨值 + 100元内数据库实体书一本第 2 名500墨值 + 爱国者U盘（128GB 双接口）第 3-5 名笔记本电脑支架（可旋转）说明：三类奖项单独评奖、每位用户可重复获得。其中新版本先锋奖数量将根据实际参与情况灵活调整，若参与情况佳则可能增设、反之亦然。五、奖励公布与发放进度公示：为了让大家更加了解自己的参与进度，…

内存一年疯涨 170%，云账单里的“隐性成本”该算清了
type: item
date: 2026-01-28T16:17:56+08:00
description: 2025 年下半年，存储价格又一次成为行业聚焦点。多家市场机构统计显示，2025 年三季度跟四季度，DRAM 和 NAND 价格一路攀升。根据 Tom's Hardware 披露的数据，2025 年 DRAM 合同价同比上涨幅度高达 171.8%，创下历史新高。此轮上涨跟 AI 数据中心建设拓展、服务器需求集中释放紧密相联，还直接引发企业 IT 基础设施采购成本上升。对于依赖自建数据中心或中小 IDC 的企业来说，这种变化带来的冲击尤为剧烈。硬件采购从一次性预算问题，演变为难以预测的长期成本风险。服务器、SSD 和内存条的价格不再稳定，交付周期也更不确定。企业在扩容时不得不承担高价买入、供货延迟的双重压力。因此，将硬件采购压力转化为按需付费的运营支出，把价格波动风险转移给云服务商，正在成为越来越多企业的选择。但问题并未因此结束。随着业务迁移到云端，企业发现云账单中存储与内存的占比仍在持续上升，即便算力配置并未明显升级，总体成本依旧水涨船高。部分团队开始反思：问题是否仅和数据量增多有关，还是资源使用方式本身就存在不合理的地方？目前，多数云实例依旧按固定的 CPU 与内存配比来交付，诸如 2 核 4GB、4 核 8GB 的规格。早期，这种设计可简化资源管理，推动了云计算普及，但如今业务形态有所改变，企业系统一般得同时支撑多样业务，各业务对于算力、内存的消耗不一样，固定规格愈发难以契合实际需求。这导致企业要么部分资源长期闲置，要么不得不面对业务在高峰阶段出现性能瓶颈的风险。当内存价格进入上行周期，这种规格错配带来的浪费被进一步放大：闲置的不再只是资源本身，而是越来越昂贵的成本。正是基于这样的背景，云基础设施走到新的路径分岔口：是继续就资源本身实施配置，还是转变方向围绕应用需求设计算力供给方式？在近期面向中国区合作伙伴召开的发布会上，华为云对 Flexus 云服务器系列规格及性能进行更新，并且展示了其在各种业务负载下的运行表现。该实例基于华为云首创的柔性算力技术，打破 CPU 与内存的固定绑定关系，使企业能够按真实业务需求配置资源，从源头减少内存浪费，并结合智能调度与应用级加速改善长期运行稳定性与算力资源投入产出比。本文将从行业环境变化与技术实现等层面，剖析这种模式背后的思路，以及它所代表的云服务器演进方向。云服务器，开始不太“合身”了云服务器长期采用固定 CPU 与内存的配比，是工程上的一种取舍考量。早期云平台首先得解决的是规模化交付和稳定调度的问题，采用固定规格利于资源池管理，同样便于容量规划及计费设计。当业务形态呈现相对单一阶段，这样的方式尚可接纳。但究其本质它是从平台管理成本角度设计的，并非从业务负载的角度出发。如今业务已不再是单一模式，电商、内容分发、数据库、缓存、AI 推理在一套系统中同步协同运行，对 CPU 以及内存的需求差别明显，固定规格无法精准对应实际负载，企业只能采用超出实际所需的实例型号。云服务器规格跟应用需求普遍不匹配，用户往往被迫去为用不到的算力和内存付费，引发大量资源的闲置浪费。资源浪费只不过是表象罢了，更深层的问题体现为性能优化的复杂度。现实的业务部署不仅涉及操作系统选定，还包含网络参数、系统参数以及应用配置参数。数量往往达到数千级别，缺少专家经验积累，难以达成稳定的最优配置。单是内核跟应用层的参数组合，就已超出普通团队可控范围，调优所用的周期漫长，效果也难以把控。从较长的时间阶段看，云服务器本身一直在不断演变，最初的资源虚拟化阶段，是把物理服务器标准化成可租借的实例；紧接着进入弹性规模阶段，采取自动伸缩的方式去应对流量变化，这两个阶段处理的是存不存在以及是否充足的问题，当下已经迈入第三阶段，关注焦点转向使用是否高效。过去，固定实例曾是工程优势，如今却愈发像是一件穿着不合身的衣服。柔性算力：从“卖规格”到“卖能力”怎样让资源本身更贴近应用？在 Flexus 云服务器 X 实例产品的设计里，华为云引入了柔性算力这一概念。在 Flexus X 实例里，柔性算力首先体现在规格形态的调整变化上。传统实例一般仅仅可在少量固定比例中选择 CPU 跟内存配置，而该实例支持按业务需求实施更精细的组合配置。发布会现场提到，所有 X 实例均支持多种非常规的 CPU/ 内存配比，包括 3:1、2:5、3:7 等组合。这可减少由规格不一致引起的资源闲置，让用户更接近按实际负载付费。然而规格数量增加，并非表示问题自动就解决了，其关键是系统如何判断哪种配置更合适。传统调度大多依据节点上剩余的 CPU 与内存。新方式需要领会业务负载本身，涵盖资源使用结构，以及随时间的变化趋势。Flexus X 实例本质上不再是调度 CPU，而是实际的业务场景。就工程实现而言，这种转变依赖底层架构的支撑，Flexus X 实例借助华为云自研的擎天 Qi…

SQLShift V6.0 发布！函数迁移&达梦适配一步到位！
type: item
date: 2026-01-28T11:16:25+08:00
description: 本次版本 新增函数对象转换能力，扩展了达梦等多数据库迁移适配范围，并提升了批量转换的处理效率，进一步降低企业级数据库迁移的复杂度与成本。一、核心特性支持函数对象迁移​函数对象可随存储过程的迁移任务一键同步转换​。该能力的加入，让 SQLShift[1] 从一款“​存储过程迁移工具​”升级为“​核心业务逻辑对象全量迁移工具​”。随之也带来三重提升：降低迁移风险与人工成本避免 函数对象 需人工逐个改写与反复校验，大幅减少因语法差异、返回值不一致引发的运行期错误。提升非表对象整体迁移效率函数对象与存储过程 可在同一时间中完成迁移与校验，缩短整体迁移周期。保障业务逻辑完整性与可用性避免 函数对象 缺失导致上层存储过程等对象无法编译或运行的问题，有效降低迁移后集中调试与返工压力，提升割接与上线的稳定性。 新增数据库迁移组合本次升级，SQLShift 扩展了多项数据库迁移组合。新增 Oracle / OceanBase → 达梦降低了迁移至达梦数据库的复杂度和人工成本，帮助企业快速完成数据库替换或国产化改造。新增 PostgreSQL → OceanBase（Oracle 模式）减少了跨数据库迁移中的人工调整工作量，加快了从 PostgreSQL 向 OceanBase 的迁移进程。二、其他更新批量处理能力提升支持同时上传多个 SQL 文件进行转换，提升大规模迁移场景下的处理效率。免费试用限时开放！👉 点击领取 你的转换额度，立即体验 SQLShift 智能化迁移带来的飞跃效率！🧩 SQL 方言再多，转换也能一步到位，SQLShift 为你搞定！

PHP 网站重构， Rust/ Python + PostgreSQL + astro+solid，大家觉得怎么样子
type: item
date: 2026-01-27T14:19:08+08:00
description: 如题，传统 php 网站，mysql 数据库，一些 crud 等，pdf 、excel 等处理准备重构：后端 Rust+python 微服务处理 pdf 、excel 等前端 astro+solid数据库 PostgreSQL部署 Podman大家觉得如何，有没有更优化的组合。前几天我还在用 Go ，但是，因为感觉很多人倾向于 Rust 替代 Go ，所有把 Go 替换成 Rust 在试一试

奥特曼小号泄密：OpenAI 代码工作 100% 交给 Codex！工程师才揭底 Codex“大脑”运行逻辑，碾压 Claude 架构？
type: item
date: 2026-01-26T17:58:54+08:00
description: 整理 | 华卫 用一个 PostgreSQL 主库和 50 个只读副本，就顶住了 ChatGPT 上的 8 亿用户！ 近日，OpenAI 的工程师们不仅爆出了这一惊人消息，还直接把 Codex 的“大脑”给扒了个精光。在 OpenAI 官方工程博客主页，OpenAI 工程师、Technical Staff 成员 Michael Bolin 发布了一篇文章，以“揭秘 Codex 智能体循环”为题，深入揭秘了 Codex CLI 的核心框架：智能体循环（Agent Loop），并详细讲解了 Codex 在查询模型时如何构建和管理其上下文，以及适用于所有基于 Responses API 构建智能体循环的实用注意事项和最佳实践。 这些消息传出后，在 Hacker News 等技术论坛及社交平台上获得了高度关注。“看似平淡的技术最终会胜出。OpenAI 正在证明，优秀的架构远胜于花哨的工具。” 值得一提的是，有网友透露，前不久 Anthropic 的一位工程师称“他们用于 Claude Code UI 的架构糟糕且效率低下”。而就在刚刚，X 上出现一条爆料：Codex 已接管 OpenAI 100%的代码编写工作。 对于“你们有多少百分比的编码工作是基于 OpenAI 模型进行”的问题，roon 表示，“100%，我不再写代码了。”而此前，Sam Altman 曾公开发帖称，“roon 是我的小号。” Codex 的“大脑”揭秘“每个人工智能智能体的核心都是 Agent Loop，负责协调用户、模型以及模型调用以执行有意义的软件工作的工具之间的交互。” 据介绍，在 OpenAI 内部，“Codex”涵盖了一系列软件智能体产品，包括 Codex CLI、Codex Cloud 和 Codex VS Code 插件，而支撑它们的框架和执行逻辑是同一个。 Agent Loop 的简化示意图 首先，智能体会从用户那里接收输入，并将其纳入为模型准备的文本指令集，该指令集被称为提示词。下一步是通过向模型发送指令并要求其生成响应来查询模型，这个过程称为推理。推理过程中，文本提示词首先被转换为一系列输入 token，随后被用于对模型进行采样，生成新的输出 token 序列。输出 token 会被还原为文本，成为模型的回复。由于 token 是逐步生成的，该还原过程可与模型的运行同步进行，这也是众多基于大语言模型的应用支持流式输出的原因。实际应用中，推理功能通常封装在文本 API 后方，从而抽象化词元化的细节。 推理步骤完成后，模型会产生两种结果：（1）针对用户的原始输入生成最终回复；（2）要求智能体执行某项工具调用操作。若为第二种情况，智能体将执行该工具调用并将工具输出结果附加至原始提示词中。该输出结果会被用于生成新的输入内容，再次对模型进行查询；智能体随后会结合这些新信息，重新尝试完成任务。这一过程会不断重复，直至模型停止发出工具调用指令，转而生成面向用户的消息（在 OpenAI 的模型中，该消息被称为助手消息）。多数情况下，这条消息会直接解答用户的原始请求，也可能是向用户提出的跟进问题。 由于智能体可执行能对本地环境进行修改的工具调用，其 “输出” 并不仅限于助手消息。在很多场景下，软件智能体的核心输出是在用户设备上编写或编辑的代码。但无论何种情况，每一轮交互最终都会以一条助手消息收尾，该消息是智能体循环进入终止状态的信号。从智能体的角度来看，其任务已完成，操作控制权将交还给用户。 多轮智能体循环 这意味着，对话内容越丰富，用于模型采样的提示词长度也会随之增加。而所有模型都存在上下文窗口限制，即其单次推理调用可处理的 token 最大数量，智能体可能在单次对话轮次中发起数百次工具调用，这有可能耗尽上下文窗口的容量。因此，上下文窗口管理是智能体的多项职责之一。这套智能体循环如何运行？据介绍，Codex 正是借助响应 API 来驱动这套智能体循环的，博文曝出许多背后的实际运行细节，包括：Codex 不会把用户的话直接给大模型用，而是会主动“拼接”出一整套精心设计的提示词结构，且涵盖多个角色的指令、用户输入的一句话在结尾才出现。模型推理与工具调用之间可能会进行多轮迭代，提示词的内容会持续增加。构建初始提示词作为终端用户，在调用响应 API 时无需逐字指定用于模型采样的提示词，只需在查询中指定各类输入类型，由响应 API 服务器决定如何将这些信息组织为模型可处理的提示词格式。在初始提示词中，列表中的每个条目均关联一个角色。该角色决定了对应内容的权重占比，优先级从高到低分为以下几类：系统、开发者、用户、助手。 响应 API 接收包含多个参数的 JSON 负载，其中三个核心参数有：指令：插入模型上下文的系统（或开发者）消息工具：模型生成回复过程中可调用的工具列…

Spring Boot 3 集成 Apache Calcite：多数据源查询的终极解决方案
type: item
date: 2026-01-26T15:22:46+08:00
description: 熟悉 Spring Boot 3 的开发者，都知道它在简化开发流程、提高开发效率方面的出色表现吧！但是，在实际业务场景中，大家肯定都碰到过这样的棘手问题：订单数据存放在 MySQL 里，库存数据在 PostgreSQL 中，用户数据又保存在 MongoDB 中，当多种数据源同时存在时，想要实现统一查询简直比登天还难。所以呢，今天我就亮出我的“终极大招”——Apache Calcite，着重给大家讲讲它怎样与 Spring Boot 3 实现无缝集成，还会分享一些可以直接拿来使用的经典应用场景。掌握了这一招，多数据源查询的难题就能轻松解决啦！一、核心认知：Apache Calcite 为何是多数据源查询的利器？在动手集成前，咱们先把核心逻辑搞明白：为啥 Calcite 能成为多数据源查询的“万能钥匙”？它的核心优势到底在哪？1.1 不止是查询引擎：Calcite 的核心定位Apache Calcite 本质是一个动态数据管理框架，而非传统的数据库。它最核心的价值在于“解耦”——将数据存储与数据查询分离，无论数据存在哪里、是什么格式，都能通过统一的 SQL 接口进行查询。说通俗点，Calcite 就像个“超级数据翻译官”——不管数据藏在哪个数据源里、是什么格式，你只要写一套标准 SQL，它就能翻译成对应数据源能懂的指令，最后把结果整理成统一格式返回。这也是它能搞定多数据源查询的核心秘诀！1.2 Calcite 的核心能力拆解统一 SQL 接口：支持标准 SQL，无论底层是关系型数据库（MySQL、PostgreSQL）、非关系型数据库（MongoDB、Redis），还是文件（CSV、Parquet）、大数据引擎（Hive、Spark），都能通过同一套 SQL 查询。强大的查询优化：内置基于规则和成本的查询优化器，能自动优化 SQL 执行计划，提升查询效率，尤其是在复杂多表关联、跨数据源查询场景下，优化效果明显。灵活的数据源适配：通过“适配器（Adapter）”机制适配不同数据源，社区已提供大量现成适配器，也支持自定义开发，适配特殊数据源。轻量级集成：核心依赖体积小，无复杂依赖，可轻松集成到 Spring Boot、Spring Cloud 等主流 Java 开发框架中，无需单独部署独立服务（也支持独立部署）。二、重点实战：Spring Boot 3 集成 Calcite 核心步骤既然大家都熟悉 Spring Boot 3 的基础操作，我就不啰嗦项目搭建这些常规步骤了，直接聚焦 Calcite 集成的核心环节，每一步都附完整代码和避坑提醒，跟着做就能成！2.1 核心依赖引入第一步先引依赖，在 pom.xml 里加好 Calcite 核心包、对应数据源的适配器，再配上 MyBatis Plus 的核心依赖（替换掉原来的 Jdbc 依赖就行），具体如下： <dependency> <groupId>org.apache.calcite</groupId> <artifactId>calcite-core</artifactId> <version>1.36.0</version> </dependency> <dependency> <groupId>org.apache.calcite</groupId> <artifactId>calcite-mysql</artifactId> <version>1.36.0</version> </dependency> <dependency> <groupId>org.apache.calcite</groupId> <artifactId>calcite-mongodb</artifactId> <version>1.36.0</version> </dependency> <dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.5</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.20</version> </dependency>这里有 3 个避坑点必须强调下：Calcite 所有组件版本要统一，不然容易出现类加载异常；MyBatis Plus 得选适配 Spring Boot 3 的版本（3.5.3+）；一定要加连接池依赖，不然 Calcite 数据源没法被 MyBatis Plus 正常管理。2.2 核心配置：C…

拥抱 PostgreSQL 支持 UI 配置化
type: item
date: 2026-01-26T11:38:52+08:00
description: 前言前阵子写的日志分析工具NginxPulse，自开源以来，已过去 2 周时间，目前 GitHub 已收获 1.5k 的 star 。收到了不少用户的反馈建议，花了点时间将这些问题都处理了下。本文就跟大家分享下新版本都解决了哪些问题，优化了哪些内容，欢迎各位感兴趣的开发者阅读本文。抛弃 SQLite有不少用户反馈说日志文件很大的时候（ 10G+），解析速度非常慢，需要解析好几个小时，解析完成之后数据看板的查询也比较慢（接口响应在 5 秒左右）。于是，我重写了日志解析策略（解析阶段不做 IP 归属地查询，仅入库其他数据，将日志中 IP 记录起来），日志解析完毕后，将记录的 IP 做去重处理，随后去做归属地的查询处理（优先本地的 ip2region 库，远程的 API 调用查询做兜底），最后将解析到的归属地回填至对应的数据库表中，这样一套下来就可以大大提升日志的解析速度。数据库的数据量大了之后，SQLite 的表现就有点差强人意了，请教了一些后端朋友，他们给了我一些方案，结合我自身的实际场景后，最后选定了 PostgreSQL 作为新的数据库选型。这套方案落地后，用户群的好兄弟说：他原先需要解析 1 个小时的日志，新版只需要 10 多分钟。UI 配置可视化使用有一部分用户反馈说他非专业人士，这些晦涩的配置对他来说使用门槛太高了，希望能有一个 UI 配置页面，他只需要点一点、敲敲键盘，就能完成这些配置。我将整个配置流程做成了 4 步，同时也准备一个[演示视频](NginxPulse 支持 UI 配置化了) - https://www.bilibili.com/video/BV1hqzyBVEU9： 配置站点 配置数据库 配置运行参数 确认最终配置 新增 wiki 文档因为配置过于庞大，仓库主页浏览 README.md 比较费劲，希望能整理一份 wiki 文档发上去。花了点时间，简化了下 README ，整理了一份： https://github.com/likaia/nginxpulse/wiki访问明细模块优化有部分用户反馈说希望增加更多的筛选条件以及导出 Excel 功能，现在它来了：概况模块优化概况页面的日期筛选之前放在趋势分析卡片的上方，但是他的切换影响的维度还包含了指标，于是我就调整了下它的位置，新版如下图所示：项目地址 GitHub 地址： https://github.com/likaia/nginxpulse dockerhub 地址： https://hub.docker.com/r/magiccoders/nginxpulse/ 写在最后至此，文章就分享完毕了。我是神奇的程序员，一位前端开发工程师。如果你对我感兴趣，请移步我的个人网站，进一步了解。