-
胖头鱼的技术专栏-485 数据库把 AI 装进内核之后（20261104）
从“数据库平替用金仓”到“AI数据库用金仓”
-
南大通用GBase 8c数据库HTAP让报表实时可查（三）
市政数字系统从报表通的HTAP实时取数，到物联网系统的分布式高写入，再到 PostgreSQL 的平滑迁移，项目落地的每一步，背后都是南大通用GBase 8c分布式数据库（gbase database）能力的支撑 —— 一套技术栈，存储模式、部署形态全部按业务适配。数据库选型的最高境界，不是 “什么都能跑”，而是 “每种负载都跑得刚刚好”。这，就是 本期“内核有数”想和大家分享的底层逻辑。4、从P
-
南大通用GBase 8c数据库HTAP让报表实时可查（二）
在某市政和公共服务融合建设项目中，南大通用GBase 8c分布式数据库（gbase database）以一套技术栈同时支撑了报表通（HTAP）、数据中台、物联感知、CIM、智慧综合杆、AI 大模型等异构业务，覆盖交易处理、批量分析、HTAP与空间数据查询等异构负载。从PostgreSQL平滑迁移，数据库形态按业务特征精准选型，最终实现 “一库多能，统一纳管”。这套架构是怎么落地的？本文继续为你详细
-
南大通用GBase 8c数据库HTAP让报表实时可查（一）
市政数字化系统里，报表往往是“最难啃的骨头”。 底层交易要实时写入，上层报表要随时出数，业务人员还要在几十张表里翻找数据。在某市政和公共服务融合建设项目中，GBase 8c以一套技术栈同时支撑了报表通（HTAP）、数据中台、物联感知、CIM、智慧综合杆、AI 大模型等异构业务，覆盖交易处理、批量分析、HTAP与空间数据查询等异构负载。从PostgreSQL平滑迁移，数据库形态按业务特征精准选型，最
-
GBase 8c数据库HyBench登顶技术解析
HyBench 3810.36分是这套架构的答卷，而Freshness的“0”才是底层硬实力的内核。HTAP解决的从来不只是峰值性能，更是数据的“实时生命力”。南大通用GBase 8c分布式数据库（gbase database）正用这套精密咬合的底层机制，打破交易与分析的物理壁垒，让“既要快，又要准”从愿景变为行业标准。本文将继续拆解，GBase 8c（gbase database）的行列双存机制
-
46台机组全部联网，TDengine为常德卷烟厂卷包车间打造智能制造数据底座
小T导读常德卷烟厂是湖南中烟工业有限责任公司旗下核心生产厂，拥有"芙蓉王"等高端品牌，年产卷烟160万箱以上。其卷包车间率先建成国产高速卷接包智能产线，卷包集成系统将46台机组及13个辅联系统全部联网。面对卷包设备高频采集产生的大规模时序数据，该厂引入TDengine作为时序数据底座，实现了生产数据的实时采集、毫秒级查询与高压缩比存储，为车间"生产透明化、管理精细化、
-
把 seekdb 塞进 iOS App：让混合检索嵌入手机 - 企业级数据库实践
Hold Infinity in the palm of your hand.纳无穷于掌中。—— 威廉·布莱克，《天真的预言》[1]seekdb[2] 终于能在 iOS 上跑了！完整的 seekdb 内核引擎被打包成了 SeekDB.framework ，几行 Swift 代码就能
-
Agent 与数据库交互：安全 SQL 生成与权限控制
导语：当 LLM 从“聊天工具”变成“能动手的系统组件”，数据库往往是最先被接入、也最容易被低估风险的一环。让 Agent 生成 SQL 并不难，难的是让它在生成之后依然可控。本文讨论 Agent 与数据库交互时的安全边界设计，重点落在 SQL 生成约束与权限控制两个层面。 一、问题从哪里开始 Agent 接入数据库的典型链路是：用户用自然语言提出需求，LLM 将其翻译为 SQL，执行后把结果回传给模型，再由模型组织成自然语言答复。这条链路里，风险并不集中在某一个点，而是分布在多个环节： 语义偏差 ：自然语言本身有歧义，模型可能生成“语法正确但语义错误”的查询，例如漏掉时间范围、误用聚合函数。 越权访问 ：模型不知道当前用户的数据边界，可能生成跨租户、跨部门的查询。 写操作失控 ：一旦允许 INSERT 、 U
-
[20261102]光标跟踪事件9.txt
[20261102]光标跟踪事件9.txt--//12c开始pdb，引入pdb导致各个pdb下如何sql语句相同，生成的sql_id相同以及hash值也相同，这样如果多个pdb运行，如果执行的--//Sql语句句相同，再加上如果遇到出现大量子光标情况，岂不是该sql语句出现大量子光标，查询兼容的子光标不是花费很大，这些--//都是我开始转向pdb的想法，前段时间看了链接：--//https://f
-
[20261102]光标跟踪事件8.txt
[20261102]光标跟踪事件8.txt--//12c开始pdb，引入pdb导致各个pdb下如何sql语句相同，生成的sql_id相同以及hash值也相同，这样如果多个pdb运行，如果执行的--//Sql语句句相同，再加上如果遇到出现大量子光标情况，岂不是该sql语句出现大量子光标，查询兼容的子光标不是花费很大，这些--//都是我开始转向pdb的想法，前段时间看了链接：--//https://f
-
[20261102]为什么出现光标出现TOP_LEVEL_RPI_CURSOR不共享.txt
[20261102]为什么出现光标出现TOP_LEVEL_RPI_CURSOR不共享.txt--//记录自己测试遇到的问题，我以为不会出现TOP_LEVEL_RPI_CURSOR不共享，结果还是出现。1.环境：SYS@book> @ ver2==============================PORT_STRING  
-
[20261102]改变pdb名字.txt
[20261102]改变pdb名字.txt--//测试的需要，限制自己测试环境的磁盘大小，不想克隆pdb=book01p，直接改名看看。--//找到1个链接：https://smarttechways.com/2024/11/16/how-to-change-the-pdb-name-in-oracle-database/--//直接按照以上步骤操作。0.安全起见先建立1个冷备份。--//关闭数据
-
从工业本体到 AI 原生：TDengine 出席 2026 QCon 分享工业数据基础设施路径
10 月 22 日至 24 日，2026 QCon 全球软件开发大会上海站举行。涛思数据受邀参会，创始人兼 CEO 陶建辉在主论坛发表题为《打造工业本体，构建 AI 原生的工业数据基础设施》的主题演讲，与来自阿里巴巴、上海交通大学、小影科技等公司的嘉宾同台，围绕 AI 如何真正进入生产系统展开讨论。本届大会由极客邦旗下 InfoQ 中国主办，吸引 1200 余位开发者、架构师与技术管理者到场。演讲
-
Kimi 支持百万级上下文，Agent 还差哪一口气？ - 企业级数据库实践
“To think is to forget a difference, to generalize, to abstract.”思者，略其异，统其类，取其理也。—— 博尔赫斯，《博闻强记的富内斯》[1]楔子（其一）：一本小说前两天，兹拉坦读了一部超短篇小说 ——《博闻强记的富内斯》。小说的主角富内斯是一位乌拉圭青年，一次坠马让他瘫痪在床，却也让他获得了过目不忘的本领：看过的云、树叶的
-
MySQL 国产替换集中式怎么选？ 看这五个维度就够了
————公司的 MySQL 要做国产化替换，到底该怎么选？问的人多了，我发现大家的困惑其实很集中——不是不知道有哪些产品，而是不知道该拿什么标准去比。看宣传材料，家家都说自己兼容 MySQL、性能强、自主可控；真到选型会上，又发现谁都说服不了谁。我自己的习惯是把它拆成五个维度：省成本、易迁移、根自研、AI 能力、品牌兜底。这五个维度过一遍，基本上能筛掉大部分不合适的选项。今天就拿 OceanBas
-
Oracle19c——CDB及PDB基本操作
本文详细介绍了oracle19c中容器、CDB及PDB的基本操作，记录于此，供各位同学及自己研究参考。
-
【TSDB 科普】时序数据库读写：批量写入、顺序读取、时序聚合的范式设计
上期我们聊完时序压缩：再好的压缩算法，也离不开底层读写模型的配合。很多人直接拿 MySQL、PostgreSQL 这类传统关系库的思维去理解时序库，很容易产生一个疑问：为什么同样是存数据，时序库写入、查询的性能差距能拉开几十上百倍？核心根源在于：时序数据库从设计之初，就抛弃了传统数据库以随机读写为核心的范式，转向适配时序数据特征的「批量写入 + 顺序读取 + 预聚合」专属读写范式。传统数据库面向事
-
数据库 Schema 治理：变更规范、影响分析与版本管理
导语 在多数研发团队里，数据库 Schema 的变更往往是最容易被“顺手处理”的一环：一条 ALTER TABLE 、一次字段类型调整、一个索引的增删，看起来只是几分钟的操作，却可能牵动线上可用性、上下游数据链路和多个版本的兼容性。当系统规模扩大、服务数量增加、发布频率提高之后，Schema 变更就从“个人操作”变成了需要被治理的工程问题。 本文围绕数据库 Schema 治理的三个核心环节展开：变更规范、影响分析与版本管理。 一、为什么 Schema 需要“治理”而不是“管理” “管理”关注的是谁在什么时候改了什么；“治理”则进一步要求：变更是否被允许、影响是否被评估、结果是否可追溯、异常是否可回滚。 Schema 之所以需要治理，主要来自几类现实约束： Schema 是多方契约 ：应用代码、数据同步链路、报表
-
数据分析 Agent：从自然语言到 SQL，再到洞察报告
导语：当“问一句话就能拿到数据”成为现实，数据分析 Agent 正在把 BI 的使用门槛从“会写 SQL”降到“会提问题”。但自然语言转 SQL 只是起点，真正决定价值的，是它能否把查询结果转化为可读、可信、可行动的洞察报告。本文围绕这一链路，梳理关键环节、常见难点与落地建议。 一、为什么是“Agent”，而不只是一个翻译器 自然语言转 SQL（Text-to-SQL）并不是新问题，早期的做法更接近“一次性翻译”：用户输入问题，模型输出 SQL，执行后返回一张表。这种方式在简单查询上可用，但一旦问题涉及多表关联、指标口径、时间窗口或后续追问，就容易失效。 数据分析 Agent 的区别在于它具备“过程性”： 多步规划 ：先判断问题需要哪些表、哪些指标，再决定查询顺序。 工具调用 ：可以调用元数据检索、SQL 执行
-
Agentic AI 时代，数据库是“数据源”还是升级为“智慧中枢”？
导语 当 Agentic AI 从概念走向工程实践，一个基础问题正在被重新讨论：数据库在这套体系里究竟扮演什么角色？是继续作为被动读取的“数据源”，还是升级为参与决策、调度与记忆的“智慧中枢”？需要说明的是，本文依据现有素材判断，仅从架构逻辑与工程约束出发做趋势分析。 一、为什么这个问题现在被提出 传统应用架构中，数据库的职责相对清晰：存储、索引、查询、事务保障。应用层负责业务逻辑，数据库负责“记住事实”。 Agentic AI 改变了调用方。智能体不再是一次性请求的接收者，而是具备多步规划、工具调用、状态维持能力的执行主体。它需要： 持续读写上下文与历史轨迹； 在多个工具与数据源之间做选择； 对中间结果做校验与回溯； 在长任务中维持一致的状态视图。 这些需求让数据库从“被查询的对象”变成“参与流程的一方”。问
