登录社区云,与社区用户共同成长
邀请您加入社区
长期以来,OceanBase 与高校、科研机构在技术攻关、成果转化与人才培育等方面展开紧密合作,未来,将持续开放真实业务场景与技术资源,深化合作,聚焦 AI 与数据库融合等前沿方向,协同攻克关键技术难题,推动原创成果从“论文”走向“产品”,从“实验室”走向“产业线”,共同推动中国数据库产业向更高水平迈进。自 2024 年起,CCF 启动产学合作基金项目成果合集收录遴选工作,旨在更好地服务 CCF
OceanBase 进一步通过 LTAP 推动数据库与数据湖的融合,LakeBase 将关系型、JSON、地理空间、文本、图片、视频等不同类型的数据纳入统一的数据基础,并支持混合检索,让 AI 应用能够更直接地访问完整的业务上下文。最直接的答案是:组件数量的大幅减少。16 年的技术积累,让 OceanBase 在原有 TP 与 AP 能力基础上,逐步构建起面向 AI 场景的数据能力体系——通过 A
双方强强联手,联合打造“智慧公积金一体化解决方案”。该方案依托 OceanBase 一体化数据库“一库多能”的特性,为公积金打造覆盖归集、贷款、提取、资金结算全场景的新一代数字化平台,推动行业从“信息化支撑”向“智能化引领”实现升级跨越,助力数字公积金治理能力现代化。从超 700 万缴存职工的信赖,到 99.99% 的高可用承诺,再到面向 AI 的前瞻布局,OceanBase 以“一体化数据库”让
这张凭证的背后,是一场历时一年、覆盖全险种的核心业务系统数智化重构——吉林省社会保险事业管理局借助企业职工基本养老保险全国统筹契机,以 OceanBase 为底座,完成机关事业单位养老保险、企业养老保险、城乡居民养老保险、失业保险、工伤保险、职业年金投资运营、财务系统、公共服务、社银一体化、风控系统、大数据分析及全省定点机构结算等全业务链条的省集中整合。必须打破技术与业务的壁垒,打造一支既精通业务
实测数据显示,相较于传统的记忆管理方案,集成 OceanBase Powercontext 后,准确率提升 49%、延迟降低92%,系统的 Token 消耗大幅降低,仅为原有默认方案的 18%。得益于海量业务场景的长期实践,OceanBase 的所有能力模块——无论是核心的 TP 引擎,还是新兴的向量检索,都经过了海量数据与极端复杂场景的反复验证与优化。回望 AI 工程化的发展历程,我们经历了从
OceanBase 一直沿着“一体化数据库”的方向演进:从核心交易场景的分布式在线交易,到 Oracle 兼容、HTAP、多模型能力和混合搜索。在刚刚过去的 OceanBase Hours 上,OceanBase 正式发布了湖库一体的 AI 数据库。这不只是负载类型和数据模型的又一次升级,而是一个更根本的变化——数据库的用户变了。AI 数据库不是为了支持图片、PDF 或向量,而是因为数据库第一次迎
当 AI 可以持续生成 Agent,数据基础设施面对的规模问题,也从“一个系统里有多少数据”,变成“需要同时管理多少个独立的数据与记忆空间”。面向海量 Agent,OceanBase 提供统一的数据基础设施:通过逻辑表承载每个 Agent 的独立数据空间,通过记忆能力持续保存、检索和调用上下文、历史事实与经验。OceanBase 正在把同一边界继续扩展到数据、索引和生命周期,让一个 Namespa
但直接相加有个问题:如果向量搜索的分数范围是 0~1,而全文搜索的分数范围是 0~30,那全文搜索的分数天然就压过了向量搜索,即使向量搜索认为某个文档非常相关,也抵不过全文搜索的一个中等分数。需要记住的其实还是这个老生常谈的基础概念:向量搜索负责语义召回,全文搜索负责关键词兜底,标量过滤负责把范围框住,融合算法负责把多路结果排到一张榜单里。OceanBase 混合搜索支持在单条 SQL 中融合向量
新版本将 Builder、Web 应用、工作流、MCP 服务全部纳入同一套管理体系,一套运行包完整承载 Prompt、Sandbox、Skills、文件存储、花名册 Roster 五大模块。本次活动围绕【**推理→Agent 运行时→上下文工程】**完整技术主线展开,4 位行业重磅专家同台分享,50+ 位 AI 架构师、智能体开发者、企业技术负责人到场,围绕企业级智能体工程化、安全治理、底层算力、
如果生产结果、检查结果和判断方向都由同一个 Loop 完成,它很容易同时成为运动员、裁判和记分员。Graph Engineering 要设计的,就是多个 Loop 之间,如何分工、交接、纠偏和停手。最近几天,突然到处都在聊。有人把它说成多 Agent 工作流,有人强调运行时生成任务,也有人讨论“让 Loop 检查 Loop”。。当一个 Loop 装不下执行、检查和方向判断时,工程问题才会从 Loo
信也许多业务最初使用MySQL分库分表方案支撑,在该方案中,以下四个痛点对DBA而言应该并不陌生。**第一,研发效能黑洞,跨库查询与分表治理问题。**我们内部有一套面向研发的自动化平台,但当分表数量较多时,排查问题需要做跨分片聚合查询,往往需要DBA协助,流程比较繁琐。而且,大部分业务代码被迫适配中间件逻辑,严重拖累敏捷迭代的交付节奏。**第二,扩容如履薄冰,极高运维风险。**一方面随着业务持续增
但衰减不等于删除,它只是一个持续变化的权重,真正决定一条记忆命运的,是它有没有被再次访问,这跟人脑的工作方式很一致。值得注意的是,LLM 返回的结构化 JSON 中的六维数据实际上并未直接参与最后的权重的计算,在这里让 LLM 返回六维数据只是为了通过 Chain-of-Thought 的结构化分解来辅助 LLM 推理,让最终答案更可靠稳定。初始保留率决定了一条信息在形成瞬间的牢固程度,越重要的信
最后,ScalePQO 为每个模板簇训练一个共享排序模型,在减少模型数量的同时,保留对相似模板的适配能力。更重要的是,IMLane 的解耦调度设计为异构资源的充分利用提供了可能——GPU 、远程服务器、甚至 LLM 推理服务,都可以以Lane为单元被灵活调度,让数据库引擎真正成为 AI 时代的数据处理中心。取而代之的是,IMLane 为 AI 函数维护独立的调度队列。未来,随着 AI 函数在数据分
这一决策的核心考量在于:一体化数据库不是简单的“国产升级”,而是架构重构——无需为不同业务负载部署多套数据库,用性能更优、功能更全、场景融合的一体化数据库,同时完成关键业务负载、实时分析与未来 AI 应用,让技术投入的价值实现最大化。未来,济南轨道交通集团将继续深化与 OceanBase 的合作,探索更多数智化应用场景,以“根自研”技术为基,以一体化能力为翼,推动轨道交通服务迈向更智能、更高效、更
在经过全面的 POC 验证及测试后,OceanBase 很好地解决了当前问题,特别是架构痛点,在承载 MySQL 业务的同时,压缩率及性能上均较原数据库更优,在与研发业务高效协作后,对当前架构进行“大换血”,目前已将原数据库的部分流量切到 OceanBase 进行 POC,运营 B 端已全部走 OceanBase。在保障业务稳定性、可用性前提下,通过切换 OceanBase 来获得性能、成本双重提
OceanBase AI 数据库以湖库一体架构打破数据孤岛,以 HTAP 能力实现实时穿透,以 OceanBase DataStudio 赋能智能数据治理——让央国企收获的不只是一个合规报送平台的数据库,而是一个让 DRP 全域数据流通起来的数智根基,支撑从监管合规到经营决策的全方位数据需求,实现从“被动检查”到“主动治理”的模式跃迁,为央国企在智能经济时代的稳健前行保驾护航。跨周期对比分析:利用
每个子域 Agent 都有自己清晰的边界——数据范围(哪些表、视图、数据源)、Ontology 范围(哪些 Object、Link、Function)、Action 范围(可调哪些查询、分析、执行 Action)、知识范围(文档、SOP、指标解释),以及行为约束(默认只读还是可执行、何时必须人工确认)。典型流程是这样的:用户提出真实业务问题,Agent 用当前空间可用的数据、指标和 SQL 能力完
在经过全面的 POC 验证及测试后,OceanBase 很好地解决了当前问题,特别是架构痛点,在承载 MySQL 业务的同时,压缩率及性能上均较 StarRocks 更优,在与研发业务高效协作后,对当前架构进行“大换血”,目前已将 StarRocks 部分流量切到 OceanBase 进行 POC,运营 B 端已全部走 OceanBase。DBA 报表业务一直基于 MySQL,存在复杂查询耗时长的
这套能力既适合想快速完成 OceanBase 初次部署和连接验证的开发者,也适合需要临时搭建测试环境的工程师、希望向客户或团队演示 OceanBase 能力的技术人员、需要部署 OBProxy、OCP、OMS、OBAgent 等生态组件的团队、需要在开发机上频繁搭建或重建验证环境的技术团队,以及希望将数据库部署和运维流程标准化、自动化的运维团队。你可以让 Qoder 部署 OceanBase,也可
企业还需要解决一系列新的问题:如何隔离不同 Agent 的数据与资源,如何沉淀长期记忆,如何为 Agent 提供安全的试错环境,以及如何让海量多模态数据真正变成可治理、可查询、可使用的资产。OceanBase 给出的答案是:通过存算分离架构与多级存储机制实现冷热分层,将低频访问的“冷数据”下沉至低成本对象存储,实现近零占用,将高频访问的“热数据”驻留于高性能本地盘,突发高峰时自动扩展配额,数据调用
OceanBase DataStudio 则把这些能力产品化成数据团队能使用的工作台:数据接入、数据加工、任务编排、语义建模、质量治理、权限管理、血缘分析、数据集发布和数据服务,都可以在一条链路中完成。一个是 AI 列——你可以理解成表上挂的实时计算列,数据写进来的时候自动跑 Embedding、打标之类的模型计算,结果直接写回表里,而且带事务保证:一批音频要么全部算完,要么全部失败回滚,不会出现
作者:陈松,算秩未来。
它把多模态数据——图片、音视频、PDF、网页快照、向量、JSON、结构化字段——作为数据库的一等数据对象统一管理,并在同一套体系内提供事务、一致性、实时高可用、混合搜索、分析计算和在线服务能力。OceanBase 多模表解决的问题,不是 AI 数据库能不能存图片、PDF 或向量,而是当 Agent 成为数据库的第一用户后,数据库如何继续管理完整的业务对象,而不是一堆彼此孤立的数据类型。多模表中大量
作为企业级的数据基座,我们非常清楚很多客户内部已经有运行了很长时间的数据系统,这些系统承载着企业大量的历史数据资产。所以OceanBase Lakebase 在设计上并不要求客户推倒重来,也不要求把所有数据都迁移进来之后才能使用。我们为 OceanBase Lakebase 设计了两种部署模式:独立部署模式, 适合全新的业务场景。
向量搜索在 AI 数据库里一定是最常见的一种计算方式,但在实际场景里,我们往往首先通过关系过滤将全局数据缩小为一个更小的候选集(例如“只看最近 30 天的订单”),接下来在候选集上做向量、全文、图的混合搜索。原先的做法,往往是采用多个不同的系统——Kafka 做接入,Flink 做流处理,Spark 做批处理,HDFS 做持久化,ClickHouse 做分析,HBase 做宽表,Elasticse
今天,OceanBase 打磨 AI 数据库的土壤,来自阿里与蚂蚁集团最前沿、最复杂、也最核心的真实 AI 场景,包括支付宝 AI 付、蚂蚁阿福、灵光、淘宝 AI 购物助理,以及通义千问、高德、飞猪等业务。OceanBase 会坚定投入这一方向,与客户和伙伴一起,把企业数据建设成可靠、开放、实时、可扩展的 AI 数据底座,让 AI 真正进入业务、理解业务,并持续创造业务价值。数据的一致性、权限的管
它将数据库的事务、一致性与实时处理能力,与数据湖的开放、海量存储和多样化计算能力统一起来,把结构化、半结构化、非结构化数据纳入统一管理体系,打通在线服务与离线分析,消除多系统拼装带来的数据割裂、链路冗余与工程复杂性,为现代 AI 应用提供可靠、实时、可扩展的数据底座。这带来的价值是,让企业的数据架构保持开放和可演进,未来新的计算引擎也可以在同一数据基础上扩展。过去的数据链路是线性的,各环节相互割裂
挑选历史计划时,绝不可单看"平均耗时最短"这个单一维度,谨防极端极少样本导致的性能假象。未来规划:探索一体化向量底座与全自动运维我们在2024年开始使用OceanBase,从特定场景到核心业务依次上线,基于其在这两年的稳定表现,我们计划持续扩大OceanBase的使用范围。例如,将部分MongoDB支持的业务场景迁移到OceanBase,以降低数据库成本。未来,我们还将基于OceanBase优化A
PowerMem部署操作手册,从Linux服务端安装配置、Dashboard使用,到Claude Code与OpenClaw插件接入,完整覆盖Agent记忆层落库流程。
OceanBase两篇论文被VLDB 2026录用,分别介绍云原生共享存储架构(成本降59%/89%)与树形2PC框架,已在生产环境规模化落地。
MaLT将事务元数据嵌入LSM-tree,使提交、回滚和恢复耗时与事务大小无关(常数时间),250万行批量导入端到端快23.9%,恢复稳定在25秒内,已用于OceanBase 4.x生产环境。
OpenClaw默认每轮全量加载MEMORY.md导致Token浪费。OceanBase PowerMem插件改用按需检索与智能抽取,Token消耗降至18%,支持一键或手动安装。
OceanBase 锁问题排查的核心是定位持锁会话及其上锁 SQL。本文提供了一套实用 SQL 脚本,通过 `GV$OB_LOCKS` 等视图精准定位锁对,并揭示了两个关键特性:锁按主键顺序逐行申请,以及锁重试存在“锁管理器”与“占用线程”两种模式;同时分析了存储过程(PL)中锁重试的整块回滚机制,帮助 DBA 高效处理复杂锁等待场景。
Agent无法注册和配置数据库是AI工作流的断点。seekdb D0 提供一个URL,让Agent通过SKILL.md自主创建实例、执行SQL,集成混合搜索与Branch,实现零门槛数据接入。
OpenClaw本地记忆依赖全量加载与session压缩,导致上下文膨胀和关键信息丢失。seekdb M0将记忆独立于上下文,通过混合检索按需召回,并增加经验共享,让Agent具备长期记忆与集体智慧。
Shuffle-DP投毒攻击下提出层次化防御框架,对任意并集保持查询实现检测与恢复,无攻击时误差不变,有攻击时仅增对数因子。
ex-brain受Karpathy的LLM Wiki启发,是一个用LLM编译知识、自动关联实体并支持混合检索的CLI知识库,让笔记像人脑一样持续更新。
混合搜索POC调优与性能排查指南,涵盖查询写法、Hint控制、召回与延迟权衡、性能测试及问题排查,助你快速上手向量查询调优。
OceanBase向量查询调优实战经验:涵盖混合查询写法、召回与延迟权衡、性能测试方法及问题排查手册,帮助开发者快速上手调优。
OceanBase备份包含数据与日志两部分,日志备份近实时(约2分钟/次)。OCP的“保留天数”实际对应recovery_window参数,设1天会保留约2天数据备份和3天日志备份。数据仓库场景下临时表写WAL日志可能导致日志备份空间膨胀。
基于OceanBase seekdb,利用泊松分布模拟比分、Elo胜率抽样淘汰赛,蒙特卡洛重复模拟1000次,在数据库内完成2026世界杯夺冠概率预测。
PowerMem以一条消息为线索,跟踪其从写入到淘汰的完整生命周期,展示重要性评估、分层衰减、复习调度与访问触发的遗忘机制如何协同工作,将认知科学原理转化为工程实践。
OceanBase官方提供基于JDBC的Flink连接器,支持MySQL/Oracle兼容模式,通过Druid连接池和批量写入优化,适用于实时数据同步与流式计算结果写入。
bub是一个Hook-First的Agent微框架,提供精简内核与Tape记忆、Skills引擎等功能插件。bubseek基于bub与seekdb构建,可实现数据洞察Agent的自驱分析与团队协作。
OceanBase Flink DirectLoad连接器利用旁路导入技术,绕过SQL层直接写入存储,实现超高吞吐批量导入(适用于数据迁移、离线ETL),较JDBC方式性能提升数倍。
基于OceanBase自研分布式入库服务,采用Master-Worker架构+K8s弹性伸缩,400亿数据入库从2小时压缩至1小时,吞吐达800万条/秒。
向量数据库PoC实战:基于数据规模与内存预算选索引,HNSW_SQ为千万级首选;64核以上CPU收益递减;分区控制在500-2000万行,稀疏向量列拆小表延迟降7倍。
Agent长期记忆需持久化、检索与安全复用。seekdb与PowerMem提供数据底座与生命周期管理,MoonBit+Wasm实现Skill安全沙箱执行。