![]()
2021年10月22日云栖大会上，OceanBase CTO 杨传辉分享了《OceanBase 一体化架构助力核心系统》的主题演讲，并宣布 OceanBase 3.2 版本正式发布。
![]()
OceanBase 数据库作为一款企业级原生分布式关系型数据库，自创立以来一直坚持原生分布式的发展路线，其高兼容、金融级容灾和高可用、透明灵活扩展、超强稳定性等能力已经在金融、政府、运营商等各个行业得到了充分验证以及认可。今年 6 月 1 日，OceanBase 3.0 产品发布会宣布 OceanBase 数据库进入 3.0 时代，全力打造硬核的原生分布式 HTAP 数据库，打破边界，同时支持 OLTP 和 OLAP 负载。截止目前为止，OceanBase 3.0 已经在多家企业的核心业务系统得以应用。
OceanBase 3.2 是宣布进入3.0时代后的首个重大版本，持续在企业级能力构建上发力，围绕兼容性、HTAP混合负载、小规格性价比等几大核心能力，在Oracle/MySQL 兼容、易用性、稳定性、性能和功能等诸多方面持续迭代增强与优化升级，在提升用户体验的同时，帮助用户更轻松地完成应用迁移、TP 和 AP 统一部署、降低应用开发部署和运维成本。OceanBase 3.2在同等环境及任务的前提下，相比于3.1版本，Sysbench OLTP 性能提升24%，BMSQL tpmC 性能提升30%以上，TPC-H 性能提升655%，极大的提升了 OLAP 能力。
Ⅰ.硬核 HTAP 能力，OLTP 和 OLAP 性能大幅提升在 3.2 版本，OceanBase 数据库通过执行计划索引剪枝、缓冲区刷新算法、去除重复表达式、Table Scan 算子，多种算子的执行效率与内存消耗优化，极大提升了HTAP 负载能力。相比于3.1版本，3.2版本在 OLTP 和 OLAP 性能上具有大幅度提升，可以更轻松的应对海量数据和高并发的 OLTP 业务挑战以及实时分析的 OLAP 业务与挑战，在 TPC-H 性能测试上提升655%，极大的提升了 OLAP 能力。持续优化系统内部模块级内存使用限制，突破小规格限制，并支持在8C64GB 小规格机器部署并稳定运行。性能层面，相比3.1版本整体提升30%。针对内存写入平滑性、系统并发执行、系统可用会话池、收发包内存等内存使用方面进行性能增强优化。进一步降低数据库对内存资源消耗。针对栈内存、Diagnose 内存、SQL 线程缓存、Close STMT 队列等模块内存方面进行重要技术升级，大幅提升数据库对内存资源的利用率。分布式数据库系统内存 Memstore 中写入的数据量超过一定限制时将 Memstore “冻结”并将数据 dump 到磁盘上，但冻结和转储过程 Memstore 中要求没有未提交的事务，因此会导致活跃事务频繁搬迁以及租户内存爆的风险。OceanBase 通过转储未提交事务技术（租户级别的调度与冻结超出内存限制的活跃未提交事务）以及 Paxos 即时写日志技术（对冻结事务生成 clog 进行Paxos 同步），实现了分布式数据库对超大事务支持能力，更好地有效解决转储对事务状态的依赖。强化内核能力，通过 Marker 去除重复的表达式，替代原有的 HashSet 以获得更好的性能；新增支持手工收集优化器统计信息，提升手工调优能力；新增索引自动加密，提升数据存储的安全性。
OceanBase 数据库针对 Oracle 和 MySQL 模式，在功能、语法、函数、过程语言、系统包等方面均进行了兼容性增强，进一步降低业务迁移到 OceanBase 数据库的改造成本，以及用户使用 OceanBase 数据库的学习成本。Ⅰ.Oracle 兼容性，支持存储过程读写及定时器任务管理调度能力新增支持系统包 UTL_FILE，实现多系统间的数据交换、同步和整合，用户可以将数据库内的数据写成文件同步至下游系统使用，也可将其他系统生成的数据文件读入数据库做进行进一步处理，避免系统重构成本。新增支持定时器任务 DBMS_JOB ，可以轻松进行任务的管理和调度，实现定时任务、循环任务及异步任务等复杂业务场景下的自定义任务管理和调度，降低人力维护成本。
客户原声：UTL_FILE
某大型银行：上层十余个微服务应用均需要通过 UTL_FILE 与外部文件交互进行数据的载入和导出， 3.2版本支持的 UTL_FILE 功能，大幅提升兼容性并降低改造成本，提升研发人员操作外部文件的效率。
客户原声：定时器任务 DBMS_JOB
某保险公司：在保险业务跑批过程中，通过 DBMS_JOB 可以灵活定制定时作业，用于进行清理大表历史数据、财务明细计算和汇总等，大大简化了开发和运维。
某运营商：当数据库自身不能执行定时任务时，为了完成运营商的数据修复任务，只能通过应用修改或编写操作系统 Shell 脚本的方式实现，所有的定时任务无法统一管理和统一运维，长期使用会造成大量不可追溯源头的数据问题。3.2版本 OceanBase 提供了完全兼容 Oracle DBMS_JOB 的定时任务能力，可以用于安排和管理自定义任务，实现数据库定时任务的统一管理和维护。
Ⅱ.适配 MySQL 5.7 协议，MySQL 模式下支持自增列和 DML 触发器
适配支持 MySQL 5.7 驱动协议，支持 5.7 新增的会话变量，可以推高 OceanBase 的 MySQL 兼容版本，避免企业内部安全审计问题。新增支持自增列做为分区键，为数据的逻辑分离提供更好的灵活性。OceanBase 的 MySQL 模式并不支持 DML 触发器，导致需要触发器行为的场景下，客户需要自己写代码来实现数据和记录的约束，OceanBase 数据库在3.2版本在 MySQL 模式下支持 DML 触发器，用户可以在表上创建触发器，当在该表上的 DML 操作满足条件时，即可触发用户自定义行为。
客户原声：使用自增列作为分区键
某商业银行：智能收支业务测试中存在部分表将自增列做为主键，并通过自增列进行分库分表的设计，此前由于不支持自增列的分区表建立，只能通过复合方式完成，在完全的迁移性或兼容性上是无法完全符合要求。支持自增列建立分区表后，满足需求的同时大大减少对业务的侵入。
OceanBase 数据库对数据库的易管理和易运维进行了针对性的提升，针对很多常用用户操作进行了简化，降低用户使用数据库的复杂度，提升使用效率。支持 Schema History 回收功能和自动清空回收站功能，OceanBase 数据库回收站提供以租户为单位，当磁盘空闲空间不足时，按照 FIFO 的策略，自动清理回收站空间的功能。支持用户通过配置项 _schema_history_recycle_interval 控制Schema History 回收周期，通过配置项 recyclebin_object_expire_time 指定回收站中对象的过期时间。提供自动巡检能力，可以根据内置巡检规则及系统脚本对关心的资源设定时间进行检查并生成巡检报告。支持租户级别的最新状态物理恢复，恢复命令在缺省条件下恢复到 CLOG 中记录的目标租户的最新状态简化用户操作。
客户原声：支持自动清空回收站功能
某商业银行：回收站作为运维人员的“定心丸”，可以作为误删数据、租户时的最后的屏障。但是否在运维过程中遇到在创建表时发现存储空间不足，而空间实际上被回收站中的对象大量占用的问题。这类问题可能需要消耗较长时间才可能排查出来。3.2版本提供的回收站自动清理功能，提供以租户为单位，当磁盘空闲空间不足时，按照 FIFO 的策略，自动清理回收站，并可以指定回收站中对象的过期时间。
提供内部状态可视化能力，通过虚拟表读取任务队列及内存任务情况；加强性能诊断报告能力，对集群的性能指标、参数和资源配置、负载进行分析并生成诊断报告帮助 DBA 进行性能诊断；提供 SQL 诊断调优特性，针对 SQL 进行健康情况诊断及性能问题排查，识别可能会影响系统稳定性的慢 SQL 及可疑 SQL ，帮忙用户提早排查问题规避风险。
OceanBase 数据库在访问连续性、数据一致性和事务执行等方面针对性提升系统的稳定性，为客户业务的连续性和正确性提供更有效的保障。新增全局死锁检测、本地路由表自动刷新、备机强一致性读、系统异常状态侦测强化、集群网络流控优化能力。Ⅰ.新增全局死锁检测功能，及时处理死锁问题，保障事务执行稳定性死锁是数据库非常常见的问题。出现死锁时，需要 DBA 来监控或巡检发现，并人工进行处理；定位时间和周期都比较长。针对这一场景，OceanBase 数据库在3.2版本支持全局死锁检测功能。实现分布式死锁检测的关键在于, 如何汇总每个节点上的局部锁等待关系, 并基于汇总出来的全局锁等待关系产生全局的锁等待图(wait-for graph), 找出图中成环(deadlock cycle)的事务, 最后挑选出最优的事务作为牺牲者(victim)去解开死锁。OceanBase 数据库采用基于 Mitchell-Merritt 算法，使得分布式死锁检测在分布式数据库系统中的得以实现。目前死锁检测范围已包含嵌套执行、存储过程、触发器、外键等，后续版本也会持续增强和完善全局死锁检测能力。
客户原声：全局死锁检测
某商业银行：在分布式数据库系统中，系统可能经常出现死锁，过去只能用超时等待方式在系统超时出现时再解除死锁。依靠OceanBase 3.2的最新全局死锁检测功能，系统可以第一时间检测到死锁，让死锁解除大幅加速。
Ⅱ.支持超多分区，突破个数规格限制，确保业务系统稳定性OceanBase 3.2版本就分区级联方案、分区状态算法、心跳及日志传输等多个重要模块组件进行增强优化，实现数据库集群支持规模达到50万级别分区数量，帮助用户在业务高速增长下保证系统稳定性。Ⅲ.优化集群网络流控，避免网络带宽耗尽带来的访问故障在数据库实际的业务场景中，当出现大规模数据同步复制（比如故障数据迁移、备份恢复）时，很容易把网络带宽耗尽，从而影响正常业务访问。OceanBase 数据库优化了集群网络流控，优化事务日志同步、迁移、补副本、RRebuild 操作拷贝静态数据等场景下所需要的网络带宽资源使用，对网络流量进行更好的控制，通过规则和保底方案形式避免访问故障的出现。
OceanBase 公有云在海外发布，在安全特性（SSL 加密、TDE 数据透明加密、VPC 隔离）满足海外安全合规需求的同时，通过数据存储压缩技术优势，实现成本下降30%、 存储空间下降90%。Ⅱ.支持多租户资源隔离，满足跨业务跨部门复杂业务场景大型复杂的业务场景下，不同业务以及部门之间需实现权限及资源隔离，以避免因资源争抢等造成业务间互相影响。针对多租户场景，提供租户级的磁盘空间限制管理能力，通过自动化任务定期主动探测空间使用情况，超出时触发空间限额管理策略。支持租户级的快照备份恢复，可以根据业务种类及重要程度指定备份策略，并支持自定义备份目的地。OceanBase 数据库将持续围绕打造硬核原生分布式 HTAP 数据库，在兼容性、稳定性、混合负载 HTAP、透明扩展等方面进行持续提升，把复杂留给数据库、把简单留给客户，打造满足客户真实业务诉求和场景的硬核数据库。* 欢迎大家点击 “阅读原文” 查看 Release Notes，开启OceanBase 3.2探索之旅，如果您对3.2版本有任何问题及建议，欢迎前往社区问答区提问互动~附互动网址https://open.oceanbase.com/answer/detail?id=13700131