OceanBase 4.0,我愿称之为最容易上手的分布式数据库

2024年 5月 7日 30.4k 0

作者简介:张瑞远,曾经从事银行、证券数仓设计、开发、优化类工作,现主要从事电信级IT系统及数据库的规划设计、架构设计、运维实施、运维服务、故障处理、性能优化等工作。 持有Orale OCM,MySQL OCP及国产代表数据库认证。 获得的专业技能与认证包括 OceanBase OBCP、Oracle OCP 11g、OracleOCM 11g 、MySQL OCP 5.7 、腾讯云TBase、腾讯云TDSQL、阿里云ACP 、KingBase KCP。

2010年诞生的OceanBase,虽然在2021年选择了开源,吸引了大量开发者参与社区贡献,并积极举办技术布道、线下沙龙等活动,其社区论坛与博客也是健康发展的状态,但在我看来,直到今年11月3日OceanBase 社区4.0版本的发布,他们才迈出了开源的重要一步。

为什么这么说?因为一个开源生态圈的建立,需要的不光是顶层的技术精英。我相信OceanBase团队研发人员的技术实力都是比较强的,但开源产品的成功靠得不是闭门造车,而是让每一个外部的从业者尽可能地参与进来,表达想法与建议,让更多想法、更多“可能”得到验证。

OceanBase社区4.0版本的发布让更多个人用户拥有了安装、使用分布式数据库的可能,也让产品自身拥有了建立繁荣开源生态圈的机会。下面我从OceanBase的3.x与4.0版本对比、OceanBase 4.0版本与其他热门分布式数据库的安装部署对比,阐述“OceanBase 是最容易上手的分布式数据库”的原因。

OceanBase v4.0相较于v3.x:麻雀虽小,五脏俱全

在OceanBase 4.0版本之前,光看其最低配置要求8核64GB,就让很多对其感兴趣的个人开发者望而却步,更别说复杂的安装及配置了。

3.x版本的快速体验版本(mini版本)是Docker镜像的模式,对于熟悉Docker技术的人来说还算简单,但对于资源的兼容性有一定要求,且可能会有初始化集群或者启动报错的情况,很多人在排查问题的过程中消磨了好多时间。就算所有部署步骤都顺利,也需要2-5分钟的时间,而且官网文档标注仅供研究、学习和评估使用,不适用于生产环境或性能测试场景。

在4.0版本发布后,直接提供了all-in-one package,在已有的虚拟机或者Docker环境可以直接解压安装,而且各个组件都在该包里,可以一个命令全部装上。并且,由于资源占用只要求4核8GB,我们在个人电脑中就可以安装,安装方便快捷,2分钟内就可以搞定。

OceanBase 4.0版本安装更简单,资源需求更小了,功能是不是减少了很多呢?功能并没有阉割,可以扩展,并且性能较之前版本有所提升,官网详细介绍了TPC-C、TPC-H测试,甚至可以通过OBD工具直接测试。可以说,麻雀虽小五脏俱全。

架构:支持单机分布式一体化架构。包含自适应日志流,一个 Unit 内的所有分区的事务修改日志可以都记录在一个日志流中,解决了OceanBase 3.x版本单节点支持的分区数量限制问题;支持超大事务,基于新的自适应日志流架构,对事务引擎进行重新设计,解决了分布式数据库普遍的大事务场景使用痛点;基于全新的自动选主协议以及全面的探活机制,进一步将机器故障场景下系统恢复时间降低到 8s 以内,帮助业务系统更快恢复,最大程度减少业务影响,给业务带来持续可用的能力;基于全新的自动选主协议,取消了对 NTP 时钟的依赖;支持分区数量能力上限等版本基础核心能力,不再需要根据配置限制 OBServer 节点的分区上限个数,但分区上限仍受机器可用物理资源限制。

内核:Online DDL 能力增强。支持添加主键、修改主键和删除主键,支持修改列名和列类型,包括字符、数值、日期等类型的相互转换,支持普通表转换为分区表,持修改表或列的字符序;支持租户级备份,可以根据业务重要性,I/O、带宽之类的资源限制,灵活配置备份方案,扩展更多字符集;支持数据编码,比MySQL、Oracle带了更好的存储压缩比例开源了多种数据编码方法;支持 IOPS 隔离,租户之间彼此感知不到对方对磁盘带宽的占用,避免租户间业务的 I/O 资源争抢,实现完备的租户资源隔离能力; LOB 存储上限扩展达到 512MB,后续将持续优化到 TB 级别;支持表锁和死锁检测,表锁允许业务以指定的方式锁定表或分区新增支持 LOCK TABLE 语法,支持 SHARE 和 EXCLUSIVE 两种锁定模式,同时支持对锁冲突的死锁检测等。

兼容性:进一步增强支持 DDL 语句的外键约束。在早期的版本中,外键约束检查仅对 DML 操作有效,DDL操作不受影响,OceanBase 4.0版本中支持了 FOREIGN_KEY_CHECKS 系统变量对DDL部分的影响,其行为保持与MySQL兼容;支持视图列信息展示,OceanBase 数据库内部仅对表列信息进行了持久化存储,4.0版本通过采用动态解析视图定义的方法,避免了对视图复杂的依赖关系解析,实现在 INFORMATION_SCHEMA.COLUMNS中展示视图列信息;支持DML触发器,支持更多 SQL MODE和函数等;扩展支持SEQUENCE对象,支持存储程序,支持SQL文本中的预处理,支持自增列做为分区键。

性能:SYSBENCH 性能优化,综合读写性能(Read Write)1024 并发测试性能相比于 3.1 版本提升 1 倍;TPC-H 查询性能优化,100GB 数据量顺序执行 22 条 SQL,整体性能相比3.1 版本提升 5 倍。感觉社区版已经全方面包围MySQL了。

运维:支持全链路追踪。在4.0版本发布前,业务出现问题需要从应用到驱动,从Proxy到 Server逐步排查,4.0版本通过解析诊断日志, 即可追踪每个 SQL 每个事务在全链路中执行耗时等相关诊断信息;支持 SESSION 状态的监控和诊断(ASH),帮助用户了解过去一段时间里系统的负载以及等待状态,及时发现并预警问题;标准化视图优化,支持 Schema History 回收功能,支持自动清空回收站功能等。

我们可以看到4.0版本包含了所有的功能,允许个人和企业先从单机开始验证,支持扩展,OceanBase的所有特性都可以体验。作为数据库从业者,我认为每一个功能的新增和优化单独拿出来看,都是不可思议的进步,我从以下几方面谈谈自己的感受。

第一,架构的升级优化真的解决了客户的痛点问题。我们的生产环境一直被分区数限制困扰,运维人员总是烦恼于长事务、悬挂事务、大事务的处理,ntp服务也曾导致几次生产环境的节点启动失败,因为核心数据库分区数较多,受分区切换主节点的时间问题影响,使业务恢复时间不符合要求。

第二,内核能力的升级带来了更多便利和方案的可能性,更灵活的租户分配。其实我们对于字符集、iops隔离和租户级备份感知不高,标准基本只用gbk和utf8,生产环境基本是一套集群一个业务租户,但是很多企业的架构不是这么设计的,他们看中的就是OceanBase的资源隔离,在一套集群上跑好多业务租户,那这几个功能就太实用了,同一套集群上布置多个业务租户,可以调整不同的字符集,因为3.X版本不会对IO进行隔离,仍然可能会影响其他租户的业务,但4.0的隔离更彻底了,这点已经比Oracle的12c之后的pdb模式下的资源隔离做的更好了,而且还可以根据租户的重要性单独配置备份,避免了多余的资源浪费;表锁和死锁检测可能是最能迫切解决生产问题的方式了,数据编码的开源相信对很多开发者会有大帮助,在Oracle存在碎片(核心数据库在10TB左右,迁移库消除碎片的话大约在7TB)的情况下,我们实测真的能减少近十倍的压缩比例。

第三,MySQL兼容性增强,降低迁移难度。个人角度对于MySQL兼容增强可能没有明显感知,但对于企业业务迁移如从MySQL迁移至OceanBase而言,兼容性的加强会大大降低迁移难度。因为我深知我们公司的生产系统当时从Oracle迁移到OceanBase企业版花费的精力,从前期用OMA进行对象语句的兼容性测试,回放wcr进行语句的性能和兼容性测试,到业务改造对象,OMS迁移测试改造不支持表,再到真正能割接上线,这漫长的准备时间是最辛苦的。

第四,运维能力提升。对于运维人员来说真的是福音,我还记得在我们上线OceanBase后,帮业务侧排查问题,从业务日志查到驱动Debug日志,再到OBProxy查询信息,还要配合Server和RS日志各种找关健Trace和信息,大部分信息还需要找研发人员支援分析和排查,真的痛苦。4.0版本支持 SESSION 状态的监控和诊断(ASH),对于我们这批Oracle DBA出身的运维人员很友好。以前只能等业务跑完SQL才能搂取信息,如果卡住没有执行完,只能通过业务提供SQL或查询processlist抓取SQL单独优化分析,4.0版本支持实时执行计划监控,对于SQL问题的排查更加便捷了。

除此以外,对于OceanBase的版本迭代,我还有些贪婪的希望,对于OceanBase中大量的内部视图,官网一直没有详细的解析,如果这部分内容也能让大家看到并方便学习的话,会对用户帮助很大。还有些兼容Oracle 的DBA视图,一些信息不够准确,如果也能完善,那对于从Oracle转OceanBase的DBA大有助益。

OceanBase 4.0相较于其他分布式数据库:部署简单,极易上手

对于数据库业务人员而言,接触的分布式数据库通常只会在企业环境中运行,最初的大部分场景是为了解决集中式数据库对于复杂运算和批量任务对于算力的不足,像大家熟知的Hadoop,最初经典的HDFS+MapReduce,不止增加了存储节点,最重要的是计算节点的增多。但是这类分布式框架下的数据库的使用,需要配合许多组件,由于其安装步骤复杂,上手较难,劝退了一大半个人开发者。

我在这些年接触了很多数据库,获得了Oracle11g OCM认证、MySQL 5.7 OCP认证、OceanBase OBCP认证、KingBase KCP认证,TiDB、TDSQL、TBase和Gbase 8a一系列国产化数据库的初级认证,接触了各种形形色色的数据库。

在我看来,对于大部分数据库从业者来说,都是从学习Oracle和MySQL这两种主流数据库开始的。在固有概念里,大家都认为这两种数据库都不属于分布式,其实Oracle和MySQL都有自己的分布式数据库架构。分布式数据库是用计算机网络将物理上分散的多个数据库单元连接起来组成的一个逻辑上统一的数据库,Oracle在19c新特性还发布了Sharding的分布式数据库架构,但是安装起来比单机更复杂,如果想在个人电脑上体验,还需依赖虚拟机或docker来做多容器,配置catalog库,每个节点安装数据库软件,安装GMS组件,相对比较耗时耗力。MySQL相对于Oracle的优势一直都是安装简便,但是在分布式架构方面,也是通过类似Mycat组件实现的,在单机上部署的话也需要创建多个数据库实例,通过不同端口启动,配置复制关系,然后安装mycat软件,配置相关参数和配置文件,来实现分布式的高可用和读写分离等功能。

而在当今的数据库环境中,大家都在宣传NewSQL的概念,不再是单纯的传统概念的分布式数据库了,都在着重强调HTAP的特性。以TiDB为例,它的生态建设建立得的很好,流行度很高,组件也很方便,与OB使用obd安装(obd demo)类似,它TiDB的安装工具是TiUP,也可以做到一条命令安装,但是其HTAP是基于TiKV和TiFlash两种存储模式实现的,如果要体验HTAP特性,需要同步数据到TiFlash。

ALTER TABLE tab SET TIFLASH REPLICA 1;
SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and TABLE_NAME = 'TAB';

同样宣称HTAP特性的数据库还有OceanBase ,而OB的HTAP特性是基于一套存储的行列混存完成,AP和TP语句不需要人工区分,交由内核处理。因此,所以综上所述,OceanBase OB不光产品做到了功能集中完善,在安装部署的友好度上也更是做到了领先。

在我接触OceanBase 之后,企业版从antman到oat一直在不断简化安装的过程。最初版本的antman的易用程度和Oracle不相上下,社区版4.0发布之后,在两分钟之内即可一键部署一个单节点的伪分布式系统,试问这是哪个学习者可以拒绝的便利?反正我拒绝不了!OceanBase v4.0所采用的架构是单机&分布式一体化架构,这一架构不止区别于传统中心化的单机数据库,也与传统分布式架构的数据库拉开了差距。

总结

正如我跟我同事聊天所得到的信息反馈,OceanBase 4.0版本的发布亮点太多,对于生态来说最成功的意义应该是每个人都可以玩了,只要有时间,随时可以在个人PC上测试练习,甚至对于行业最大的贡献也在于其极大降低了分布式数据库的门槛。但这么说又有些偏颇,因为OceanBaseOB做的不光是安装资源的更友好,产品功能也在飞速完善。自OB从20年开始商业化,2021年开始开源后,到OceanBase今年的4.0发布,从存储到引擎,从架构到功能,其迭代的速度之快让人不敢相信。

如发布会上所说“从小到大”“小就是大”,完备的产品功能,既能够处理 OLTP 核心业务场景,也能够用来处理 OLAP 实时分析场景,不止在小资源规模可以部署,同样可以在大型生产场景部署,让企业能够实现一次选择,终身受用,让个人学习也能一次安装,就可以体验所有功能。

还记得我写的第一篇关于写的OceanBase的ob文章是谈关于OMS的文章,后续也写了不少关于ob本身的博客,一般都是记录问题和解决方案的,我第一篇博客中最后有句话“生态圈的完善本身也是在不断碰撞、修改中完善的。我们踩过的坑都会成为OceanBase进步完善的台阶,后续的同仁再使用相关产品的时候将减少甚至不会遇到我们的问题”。但我没想到,每次遇到的问题会被解决得的会这么快,比如,OBServer一开始不支持split分区、500租户内存不释放、锁机制判断、location组件导致的4025报错。location问题,split分区问题在v3.2.3中被解决,v4.0解决了内存问题和重启时间的问题,增加了锁机制的判断。翻一下自己的博客,最近的一个问题是在10月28日写的,是个内核bug导致的SQL执行计划不对的问题,还有待4.x企业版验证,在其之前的其他问题均已被解决。

我一直以“行之所向,莫问远方”作为自己的座右铭,我习惯先去做,不去考虑能不能成功。但是OceanBase团队一直在努力做这些事情,虽然它和国外优秀的数据库相比存在不小的差距,但其进步的速度和尤其是社区版4.0的发布,让我看到了国产化数据库的远方。在我看来“称其为,最容易上手的分布式数据库“只是OceanBaseOB的冰山一角。

相关文章

最新发布!MySQL 9.0 的向量 (VECTOR) 类型文档更新
国产数据库中级认证HCIP-openGauss经验分享
保障数据完整性与稳定性:数据库一致性
OceanBase 里的 DDL 超时时间
OceanBase v3.1.x 将不再更新版本 | 社区月报2024.6
openGauss Developer Day 2024 | SIG组工作会议亮点回看!

发布评论