共计 7151 个字符，预计需要花费 18 分钟才能阅读完成。
2021 年 6 月 1 日，OceanBase 首次对外发表开源。过来的一年工夫里，OceanBase 社区版在社区和用户驱动下失去飞速发展，外围能力失去了十分大的冲破。从最后的外围内核引擎 300 万行代码全副开源，到基于第一批开源用户的实在场景及业务需要，咱们与社区开发者独特打磨欠缺内核及生态工具能力。越来越多的用户把 OceanBase 社区版用在外围业务场景，从“能用”到“好用”，过来的一年里社区版取得了很多开发者的认同和用户的青睐。
2022 年 11 月 3 日，OceanBase 社区版 4.0 Beta 版本（代号：小鱼）正式公布，这是社区版的全新里程碑。 作为业内首个兼容 MySQL 8.0 的单机分布式一体化数据库，OceanBase 社区版 4.0 全面凋谢 MySQL 兼容能力，全面兼容 MySQL 8.0 协定，大幅晋升 Online DDL 能力，反对超大事务，反对主键变更、主键增删改等。在多租户的外围能力方面，首次将 IO 纳入隔离体系，并将集群级别粒度的备份能力细化拆分到租户级别粒度，最小可反对按租户级别的备份及复原。
经测试，OceanBase 社区版 4.0 在等同硬件环境下，OLTP（联机事务处理）性能是 MySQL 的 1.9 倍，OLAP（联机剖析解决）性能是 Greenplum 6.22.1 的 5 到 6 倍，既可能稳固牢靠解决 OLTP 外围业务场景，也可能用来疾速解决 OLAP 实时剖析场景。具备单机分布式一体化能力，能够反对业务最后仅应用单机部署，同时具备单机到多机程度扩缩容的能力。
外围能力与用户价值
OceanBase 社区版 4.0 在保障性能个性不失落的前提下，从新扫视了数据库与分布式系统两个畛域最根底的设计，全新推出业内首个单机分布式一体化架构。与此同时，本版本也从架构上解决了 3.x 版本的设计瓶颈，反对用户业务关注的多个外围能力，在内核性能、兼容性、稳定性、性能上获得冲破。
- 单机分布式一体化架构：自适应日志流、反对超大事务、RTO 工夫升高到 8s 以内、NTP 服务依赖优化、反对分区数量能力下限等版本根底外围能力构建；
- 内核能力加强：Online DDL 能力加强，反对租户级备份，字符集扩大，反对数据编码，反对 IOPS 隔离，LOB 规格下限扩大，反对表锁和死锁检测等；
- 兼容性加强：反对 DDL 语句的外键束缚，反对视图列信息展现，反对 DML 触发器，反对更多 SQL MODE 和函数等。扩大反对 SEQUENCE 对象，反对存储程序，反对 SQL 文本中的预处理，反对自增列作为分区键。
- 性能大幅晋升：SYSBENCH 性能优化，综合读写性能（Read Write）1024 并发测试性能相比于 3.1 版本晋升 1 倍。TPC-H 查问性能优化，100GB 数据量程序执行 22 条 SQL，整体性能相比于 3.1 版本晋升 5 倍。
- 运维能力晋升：反对全链路追踪，反对 SESSION 状态的监控和诊断（ASH），标准化视图优化，反对 Schema History 回收性能，反对主动清空回收站性能等。
单机分布式一体化架构降级
▋自适应日志流
OceanBase 晚期版本的架构体系里以分区为根本单元进行操作，当零碎内的分区数量达到肯定水平之后，以分区为单元的操作的耗费也随之增大，逐步造成了 OceanBase 的应用痛点：单节点反对的分区数量受到限制，单节点上波及跨分区的数据批改也须要两阶段提交协定来保障事务的原子性等问题。
日志流是由 OceanBase 主动创立和治理的实体，它代表了一批数据的汇合，包含若干分区和有序的 Redo 日志流。在新的零碎架构下，一个 Unit 内的所有分区的事务批改日志能够都记录在一个日志流中，通过日志流把批改同步到其余 Zone 的对应 Unit 上。OceanBase 的每个租户每有一个 Unit，就会有一个对应的日志流。零碎会把一个日志流和其所对应的分区关系固定下来，只有迁徙产生时，才会扭转这个对应关系。
▋反对超大事务
基于新的自适应日志流架构，对事务引擎进行从新设计，解决了分布式数据库广泛的大事务场景应用痛点，比方事务大、参与者数量多、事务提交卡等问题。新事务引擎能稳固应答在线业务、批处理、勘误数据等多种业务场景，使得用户在各自繁冗的业务场景下能够释怀的应用数据库。
▋RTO < 8s
基于全新的主动选主协定以及全面的探活机制，进一步将机器故障场景下零碎复原工夫升高到 8s 以内，帮忙业务零碎更快复原，最大水平缩小业务影响，给业务带来继续可用的能力。
▋NTP 服务优化
基于全新的主动选主协定，勾销了对 NTP 时钟的依赖，突破原来晚期版本对所有节点的时钟偏差管制在 100ms 以内的强需要。OceanBase 4.0 版本容许的时钟偏差能够达到 2s，同时反对动静批改时钟，不会对数据正确性和集群稳固运行带来影响。
▋优化分区能力下限
在自适应日志流的架构设计下，零碎外部一个 Unit 内的所有分区共享一个资源组，大大降低了晚期版本每个分区独立申请保留系统资源，晋升系统资源的利用率，因而不再须要依据配置限度 OBServer 节点的分区下限个数，但分区下限仍受机器可用物理资源限度。
内核能力加强
▋Online DDL 能力加强
在 OceanBase 晚期的版本中，因为架构设计上的限度，对数据库 Online DDL 能力进行了无限反对，例如不反对主键批改操作给业务应用带来了诸多不便。得益于新版本一体化的架构设计，OceanBase 针对波及到数据搬迁的 Online DDL 操作进行加强反对，次要包含：
反对增加主键、批改主键和删除主键
反对增加外键、删除外键
反对批改列名和列类型，包含字符、数值、日期等类型的互相转换
反对一般表转换为分区表
反对在线批改表或列的字符序
▋反对租户级备份
多租户是 OceanBase 的外围价值能力之一，在大多数客户零碎中，用户都抉择在同一个集群中创立了多个租户，每个租户代表一个业务单元，依据业务的不同品种和对客户的重要水平，须要有不同的备份频率和策略进行细粒度反对。在 OceanBase 社区版 4.0 中将集群级别粒度的备份能力细化拆分到租户级别粒度，反对按租户级别的备份，也反对将备份数据恢复到新租户。优化数据备份快照保留策略，缩小备份期间的磁盘空间影响。同时拆分数据备份与日志备份存储目录，反对别离接入不同性能的备份介质。
▋向量化引擎开源，AP 能力全面加强
OceanBase 在企业版 3.2.3 全面实现了向量化引擎，以 Architecture aware 的设计革新了全副的算子和绝大部分罕用的执行表达式，充沛挖掘古代 CPU 的 cache 个性以及优化指令，并利用于 TPC-H 的 benchmark 中。向量化带来了大量的算法优化可能，通过在向量化的框架下进行算法和数据结构优化，实测整体执行性能相比原先非向量化执行引擎性能晋升广泛在 4-5 倍，很多算子和单场景可取得 10 倍以上的性能晋升。在本次版本公布中，OceanBase 将其向量化引擎能力全副开源，帮忙用户在 OLAP 场景下获取更好的性能。
▋数据编码开源，数据压缩比进一步晋升
OceanBase 通过数据编码压缩技术实现了数据的高压缩比，是帮忙用户减小存储老本重要技术手段。OceanBase 本次开源多种数据编码办法，包含字典编码、RLE 编码、常量编码、差值编码、前缀编码、列间编码等，并反对每一列主动抉择最合适的数据编码。通过编码和压缩，应用雷同的块大小（16KB）、以及雷同的压缩算法（lz4），同样的数据寄存在 OceanBase 中，要比在 MySQL 5.7 中均匀节俭一半的空间，同时没有损失任何查问性能。
▋隔离能力再降级，反对 IOPS 隔离
OceanBase 晚期的版本曾经反对了租户级别的 CPU 和内存隔离，4.0 版本开始反对租户间 IOPS 隔离，租户之间彼此感知不到对方对磁盘带宽的占用，防止租户间业务的 IO 资源争抢，实现齐备的租户资源隔离能力。
用户通过 UNIT CONFIG 设置 UNIT 的资源规格，其中 MIN_IOPS、MAX_IOPS、IOPS_WEIGHT 是 IOPS 隔离相干资源，租户的可用资源与 UNIT 绑定。告诉反对动静调整租户的 IOPS 规格，批改 UNIT CONFIG 中的 IOPS 相干设置即可实时失效。在租户外部，反对通过配置项 io_category_config 调配各类别 IO（业务申请、系统日志等）申请的百分比，进而细粒度管制 IO 资源分配与调度。
▋LOB 规格下限扩大
在 OceanBase 晚期的版本中，LOB 数据存储大小限度在 48MB 以内，这对客户应用 LOB 带来了强束缚限度。在本次架构降级中，通过存储层将 Lob 宏块的数据拆成多条 Lob Meta 进行存储，取数据的时候再将多条 Lob Meta 中的数据聚合成一个间断 Buffer 返回给 SQL 层解决，这样冲破了数据存储大小的限度，使得 LOB 存储下限扩大达到了 512MB，后续将继续优化到 TB 级别。
▋反对表锁和死锁检测
表锁容许业务以指定的形式锁定表或分区，防止业务并发操作造成数据毁坏。在 OceanBase 4.0 版本中反对了 Online DDL 操作，因而必须配套表锁爱护 DDL 与 DML 并发时的正确性问题。新增反对 LOCK TABLE 语法，反对 SHARE 和 EXCLUSIVE 两种锁定模式，同时反对对锁抵触的死锁检测。
▋扩大更多字符集
反对 UTF8、UTF16、GBK、GB18030 和 BINARY 字符集，新增反对 UTF8MB4_BIN、UTF16_BIN、GBK_BIN、GB18030_BIN、UTF8MB4_GENERAL_CI、UTF16_GENERAL_CI、GBK_CHINESE_CI 和 GB18030_CHINESE_CI 排序规定。
MySQL 兼容性加强
▋反对 DDL 语句的外键束缚
OceanBase 数据库默认开启外键束缚查看，外键束缚查看开关由租户变量 FOREIGN_KEY_CHECKS 来管制，要求束缚的列的值取自于另外一个表的主键列。在晚期的版本中，外键束缚查看仅对 DML 操作无效，DDL 操作不受影响。OceanBase 4.0 版本中反对了 FOREIGN_KEY_CHECKS 零碎变量对 DDL 局部的影响，其行为放弃与 MySQL 兼容。
▋反对视图列信息展现
在 MySQL 数据库中，视图列信息和表列信息一样，被作为根底的元信息被存储在数据字典中，并通过 INFORMATION_SCHEMA.COLUMNS 显示给用户。OceanBase 数据库外部仅对表列信息进行了长久化存储，4.0 版本通过采纳动静解析视图定义的办法，防止了对视图简单的依赖关系解析，实现在 INFORMATION_SCHEMA.COLUMNS 中展现视图列信息。
▋SQL Mode 扩大反对
扩大反对 MySQL 默认开启的 SQL Mode，新增反对 NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO 和 NO_AUTO_CREATE_USER 三个 SQL Mode，产品行为与 MySQL 兼容。针对 NO_ENGINE_SUBSTITUTION 仅反对语法兼容。
▋反对 SQL 文本中的预处理
反对 SQL 文本中的预处理语句（Prepared Statements），Prepared Statements 接口应用二进制协定相比交互式 SQL 接口具备更高的执行效率，应用办法大体如下：
PREPARE 筹备执行语句。PREPARE stmt1 FROM ‘SELECT SQRT(POW(?,2) + POW(?,2))’;
EXECUTE 执行筹备好的语句。SET @a = 3; SET @b = 4; EXECUTE stmt1 USING @a, @b;；
DEALLOCATE PREPARE 开释一个筹备好的语句。DEALLOCATE PREPARE stmt1;
▋反对自增列做为分区键
例如：
create table t2(inv_id bigint not null auto_increment ,c1 bigint, primary key (inv_id) ) partition by hash(inv_id) partitions 8;应用自增列作为分区键时须要额定留神，自增列的值全局惟一，但在分区内不保障始终增长，和原生 MySQL 行为不同。和其余分区形式相比，对这类分区表的插入操作性能会有肯定的降落。
▋反对 SEQUENCE 对象
扩大反对 SEQUENCE 对象，满足业务系统对 SEQUENCE 对象的依赖诉求，升高客户在业务迁徙过程中的适配复杂度。反对 CREATE/ALTER/DROP SEQUENCE 对象，反对获取 CURRVAL、NEXTVAL 和重置取值等对象操作，反对的对象取值范畴从 INT64_MIN 到 INT64_MAX。
▋反对存储程序
反对兼容 MySQL 5.7 语法的存储程序（蕴含存储过程和存储函数），反对游标、流程管制语句、异样解决、存储程序相干的 DDL 操作和视图和状态查问。同时扩大反对多个零碎包，例如 DBMS_STATS、DBMS_SESSION 等。
▋反对 DML 触发器
反对在表上创立触发器，兼容 MySQL 5.6 语法。当在该表上 DML 操作满足条件时、触发用户自定义行为。
▋反对更多函数
反对函数 ADDTIME()，将指定的工夫距离增加到给定的日期和工夫。例如：
SELECT ADDTIME('2007-12-31 23:59:59.999999', '1 1:1:1.000002');反对函数 DAYNAME()，返回给定日期的工作日名称。例如：
SELECT DAYNAME('2018-01-8');反对聚合函数 BIT_AND()/BIT_OR()/BIT_XOR()，返回表达式的按位与 / 或 / 异或的运算后果。
新增函数 UUID_SHORT()，返回 64-bit 无符号整数。例如：
SELECTUUID_SHORT();
运维能力晋升
▋反对全链路追踪
OceanBase 作为一款久经沙场的分布式数据库，其外部数据拜访的链路曾经非常复杂，当线上呈现超时等问题的时候，往往无奈无效疾速定位问题呈现的第一现场，须要依附有教训的运维人员对追个环节进行排查，验证影响到运维效率和故障影响速度。OceanBase 4.0 版本设计了一套全链路追踪的机制，可能晋升全链路问题定位的效率，贯通从业务 APP > 客户端驱动(JDBC, OCI) > 代理（OBProxy）> 数据库节点（OBServer）到全副流程，用户通过 PL/SQL 或 OBClient 接口在应用程序 APP 中设置相干标识信息（MODULE/ACTION/CLIENT_INFO/CLIENT_IDENTIFIER）到正在应用的链接中，运维人员能够通过 PL/SQL 程序包，管制相干应用程序设置的标识信息维度是否关上全链路跟踪诊断以及设置诊断输入策略；诊断日志以 OpenTracing 数据模型输入到 OBProxy 和 OBServer 日志文件中进行保留, 通过对诊断日志解析, 即可达到追踪每个 SQL 每个事务在全链路中执行耗时等相干诊断信息。
▋反对 SESSION 状态的监控和诊断（ASH）
OceanBase 数据库晚期版本曾经反对获取以后正在执行的 SQL 的状态信息，包含期待事件等信息，但只能通过 __all_virtual_session_wait 查问到 session 最近一次期待事件。OceanBase 4.0 版本反对更全面的 session 与期待事件之间的关系图（ASH），不仅蕴含以后执行的 SQL 的状态，还蕴含 SESSION、USER、SQL、WaitEvent 等多个维度状态历史信息。ASH 可能以 1s 为周期采样系统中所有 Active Session 状态，采纳过程中全程不加锁不影响业务 SQL 的失常执行。OCP 通过对这些状态采样信息进行综合汇总剖析，帮忙用户理解过来一段时间里零碎的负载以及期待状态，及时发现并预警问题。
▋反对实时执行打算监控
OceanBase 在 SQL 执行打算的诊断中引入了 SQL Plan Monitor, SQL Plan Monitor 提供了对于逻辑执行打算、物理执行打算、算子吐行数、算子开始 / 完结工夫点等信息, SQL Plan Monitor 信息只能在 SQL 执行结束后取得，能够通过 GV$SQL_PLAN_MONITOR 租户级视图获取相干信息。OceanBase 4.0 版本支实时 SQL Plan Monitor，能够实时的查看以后租户各 SQL 执行打算状态，在客户理论业务场景或者是诊断剖析场景, 如果存在 SQL 卡住的问题, 此时通过实时 SQL Plan Monitor 也能够查问各个执行线程执行算子的执行状态。
▋反对 Schema History 回收性能
解决 Schema History 只增不删导致 Schema History 过多，影响 OBServer 启动慢的问题。通过暗藏配置项 _schema_history_recycle_interval 管制 Schema History 回收周期，该配置项缺省值是 0，示意敞开 schema history 回收性能。
▋反对主动清空回收站性能
OceanBase 数据库回收站提供以租户为单位，当磁盘闲暇空间有余时，依照 FIFO 策略，主动清理回收站空间的性能。减少配置项 recyclebin_object_expire_time 用于指定回收站中对象的过期工夫。
写在最初
4.0 版本带来的不仅是降低成本，咱们心愿可能为用户提供一个面向未来的数据发动机，能够帮忙适宜分布式场景的大型用户，也能适宜单机场景的中小规模用户，以及可能会在将来某个霎时迎来业务爆发式增长的初创企业。通过社区版 4.0 版本的技术创新，包含小型化、小规格部署能力，更强的 OLTP 及 OLAP 性能，更好的易用性，可能帮忙用户反对在从小到大倒退的过程当中的每一个爆发性增长和每一次平滑缩容，更释怀、更平安的享受到数据处理的价值。
