检索增强生成 (RAG):OceanBase在联通软研院的落地实践| 优秀征文分享
本文为「让技术被看见 | 2024 OceanBase 布道师计划」的参赛文章。诚邀更多的技术爱好者参与 OceanBase 技术征文,赢取万元大奖,和我们一起用文字让代码跳动起来!投稿说明:作者邱永刚,联通软件研究院 OceanBase 研发负责人,主要负责中国联通自研关系型数据库分布式 CUDB 研发、支撑、运维工作。由于时间及其他个人原因,本投稿由其本人授权官方代为发布,内容著作权归作者邱永
从Oracle PDB到OB多租户体验国产数据库的核心特性| 优秀征文分享
在上一篇文章《从Oracle PDB到OB多租户窥探国产数据库的核心特性之路》中,我以曾经的产品经理视角,来回顾从Oracle PDB到Oceanbase的多租户特性。而数据库终究是一个要实操的软件,仅仅停留在纸面上的理论,终究要落地到实际操作中。针对上一篇文章提出的三个核心需求,我来以自己的实际操作,进一步来体验分析多租户这一数据库的和新特性。细粒度的资源分配与隔离存算与权限,PDB与Ocean
基于OceanBase列存与物化视图的数仓探索| 优秀征文分享
OceanBase在4.3开始,同时支持了行存和列存,以及可刷新物化视图。这些特性给予了这个产品更多的使用场景和可能性。作为过去一年时间里,都是在和数仓打交道的人,我在最近也做了一些基于这两个特性的测试和探索。现阶段的OceanBase,已经可以通过这些特性,来实现流和批两种场景下的数仓建设。一、特性比对1.1 行存与列存我们所熟悉的几个经典数据库产品,都是基于行存的。无论是MySQL的innod
新闻 | Check Point Infinity平台荣获“创新解决方案奖”.....
2024年,网络安全领域迎来了前所未有的挑战:人工智能与网络安全的深度融合、勒索软件攻击的猖獗、零日漏洞的频繁利用、高级持续性威胁(APT)攻击的加剧、供应链攻击的增长……
中国移动协同创新基地浙江中心 BOSS 系统基于GoldenDB的分布式改造应用实践
信息技术创新与应用已成为推动各行业进步的关键力量。中国移动积极发挥企业创新主体作用,全面推进战略性新兴产业发展,统筹规划全国布局的协同创新基地。
存算分离架构实践:金融机构数据库优化之道
近日,由北京金融信息化研究所等单位联合发布的《金融数据库存算分离架构选型白皮书》,为金融机构在金融行业数据库架构选型与优化方面提供了宝贵的指导与建议,助力金融机构在数字化转型的道路上迈出坚实的一步。 从数据库技术的早期探索(1960年代)至今,存算分离架构始终是其中的重要篇章。以文件系统数据库为起点,存算分离的理念便已初现端倪,支持着单体应用的稳健运行。随后,关系型数据库的蓬勃发展,更是将存
成为oceanbase贡献者第三天:内存管理使用小技巧
大家好,这是成为oceanbase贡献者的第三篇文章,本文主要讲述内存管理使用技巧,这里并没有直接从ob代码说起,而是从一个普通人学习c++语法,了解其他平台小细节开始,同时 如果句子不通顺地方,说明理解可能有偏差,请指教阅读本文章你将受益如下重载运算符new 与malloc在返回值上区别?在ceph 双向链表新用法,一个类定义时候 成员变量就是包含了 双向链表节点,可以通过该节点反推 类其他变量
使用 obdiag 评估预建索引空间大小
1. 背景最开始不过是一次平淡无奇的报错:4184 - Server out of disk space,一次社区问题的讨论: 新建索引空间膨胀问题,一个新功能特性的诞生: obdiag 索引空间预估,直到有机会在这里和大家讨论学习。OceanBase 索引磁盘空间放大问题究其根因是其存储引擎是基于 LSM-Tree 架构实现的,LSM-Tree 的设计理念是将随机写操作转化为
OceanBase写入限速源码解读
作者:陈慧明爱可生测试团队成员,主要参与dmp和dble自动化测试项目。本文来源:原创投稿* 爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。一、简介OceanBase中的写入限速机制旨在控制系统中写入操作(一般写入操作包括插入、更新和删除等)的速率,目的是为了提高数据库系统的稳定性。本文主要通过以下2个参数来解释写入限速的实现机制。writing_throttling
OceanBase 手滑误删了数据文件怎么办?
作者:张乾外星人2号,现兼任六位喵星人的资深铲屎官。本文来源:原创投稿* 爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。手滑误删了数据文件,并且没有可替换的节点时,先别急着提桶跑路,可以考虑利用参数 server_permanent_offline_time 来重建受影响的节点。原理:server_permanent_offline_time 是 OceanBase
成为OB贡献者(4):从单点到多节点 i++并发方案
要点:单点到多节点 i++并发方案只有1个节点,用锁只有2个节点,一个是客户端,一个存储节点,查询加锁,更新解锁如果多个节点,通过2轮RPC 执行多数派方式接受一个值(被确定了)。提案被批准一定不会被修改,意思是可以更高提案编号,但是提案值不变。提案被被接受,最后可能会被修改,也可能不会被修改,不确定本文最清楚分析个人认为第二章节 2.3 情况2,根据图片给出观察结果 总结论是对的,然后分析执行过
如何快速通过日志分析定位 OBServer 的 crash?
作者:胡呈清,爱可生 DBA 团队成员,擅长故障分析、性能优化,个人博客:[简书 | 轻松的鱼],欢迎讨论。适用版本都适用说明crash 即 observer 进程崩溃退出,常见的原因有:程序 bug、文件损坏、磁盘坏块、内存坏块,是一种比较难分析的故障。集群部署时会自动配置 coredump,因此发生 crash 会自动生成 coredump 文件(捕获进程崩溃时内存的文件),它包含程序在失败时
存储过程慢?可能是 plan cache 失效了
作者:程柳润,爱可生 DBA 团队成员,OceanBase 数据库技术爱好者。问题描述业务反馈一个存储过程执行慢,需要排查原因。由于存储过程过长且涉及多张表,所以主要分享排查思路。分析过程1. 查找该存储过程的 trace_id每次执行存储过程后会有两条记录,两条记录 SQL 的请求类型不同,先产生的记录是预编译的记录(执行耗时很小),另一个是实际执行的记录。obclient [ocea
OceanBase 租户延迟删除的设计猜想
杨涛涛,资深数据库专家,专研 MySQL 十余年。擅长 MySQL、PostgreSQL、MongoDB 等开源数据库相关的备份恢复、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生,为各大运营商及银行金融企业提供 MySQL 相关技术支持、MySQL 相关课程培训等工作。OceanBase 关于租户的删除设计了以下三种方式:正常删除:租户里的各种对象也被删除,具体表现形式依赖sys租户
深入理解 LSM-Tree 和 OceanBase 分层转储
金长龙,爱可生测试工程师,负责DMP产品的测试工作先前在做 OB 存储引擎这块学习的时候,对 OceanBase 的分层转储和 SSTable这块有些细节就懵懵的,比如L0层的 mini SSTable 的每次生成是否就计入转储次数,L0层到L1层转储的时机以及和 minor_compact_trigger 之间的关系等。今天就这部分内容做个更细致的探究,试图更深入的理解 OceanBase 的分
深入理解 LSM-Tree 和 OceanBase 分层转储
金长龙,爱可生测试工程师,负责DMP产品的测试工作先前在做 OB 存储引擎这块学习的时候,对 OceanBase 的分层转储和 SSTable这块有些细节就懵懵的,比如L0层的 mini SSTable 的每次生成是否就计入转储次数,L0层到L1层转储的时机以及和 minor_compact_trigger 之间的关系等。今天就这部分内容做个更细致的探究,试图更深入的理解 OceanBase 的分
OceanBase_CE 4.2.1.7 容器化单机部署
OceanBase_CE 4.2.1.7 容器化单机部署# docker的版本过低拉取镜像错误: missing signature key# https://developer.aliyun.com/mirror/docker-ce/[root@ecs ~]# yum install -y yum
OceanBase如何查看表大小和索引大小?
OceanBase查看表大小和索引大小,正常来说只需在OCP上进入任意普通租户下,选择左侧菜单资源管理即可查看,但是最近我发现,这里显示的索引大小与实际后台SQL(见下文)查看的索引大小数据不一致,经过官方问答社区帖子询问:https://ask.oceanbase.com/t/topic/35609708/11,又仔细研究了下相关视图,于是有了这篇文章。在 ob 4.x 版本之前,大部分情况下都
成为OB贡献者(5):从一道OBCE面试题再探Paxos
为了整理思路,文章采用模拟2人对话方式,如有误,欢迎留言。Basic-Paxos协议回顾一天下午,小王同学正在津津有味回顾:<<成为OB贡献者第四天:从单点到多节点 i++并发方案 >>通过假设一个存储服务,2个客户端,3个存储节点 存储一个值方式 解决并发问题 引出 Basic Paxos任何成员都可以提出议案,然后通过2轮 RPC 来确定只一个值。(这里没考虑持久化)关
记录一次OB3.xRS异常4019
背景:前两天上午突然收到告警,observer进程不存在。赶紧检查集群,发现告警集群的三台server处于inactive的状态,该集群架构为3-3-3。平时业务的primary_zone是zone3,sys租户的primary_zone在zone1,inactive的是zone1的两台机器。zone2的一台机器,zone1是一个机房,zone2和zone3在另外的机房,万幸的是业务反馈告警时候断