OceanBase 4.1 更新了哪些新功能？｜社区月报 2023.3

数据运维 2024-05-07 大白菜程序猿 手机阅读
我们每个月都会和大家展开一次社区进展的汇报沟通会，希望通过更多的互动交流让OceanBase 开源社区更加透明，实现信息共享，也希望能营造更加轻松的氛围，为大家答疑解惑，让大家畅所欲言。如果您对我们的社区有任何建议，欢迎在 GitHub 上提 Issues 或 PR ，也欢迎大家成为 Contributor，参与到社区建设中来。


OceanBase 4.1 更新了哪些新功能？｜社区月报 2023.3-1


2月的社区月报 和大家分享了 OceanBase 内核及生态工具的进展，那在3月份 OceanBase 又有哪些新进展呢？本文将介绍 4.1 版本带来的重要功能特性及用户价值，以及 OceanBase 社区未来3-6月份的规划。


OceanBase 4.1 功能解读

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


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


下面将会从以下五点和大家介绍 OceanBase 4.1 版本重要功能特性：

  • 易用性
  • 内核能力提升
  • 性能持续优化
  • MySQL 兼容性
  • 企业级高级特性


一、易上手✖️易使用✖️体验友好

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


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

为了让使用者更方便的部署和使用 OceanBase，我们重视每一个环节。在新版本中，我们推出全新的安装部署和运维管理解决方案。全新的向导式部署流程，通过图形化界面最大程度降低安装 OceanBase 的门槛。同时，一次部署就能获得数据库内核（OBServer）、代理服务（OBProxy）、管理工具（OCP Express）在内的完整产品服务。

OCP Express 是全新的轻量化设计改造后的 OCP，让用户以极低的资源成本完成便捷高效数据库运维管理工作，在满足数据库基础管理和数据库可观测性的同时，大幅降低了 OceanBase 数据库图形化管理的使用门槛。

OceanBase 4.1 更新了哪些新功能？｜社区月报 2023.3-2

旁路导入｜数据导入性能提升 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 这个资源组所设定的资源内。通过这样细粒度的控制策略，可以帮助到更多业务进行资源管控，保证业务整体运行得更平稳。