-
NineData 10 月产品动态｜新增 18 组复制对比链路，AI Agent、Oracle 复制深度增强
10 月 NineData 持续升级数据库 DevOps、AI Agent 与异构数据复制能力：新增 18 条数据复制对比异构链路，新增 Databricks 数据源，强化 SQL 规范管控、OnlineDML、慢查询治理；优化权限审批、OpenAPI 与敏感脱敏流程；ChatDBA 交互与模型管理更新；Oracle、TiCDC、A2A 复制能力大幅增强，批量修复多数据库兼容性问题，提升异构同步稳定性与研发协作效率。
-
无需自研脚本：用 NineData 快速打通 PostgreSQL 与 StarRocks 数据链路
将 PostgreSQL 业务库数据实时同步到 StarRocks，是构建实时分析能力的常见选择。本教程基于 NineData 数据复制控制台的完整实操录屏，演示从创建复制任务、选择实例、周期性全量与增量复制配置，到对象选择、映射、预检查、结构/全量/增量复制、监控运维与数据对比的完整流程。
-
数据库教程FGMT86：AI-DBA自动化运维开发快速入门
数据库教程FGMT86：AI-DBA自动化运维开发快速入门
-
MySQL 同步到 Doris 怎么做？NineData 实时复制实战教程
NineData 实操演示 MySQL 到 Doris 的数据迁移，详细讲解版本兼容、无主键表校验、Binlog 与账号权限配置等关键检查项，并演示如何按源表主键、唯一键自动选择 Unique 或 Duplicate 模型并定义 Key 与 Distribute Key。同时分享存量数据清空重写等安全策略。跟随视频即可低门槛完成 MySQL 到 Doris 的平滑迁移，平稳支撑业务向实时分析架构演进，缩短改造周期、控制迁移风险。
-
数据库厂商如何应对这场 AI 变革：技术、组织与生态的三重考验
导语：大模型正在重写数据库的使用方式——查询入口从 SQL 编辑器变成自然语言，数据形态从结构化行列表扩展到向量与多模态，负载特征从稳定可预期变成突发且长尾。对数据库厂商而言，这不是一次版本升级，而是一次产品定义、组织能力与生态位的同时重构。本文从技术、组织、生态三个维度拆解应对路径。 一、变革到底改变了什么 在讨论“怎么应对”之前，先要明确 AI 对数据库的冲击落在哪几个层面。可以归纳为四点： 第一，交互层被重构。 自然语言到 SQL 的转换（NL2SQL）、基于检索增强生成（RAG）的问答，让大量非专业用户直接触达数据。数据库不再只是被应用程序调用的后端组件，而开始承担“对话式数据服务”的角色。 第二，数据模型被扩展。 向量检索成为标配需求，文档、图像、日志等非结构化数据需要与结构化数据在同一套系统内协同管
-
Agentic AI 时代，数据库面临哪些挑战？
导语 当大模型从“回答问题”走向“执行任务”，Agentic AI（智能体式 AI）正在把数据库从被动存储系统推向主动决策链路的核心位置。智能体需要读写记忆、调用工具、维护状态、协调多步事务，这些需求与传统 OLTP/OLAP 负载存在结构性差异。 一、从“查询”到“行动”：负载形态的根本变化 传统数据库的负载以人驱动的 SQL 查询为主，请求边界清晰、可预期。Agentic AI 引入的变化在于： 请求由智能体自主发起，频率、并发和时序难以预先建模； 一次任务对应多轮读写，包含检索、写入记忆、更新状态、回滚重试等混合操作； 读写比例动态漂移，同一系统内可能同时承载高频小写入与长上下文检索。 这意味着容量规划、索引设计和缓存策略都需要重新评估，而非简单扩容。 二、核心挑战梳理 1. 状态与记忆的持久化 智能体需
-
Agentic AI 时代，数据库准备好了吗？
导语 当大模型从“回答问题”走向“执行任务”，Agentic AI 正在把数据库从被动的存储后端，推向智能体决策链路的核心位置。智能体要规划、要调用工具、要读写状态、要记住历史，这些动作最终都会落到数据层。问题随之而来：为人类应用和传统微服务设计的数据库，是否足以承载一个会自主行动的软件实体？ 一、Agentic AI 改变了数据库的使用方式 传统应用对数据库的访问是确定性的：请求进来，SQL 执行，结果返回。访问路径由开发者预先写好，频率和模式可预测。 Agentic AI 引入了几处结构性变化： 访问主体变了。发起查询的不再只是后端服务，而是会自主拆解任务、多轮试错的智能体。一次用户请求可能触发数十次数据库交互。 访问模式变了。智能体倾向于“先查再想、边想边查”，查询从批量、可缓存，变成高频、碎片化、上下文
-
Agentic AI 时代，数据库会退化为“数据源”还是会升级为“智慧中枢”？
导语 当 Agentic AI 从“被动回答问题”走向“主动规划并执行任务”，一个绕不开的基础设施问题浮出水面：数据库在这场范式迁移中会被降级为被调用的“数据源”，还是会升级为参与决策的“智慧中枢”？ 一、先把问题问清楚：两种角色意味着什么 “数据源”与“智慧中枢”并不是非此即彼的营销标签，而是两种截然不同的系统定位。 数据源定位：数据库负责存储与检索，Agent 负责理解、规划与决策。数据库被动响应查询，价值体现在吞吐、延迟、一致性和成本。 智慧中枢定位：数据库不仅存数据，还承载语义、上下文、记忆与策略，主动参与 Agent 的推理链路，甚至对“该不该执行某个动作”给出约束与建议。 两者的关键分野在于：决策权与语义理解放在哪一层。 二、为什么“退化为数据源”是一种真实风险 Agentic AI 的一个典型架构
-
“尚工”行动・百家千企深度行2026第十四场（烟台站）顺利举办
11月5日，“尚工”行动・百家千企深度行（烟台站）公益赋能专项活动在烟台顺利举办。
-
用 Codex 处理数据库改动，我的规矩是：只让它生成脚本，不让它执行
在生产环境附近用 AI 改数据库，是我现在最谨慎的一类操作。代码改错了可以回滚重发，数据改错了，很多时候没有后悔药。这半年我用 Codex 处理过几次表结构调整和数据修复，固定下来一条规矩：它只负责生成脚本和校验清单，执行永远是人来按。具体拆成四步。第一步：让它先出「影响面报告」，不许直接写 SQL我先让它读相关的表结构、实体类和调用方代码，输出一份报告：这张表被哪些服务读写、有没有外键和触发器、
-
AI时代，知识与本体的演进与思考：从数据工程到知识工程
编者按：根据云器科技联合创始人 & CTO 关涛在2026DACon 北京的KeyNote演讲分享整理，本文围绕知识表达、获取、加工与持续更新展开，结合两个实践案例及知识工程架构进行讨论。图示来自分享资料，如需获取完整版分享材料，可点击下方小程序下载。导言：从数据处理走向知识生产过去，从关系数据库到大数据平台，数据技术主要解决的是将原始数据加工成信息的问题。原始日志被转换为BI报表，交易记
-
NineData 五周年团建 | 让数据奔涌，热爱无界！
NineData 五周年，感谢每一位 NineData 人的全力以赴，感谢各位合作伙伴的同心相伴，更感谢每一位客户的信任与支持。五载同行，感恩有您；数据奔涌，我们一起向上生长！未来，NineData 将继续怀揣「代码有解，热爱无界」的信念，与您携手，奔赴更辽阔的山海！
-
10月数据库圈值得关注的事 | 2026
Gartner近日公布2027年企业机构需要关注的十大战略技术趋势，包括数据库在内的主权技术成为新的趋势;中国计算机学会(CCF)与阿里云联合发布《CCF-阿里云瑶池科研基金2026年度指南》，本年度基金指南围绕三大研究方向设置8项重点课题;达梦数据2026年前三季度营业收入11.14亿元，比上年同期增长34.22%;镜舟科技正式发布MirrorShip Intelligence Platform(MIP)……
-
追溯父子码关系怎么存？边表设计与递归反查SQL
本文讨论条码追溯里父子码关系的边表建模与递归反查写法。
-
Agent 与数据库交互：安全 SQL 生成与权限控制
导语：当 LLM 从“聊天工具”变成“能动手的系统组件”，数据库往往是最先被接入、也最容易被低估风险的一环。让 Agent 生成 SQL 并不难，难的是让它在生成之后依然可控。本文讨论 Agent 与数据库交互时的安全边界设计，重点落在 SQL 生成约束与权限控制两个层面。 一、问题从哪里开始 Agent 接入数据库的典型链路是：用户用自然语言提出需求，LLM 将其翻译为 SQL，执行后把结果回传给模型，再由模型组织成自然语言答复。这条链路里，风险并不集中在某一个点，而是分布在多个环节： 语义偏差 ：自然语言本身有歧义，模型可能生成“语法正确但语义错误”的查询，例如漏掉时间范围、误用聚合函数。 越权访问 ：模型不知道当前用户的数据边界，可能生成跨租户、跨部门的查询。 写操作失控 ：一旦允许 INSERT 、 U
-
数据库 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 改变了调用方。智能体不再是一次性请求的接收者，而是具备多步规划、工具调用、状态维持能力的执行主体。它需要： 持续读写上下文与历史轨迹； 在多个工具与数据源之间做选择； 对中间结果做校验与回溯； 在长任务中维持一致的状态视图。 这些需求让数据库从“被查询的对象”变成“参与流程的一方”。问
-
数据库可观测性：从慢日志到根因分析的完整方法论
导语：当业务方反馈“数据库又慢了”，DBA 打开监控面板看到 CPU 飙高、连接数打满，却很难在短时间内说清“到底慢在哪、为什么慢、该改什么”。数据库可观测性的价值，正是把慢日志、指标、链路追踪这些分散信号组织成一条可追溯的证据链，让根因分析从经验判断走向数据驱动。 一、为什么“看监控”不等于“可观测” 传统数据库运维依赖监控面板：CPU、内存、连接数、QPS、慢查询数量。这些指标能回答“系统是否异常”，却很难回答“异常由什么引起”。 可观测性（Observability）强调的是： 仅通过系统对外输出的数据，就能推断其内部状态 。落到数据库场景，通常由三类信号构成： 日志（Logs） ：慢查询日志、错误日志、审计日志，记录“发生了什么”。 指标（Metrics） ：时序化的数值，记录“变化趋势与资源水位”。
-
如何提升 NL2SQL 的质量：从“能跑通”到“可上线”的工程化路径
导语 NL2SQL（Natural Language to SQL）正在从演示型能力走向企业数据问答、BI 自助分析、智能报表等真实业务场景。但在实际落地中，很多团队都会遇到同一个问题：Demo 阶段效果惊艳，一旦接入真实库表、复杂口径和多轮追问，准确率与稳定性就明显下滑。 NL2SQL 的质量提升不是单一模型问题，而是“数据理解 + 检索增强 + 生成约束 + 校验反馈 + 评测闭环”的系统工程。 一、先明确：NL2SQL 的“质量”包含哪些维度 讨论提升之前，需要先把质量拆解为可度量的维度，否则优化容易失焦。通常可从以下几个层面评估： 语义正确性 ：生成的 SQL 是否真正回答了用户问题，而不只是语法正确。 执行正确性 ：SQL 能否在目标数据库上成功执行，是否存在字段、表名、方言错误。 结果正确性 ：返回
