博客

OceanBase 4.1 发版 | 一个面向开发者的里程碑版本

  • Post author:
  • Post category:其他



欢迎访问 OceanBase 官网获取更多信息：https://www.oceanbase.com/

2022 年 8 月，OceanBase发布了 4.0 版本（小鱼），作为业内首个单机分布式一体化架构，兼顾了分布式架构的扩展性和集中式架构的性能优势，在同等硬件条件下实现单机性能赶超集中式数据库的同时，帮助用户极大地降低了分布式数据库的使用门槛。

2023 年 3 月 25 日，OceanBase 4.1 正式发布，这是一个面向开发者的里程碑版本。

4.1 版本在 4.0 基础上性能进一步提升，完善功能的同时增强稳定性，在内核能力上对分布式事务和存储进行了大量优化，同时我们也推出了很多对开发者非常重磅的功能，包括 GIS、JSON、增强 LOB、租户级主备库等。

经测试，OceanBase 4.1 相比 4.0 版本有很大的性能提升，小规格场景 sysnbench 综合读写能力相比 4.0版本性能提升40%，通过优化计划生成能力、支持更多的算子下压、增强查询改写，OLAP 的场景性能提升 15%以上。4.1 版本还实现了众多开发者群体期待的旁路导入功能，通过旁路导入，数据导入性能比 4.0 版本提升 6 倍。OceanBase 也在持续完善 MySQL 8.0 的兼容性，在新增内核兼容功能的同时还新增 MySQL Binlog 协议的支持，帮助用户更方便地把数据库接入到下游的 MySQL 生态。

本文将介绍 4.1 版本带来的重要功能特性及用户价值，包括以下五个重要部分：

  1. 易用性

  2. 内核能力提升

  3. 性能持续优化

  4. MySQL 兼容性

  5. 企业级高级特性



易上手 x 易使用 x 体验友好

自 OceanBase 4.0 发布以来，我们从一线用户处收到很多宝贵的产品改进建议，4.1 版本里的很多特性就来自于这些思想的碰撞，尤其是很多易用性优化和使用体验改进，目的就是让用户可以更高效使用 OceanBase 来解决实际的业务需求。



全新安装部署 最大程度降低安装 OceanBase的门槛

为了让使用者更方便的部署和使用 OceanBase，我们重视每一个环节。

在新版本中，我们推出全新的安装部署和运维管理解决方案。全新的向导式部署流程，通过图形化界面最大程度降低安装 OceanBase 的门槛。

同时，一次部署就能获得数据库内核（OBServer）、代理服务（OBProxy）、管理工具（OCP Express）在内的完整产品服务。OCP Express 是全新的轻量化设计改造后的 OCP，让用户以极低的资源成本完成便捷高效数据库运维管理工作，在满足数据库基础管理和数据库可观测性的同时，大幅降低了 OceanBase 数据库图形化管理的使用门槛。

img



旁路导入 数据导入性能提升 6 倍

当业务迁移到 OceanBase 时，首先面临的挑战就是把大量的数据迁移到 OceanBase 中，虽然 OMS 迁移服务让用户在迁移数据的操作上已经非常便捷，但耗时的全量数据迁移过程却很烦心。


在新版本中，旁路导入功能可以大大加速数据导入的速度。

OceanBase 通常的请求执行路径是为最通用的功能设计的，SQL 引擎、事务引擎、存储引擎需要为最全面的功能打造，在面对数据导入这种场景时不够高效。旁路导入功能让一张表格写入数据的流程绕过 SQL 引擎和事务引擎，直接按照存储引擎的格式生成持久化的数据，通过定制流程优化导入数据的效率。旁路导入功能的打开方式是在

INSERT

语句中加上

/*+ APPEND */

提示，或者在

LOAD DATA

语句中加上

/*+ DIRECT */

提示。

旁路导入功能是一个完备的功能，有很多让使用者贴心的使用体验。

旁路导入在表级别进行并发控制，正在执行旁路导入的表会与表上的其他修改事务互斥，保证数据的一致性。同一时间其他表上的操作不会受影响。

旁路导入功能还适配了备份恢复和物理备库功能，新写入的数据会实时归档，也会同步到备库。所以，旁路导入功能不仅可以用在新业务加载数据的场景，日常的数据操作和运维管理也可以使用，比如

INSERT INTO SELECT

语句加上

/*+ APPEND */

提示后也会通过旁路导入流程向目标表写数据，大幅提升执行速度。



在线统计信息收集 持续生成最优的执行计划

当一张表格突然新增大量数据时，统计信息不能准确反映实际的数据，可能导致用户后续请求生成不优的执行计划。OceanBase 中通常的统计信息更新是会每天由后台任务在用户设定时间开启，一般是在夜间。在线统计信息收集功能，让表格在突然写入了大量数据的过程中自动维护统计信息，确保及时生成最优的执行计划。新版本中，当用户执行

CREATE TABLE AS SELECT

、

INSERT INTO SELECT

、

LOAD DATA

等语句时，在请求执行的过程中，利用原本数据迭代流程，采用增量更新的方式，对统计信息进行更新。在线统计信息收集功能，不仅能够更及时的维护统计信息，而且相比显式调用统计信息收集更轻量、更快速。



租户级别物理备库 更符合实际业务的容灾部署方案

之前版本的 OceanBase 物理备库功能是集群级别的，同一个集群所有的租户必须同时是主库状态或者同时是备库状态。但是，使用 OceanBase 的用户会使用不同的租户来承载不同的业务，容灾的需求也就会以租户粒度有区别。新版本提供租户级别物理备库功能，让备库功能做到租户粒度，允许同一个集群中同时存在主库角色的租户和备库角色的租户，也就允许两个集群的不同租户互为主备，例如，A租户的主库在集群1、备在集群2，B租户的主库在集群2、备在集群1。通过更加灵活的方式，可以方便用户安排更符合实际业务的容灾部署方案。

同时，新的物理备库方案在内核层面做了全新设计，解除了对于集群运行状态的依赖，备库同步只依赖归档存储中的日志即可，即使主库不存在了，也可以基于备份数据和归档日志搭建出备库，所以，只要归档日志还在，用户也不用担心主库日志回收导致的备库同步的断流风险。



Index Skip Scan 提升索引数据的价值

数据库中的索引结构是用来加速业务查询的有力武器，通常来说，查询请求必须满足索引的一些条件才能用上索引，比如，查询请求的过滤条件指定了全部索引列，或者至少指定了索引列前缀。新版本中的 Index Skip Scan 功能允许一些新的查询场景也能用上索引，更大程度发挥索引数据的价值。举一个例子： 

CREATE TABLE ORDERS(USER_ID INT, ORDER_ID INT, STATUS CHAR(1), PRIMARY KEY(USER_ID, ORDER_ID));
SELECT * FROM ORDERS WHERE ORDER_ID = 2010;


ORDERS

表的主键索引是

USER_ID

和

ORDER_ID

的组合，那么当请求只指定

ORDER_ID

列查询时，按照通常的理解，主键索引没法起作用，只能执行全表数据扫描再按照

ORDER_ID = 2010

条件进行过滤。但是，如果实际表中用户数量特别少呢，最极端的情况整张表都是一个用户的订单，只有一个

USER_ID

值，那么拼上这个

USER_ID

和

ORDER_ID = 2010

的条件就能利用上主键索引了。如果有多个用户，也可以拼出来多个查询范围利用主键索引加速查询，只要用户的数量不多，就会比扫描全部数据再过滤要高效。当然，什么时候适合用 Index Skip Scan 是由表中的数据分布以及查询条件决定的，OceanBase 的优化器会根据代价决定是否使用 Index Skip Scan，自动选择最适合的查询方式。



基于用户场景的文档重构 从“有什么”到“解决什么问题”

一套好用的文档是很多开发者给我们提过的要求，在新版本中，我们对文档和文档中心做了全面的优化。


我们协同资深 DBA 一起梳理出了用户使用 OceanBase 数据库的核心链路和场景，将这些文档按照用户旅程来单独呈现，同时将用户按需检索类的文档作为参考信息单独呈现。

为了解决文档不好找的问题，我们在文档中心首页提供内容的引导，在产品文档首页提炼产品的核心场景并提供使用链路指导，让信息获取更加便捷。为了解决文档不好搜的问题，我们提供搜索结果筛选功能，可以通过选择想要的产品和版本来缩小搜索结果的范围。同时，新的搜索分层功能，可以搜整个官网的所有内容，也可以专注只搜索文档，还可以只搜索某个产品某个版本的文档。



内核能力提升



资源隔离 更细粒度的资源隔离控制能力

OceanBase 之前的版本已经支持了资源隔离功能，常见的用法是为 TP 和 AP 业务创建不同的 User，并分别绑定到不同的资源组上，即可实现 TP 和 AP 业务的资源隔离。不仅如此，资源隔离的需求广泛存在，例如，做平台化服务的 SaaS 企业会在其平台上服务大小不同的客户，大客户的数据量要远远多于小客户，SaaS 企业需要尽可能隔离大客户的请求，避免其耗尽所有资源而影响到众多其他客户。

4.1 版本提供了更细粒度的资源隔离控制能力，允许对同一张表的不同数据指定分别的资源组。

以下面的用法为例： 

DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
   attribute        : COLUMN 
   value            : "Order.Check.UID = 3"
   consumer_group   : "resource_group_for_big");

如上设置后，

Order

库的

Check

表上访问

UID = 3

的请求，都会被限制在

resource_group_for_big

这个资源组所设定的资源内。通过这样细粒度的控制策略，可以帮助到更多业务进行资源管控，保证业务整体运行得更平稳。



故障恢复能力升级 更多场景达成 RTO < 8 秒

OceanBase 4.0 版本在业界首次提出机器宕机时数据库的恢复时间小于 8 秒的能力，即 RTO < 8 秒。在数据库的实际运行环境中，出现的异常情况不仅是机器宕机，还会出现网络中断、IO 异常甚至是数据库进程被中断等。另外，出现异常的也不一定是数据库机器，还有可能是路由层 OBProxy 所在服务器。异常情况的处理不仅要考虑通常 TP 业务的并发事务执行场景，也要考虑执行 DDL、数据加载等运维场景。


新版本中，我们继续完善了故障恢复能力。

以用户实际遇到的多种类的异常问题作为优化目标，打磨每个模块处理异常的细节，让上述提到的各种异常情况发生时，数据库的服务都能在 8 秒内恢复，给业务提供更强的持续可用能力。



存储空间占用优化 进一步提升存储利用效率

在 OceanBase 中，对于一张单分区表或者分区表中的一个分区，只要其中有用户存入的数据，其都会在硬盘上至少占用一个宏块，即使只存储一行数据，也要占据整个宏块。宏块是 OceanBase 硬盘管理的基本单位，大小为2MB。这就造成一些场景存储空间利用不高效的问题，典型的场景是业务建了大量的表，每张表都存了少量数据，结果就会导致总数据量没多大却占用了大量存储空间。实际上，这些占用的宏块内部实际存储的数据很少，但也无法再存储其他表格的数据了。

新的存储优化方案就是为了解决这种场景的问题，

在新版本中，系统会自动追踪宏块的使用情况，并允许多张表的数据可以复用同一个宏块。

并且，当系统长时间运行，因为表格的陆续删除，宏块出现大块剩余空间时，还会自动进行碎片整理，释放出更多的宏块空间，进一步提升存储利用效率。在上述典型的表格数据量很小的场景下，新版本可以将存储空间利用率提升 1 至 2 个数量级。



空间信息系统（GIS） 更好的支持位置查询、空间分析等业务场景

空间信息系统（GIS） 提供了对空间对象（点、线、面以及复杂的空间对象）的原生存储能力，以及空间关系计算、空间索引能力和常用的空间函数。例如，出行软件搜寻用户周边的车辆，就是利用了空间索引和空间关系计算，快速的在大量车辆中找到离用户最近的车辆信息。在新版本中，OceanBase 支持了这些功能，能够高效的完成空间数据存储与高性能计算。未来，时空轨迹相似度计算、空间对象相对位置计算、邻近计算等空间信息系统相关的业务场景都可以基于 OceanBase 更快速的构建。



全新的通用 LOB 更少资源更高并发

OceanBase 4.0 在 MySQL 模式下支持了存储 512MB 的 LOB。在 4.1 版本中，OceanBase 继续优化 LOB 类型的操作，在访问 LOB 的全链路上支持了 LOB 的延迟加载，解决了 LOB 查询对内存的依赖，可以用更少的资源更高并发处理 LOB 类型。同时，新版本还支持了 LOB 类型的增量操作能力，优化了 LOB 更新对日志以及存储子系统的写放大问题，提升了 LOB 类型的更新效率。



性能提升

持续的性能优化，提升 OceanBase 的产品竞争力和性价比，是整个 OceanBase 研发团队孜孜不倦的追求。

我们从实际用户的使用中也收到很多反馈，并将最常遇到的性能问题作为版本迭代的重点。

下面的“并行 Truncate Table”优化和“事务内路由优化”是两种业务场景下的优化工作，“ TP 性能”和“ AP 性能”是新版本针对 TP 和 AP 两种业务场景的通用性能提升。



并行 Truncate Table 让跑批业务场景更加高效

OceanBase 是一个分布式数据库，Schema 变更需要在集群级别进行串行调度。很多客户的跑批业务场景有可能出现多个并发同时执行 Truncate Table 的操作，之前的版本只能在集群级别串行执行，效率不够好。新版本对于 Truncate Table 进行了专门优化，允许不同表的 Truncate Table 语句并行执行，可以在上述跑批业务场景中让执行效率提升一个数量级。OceanBase 在优化执行效率的同时，依然保证了严格的并发控制，同一张表的并发Truncate Table 会串行执行，另外，如果表上正在执行修改事务，Truncate Table 语句也会等待事务结束才会执行，确保了 Truncate Table 严格的并发控制行为。



事务内路由优化 大幅降低事务整体执行延迟

OBProxy 是 OceanBase 的路由层，其可以将请求发送到最适合的 OBServer 节点进行处理，通常是一条语句所要处理的数据所在节点。这种路由能力可以优化 SQL 执行延迟。但是，之前的 OceanBase 会限制一个事务内的多条语句都必须首先路由到同一台 OBServer，对于多语句的事务，只有事务内的第一条语句能按照数据位置进行路由，事务内后续的语句无法按照其本身访问的数据进行路由。新版本中，OceanBase 对于事务状态进行了重新设计，允许事务内的多条语句自由路由，让 OBProxy 可以把语句发送到数据所在节点，让语句执行的更快。这个优化对于 TP 业务分布式事务较多的场景，有非常大的优化效果，能够大幅降低整个事务的整体执行延迟。



TP性能 小规格场景性能提升 40%

OceanBase在 4.0 版本中，基于单机分布式一体化架构已经打造了单机能力可以超越单机 MySQL 的系统。在新版本中，我们持续对更多场景进行优化，sysbench 压测的各种压测模型和 benchmarksql 压测模型都有显著的性能提升，尤其在小规格硬件环境中，性能提升比例更大，4核小规格部署环境，sysnbench综合读写能力相比4.0提升40%。



AP性能 OLAP场景提升 15%

在持续提升 TP 能力的同时，OceanBase 每个版本也在不断加强 AP 能力。在新版本中，我们优化了计划生成能力，允许更多的算子下压操作，同时也增强了查询改写，支持了更多场景的改写优化，还引入了更多的自适应执行能力。新版本的 TPC-H 100G场景性能比4.0提升17%，TPC-DS 100G 场景性能比4.0提升15%。



兼容性



MySQL 8.0 更全面的兼容能力

OceanBase 的 MySQL 兼容模式已经对 MySQL 5.7 进行了全方位的兼容，但是我们也逐渐发现了一些用户使用了 MySQL 8.0 的新功能，为了让这些用户更平顺的迁移到 OceanBase 上，在新版本中，我们开始在 MySQL 兼容模式中逐步引入 MySQL 8.0 的新功能。

4.1 版本里新增了针对 MySQL 8.0 的多个兼容性升级：

  1. 新增多种 SQL mode 的支持，包括

    REAL_AS_FLOAT

    ,

    POSTGRESQL

    ,

    NO_DIR_IN_CREATE

    等13个
  2. 新增支持十多个函数，包括

    BIN_TO_UUID

    ,

    CURRENT_ROLE

    ,

    IS_UUID

    等
  3. 触发器功能中

    CREATE TRIGGER

    语句支持

    PRECEDES

    /

    FOLLOWS

    子句定义触发顺序
  4. 公共表达式功能（CTE）支持

    WITH ... UPDATE ...

    和

    WITH ... DELETE ...

    用法
  5. 进一步完善

    INFORMATION_SCHEMA

    的兼容表现



MySQL Binlog Service 更方便接入下游数据生态

MySQL 拥有非常好的生态，基于 Binlog 逻辑复制能力做出了一些比较成熟的增量解析系统并被广泛使用在数据集成中，很多使用 OceanBase MySQL 兼容模式的用户希望复用 MySQL 生态中的这些成熟工具，让这些工具可以直接消费 OceanBase 产生的增量日志。在新版本中，Binlog Service 可以将 OceanBase 的日志转换成 MySQL Binlog 格式，并且提供了全面兼容 Binlog 协议的能力，当用户将 MySQL 替换为 OceanBase 时，可以继续复用 MySQL 的增量日志解析工具。



企业级高级特性



基于仲裁的高可用 更强的服务连续性和数据可靠性

OceanBase 之前的版本为两地三中心机房环境提供了五副本的部署方案，即主城市的两中心各放置两副本，灾备城市放置一副本。这种部署方案以 Paxos 一致性协议为基础，当主城市中任意一个中心故障时，只损失两副本，剩余的三副本可以继续提供数据库服务，其服务连续性和数据可靠性保证超越传统数据库的主备库模式。但这个方案带来服务连续性优势的同时，对于两个城市跨城市网络带宽提出了要求，要求必须保证所有新生成的增量日志要实时传输不能落后。


在新版本中，我们升级了对于两地三中心机房的支持。基于仲裁的高可用部署方案在主城市的两中心依然各放置两副本，在灾备城市放置仲裁服务，仲裁服务自身不存储数据。

集群正常工作时，主城市的四副本依然以 Paxos 一致性协议为基础进行事务日志的高可用同步，仲裁服务会实时维护与主城市四副本之间的活性检测。当主城市任一中心故障时，仲裁服务会介入管理让另一个状态正常的中心恢复数据库的服务。基于仲裁的高可用方案在大幅度减少对于跨城网络带宽的依赖同时，依然保证了在主城市单个中心故障时服务连续性和数据可靠性，能力与之前的五副本方式一致，是最理想的两地三中心的数据库部署方案。



Oracle 兼容性



Database Link支持写事务

OceanBase 之前的版本已经支持了 OceanBase 到 Oracle 数据库的 Database Link 功能，但是只能提供只读操作。新版本中，以 XA 事务能力为基础，在 Database Link 上支持了跨 OceanBase 和 Oracle 的写事务能力，也支持 OceanBase 到 OceanBase 的写事务能力。更强的 Database Link 功能的支持可以协助实际业务替换数据库过程中做得更平滑，改动更小。



JSON

JSON 是如今非常常用的一种数据格式，学习成本低、表达能力强，被用在各种系统和处理流程中。OceanBase 在 MySQL 兼容模式已经支持了 JSON 类型的基础上，在新版本中，添加了 Oracle 兼容模式中对于 JSON 类型的支持，完善了 OceanBase 的数据多模型能力。除了 JSON 类型的存储与查询，还支持了 Oracle 关于 JSON 新增的大部分函数如

JSON_OBJECT

、

JSON_EQUAL

等，方便在 Oracle 兼容模式中对 JSON 类型进行处理。



DBMS_LOB 包

Oracle 兼容模式下也具备了上文提到的全新的通用 LOB 能力，解决了大 LOB 操作对内存的依赖。同时，新版本还在 Oracle 兼容模式中支持了 DBMS_LOB 包，向用户提供对 LOB 的增量修改以及部分查询的能力，也进一步放宽了 LOB 大小的限制，能够支持 TB 级别大小的 LOB。



写在最后

自 OceanBase 4.0 发布以来，得益于大量用户真实场景的快速反馈和众多开发者的共同打磨共建，4.1 版本功能和稳定性获得更进一步的升级，也成为我们推荐给企业级用户的第一个 4.x 系列版本。

非常感谢用户和开发者们在 OceanBase 4.1 版本中所做出的贡献。感谢大家一如既往地支持，帮助 OceanBase 在实际场景中持续提升开发者和 DBA 的使用体验，使 OceanBase 变得更加简单易用。在未来的版本中，我们将一如既往地聆听用户和开发者的声音，与开发者共同打造真正能够满足需要并让用户喜爱的分布式数据库。


欢迎大家点击下方链接查看 Release Notes，开启 OceanBase 4.1 探索之旅


https://www.oceanbase.com/product/oceanbase-database-rn/releaseNote#V4.1.0


版权声明：本文为OceanBaseGFBK原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。