共计 4653 个字符，预计需要花费 12 分钟才能阅读完成。
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 能力。
01、更高的性能，TPC-H 6 倍高性能晋升
Ⅰ. 硬核 HTAP 能力，OLTP 和 OLAP 性能大幅晋升
在 3.2 版本，OceanBase 数据库通过执行打算索引剪枝、缓冲区刷新算法、去除反复表达式、Table Scan 算子，多种算子的执行效率与内存耗费优化，极大晋升了 HTAP 负载能力。相比于 3.1 版本，3.2 版本在 OLTP 和 OLAP 性能上具备大幅度晋升，能够更轻松的应答海量数据和高并发的 OLTP 业务挑战以及实时剖析的 OLAP 业务与挑战，在 TPC-H 性能测试上晋升 655%，极大的晋升了 OLAP 能力。
Ⅱ. 反对小规格部署，性能晋升 30%
继续优化零碎外部模块级内存应用限度，冲破小规格限度，并反对在 8C64GB 小规格机器部署并稳固运行。性能层面，相比 3.1 版本整体晋升 30%。针对内存写入平滑性、零碎并发执行、零碎可用会话池、收发包内存等内存应用方面进行性能加强优化。进一步升高数据库对内存资源耗费。针对栈内存、Diagnose 内存、SQL 线程缓存、Close STMT 队列等模块内存方面进行重要技术升级，大幅晋升数据库对内存资源的利用率。
Ⅲ. 冲破分布式数据库事务限度，反对超大事务
分布式数据库系统内存 Memstore 中写入的数据量超过肯定限度时将 Memstore“解冻”并将数据 dump 到磁盘上，但解冻和转储过程 Memstore 中要求没有未提交的事务，因而会导致沉闷事务频繁搬迁以及租户内存爆的危险。OceanBase 通过转储未提交事务技术（租户级别的调度与解冻超出内存限度的沉闷未提交事务）以及 Paxos 即时写日志技术（对解冻事务生成 clog 进行 Paxos 同步），实现了分布式数据库对超大事务反对能力，更好地无效解决转储对事务状态的依赖。
Ⅳ. 内核能力优化晋升性能
强化内核能力，通过 Marker 去除反复的表达式，代替原有的 HashSet 以取得更好的性能；新增反对手工收集优化器统计信息，晋升手工调优能力；新增索引主动加密，晋升数据存储的安全性。
02、更高兼容性，升高业务迁徙革新老本
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 操作满足条件时，即可触发用户自定义行为。
客户原声：应用自增列作为分区键
某商业银行：智能收支业务测试中存在局部表将自增列做为主键，并通过自增列进行分库分表的设计，此前因为不反对自增列的分区表建设，只能通过复合形式实现，在齐全的迁移性或兼容性上是无奈齐全符合要求。反对自增列建设分区表后，满足需要的同时大大减少对业务的侵入。”
03、进步产品易用性，升高运维老本
OceanBase 数据库对数据库的易治理和易运维进行了针对性的晋升，针对很多罕用用户操作进行了简化，升高用户应用数据库的复杂度，晋升应用效率。
Ⅰ. 晋升自动化能力简化运维老本
反对 Schema History 回收性能和主动清空回收站性能，OceanBase 数据库回收站提供以租户为单位，当磁盘闲暇空间有余时，依照 FIFO 的策略，主动清理回收站空间的性能。反对用户通过配置项 _schema_history_recycle_interval 管制 Schema History 回收周期，通过配置项 recyclebin_object_expire_time 指定回收站中对象的过期工夫。提供主动巡检能力，能够依据内置巡检规定及零碎脚本对关怀的资源设定工夫进行查看并生成巡检报告。反对租户级别的最新状态物理复原，复原命令在缺省条件下复原到 CLOG 中记录的指标租户的最新状态简化用户操作。
客户原声：反对主动清空回收站性能
某商业银行：回收站作为运维人员的“定心丸”，能够作为误删数据、租户时的最初的屏障。但是否在运维过程中遇到在创立表时发现存储空间有余，而空间实际上被回收站中的对象大量占用的问题。这类问题可能须要耗费较长时间才可能排查进去。3.2 版本提供的回收站主动清理性能，提供以租户为单位，当磁盘闲暇空间有余时，依照 FIFO 的策略，主动清理回收站，并能够指定回收站中对象的过期工夫。
Ⅱ. 极大晋升性能及问题诊断监控能力
提供外部状态可视化能力，通过虚构表读取工作队列及内存工作状况；增强性能诊断报告能力，对集群的性能指标、参数和资源配置、负载进行剖析并生成诊断报告帮忙 DBA 进行性能诊断；提供 SQL 诊断调优个性，针对 SQL 进行衰弱状况诊断及性能问题排查，辨认可能会影响零碎稳定性的慢 SQL 及可疑 SQL，帮忙用户提前排查问题躲避危险。
04、外围场景稳定性更强，为业务护航
OceanBase 数据库在拜访连续性、数据一致性和事务执行等方面针对性晋升零碎的稳定性，为客户业务的连续性和正确性提供更无效的保障。新增全局死锁检测、本地路由表主动刷新、备机强一致性读、零碎异样状态侦测强化、集群网络流控优化能力。
Ⅰ. 新增全局死锁检测性能，及时处理死锁问题，保障事务执行稳定性
死锁是数据库十分常见的问题。呈现死锁时，须要 DBA 来监控或巡检发现，并人工进行解决；定位工夫和周期都比拟长。针对这一场景，OceanBase 数据库在 3.2 版本反对全局死锁检测性能。实现分布式死锁检测的关键在于, 如何汇总每个节点上的部分锁期待关系, 并基于汇总进去的全局锁期待关系产生全局的锁期待图 (wait-for graph), 找出图中成环(deadlock cycle) 的事务, 最初挑选出最优的事务作为牺牲者 (victim) 去解开死锁。
OceanBase 数据库采纳基于 Mitchell-Merritt 算法，使得分布式死锁检测在分布式数据库系统中的得以实现。目前死锁检测范畴已蕴含嵌套执行、存储过程、触发器、外键等，后续版本也会继续加强和欠缺全局死锁检测能力。
客户原声：全局死锁检测
某商业银行：在分布式数据库系统中，零碎可能经常出现死锁，过来只能用超时期待形式在零碎超时呈现时再解除死锁。依附 OceanBase 3.2 的最新全局死锁检测性能，零碎能够第一工夫检测到死锁，让死锁解除大幅减速。
Ⅱ. 反对超多分区，冲破个数规格限度，确保业务零碎稳定性
OceanBase 3.2 版本就分区级联计划、分区状态算法、心跳及日志传输等多个重要模块组件进行加强优化，实现数据库集群反对规模达到 50 万级别分区数量，帮忙用户在业务高速增长下保证系统稳定性。
Ⅲ. 优化集群网络流控，防止网络带宽耗尽带来的拜访故障
在数据库理论的业务场景中，当呈现大规模数据同步复制（比方故障数据迁徙、备份复原）时，很容易把网络带宽耗尽，从而影响失常业务拜访。OceanBase 数据库优化了集群网络流控，优化事务日志同步、迁徙、补正本、RRebuild 操作拷贝静态数据等场景下所须要的网络带宽资源应用，对网络流量进行更好的管制，通过规定和保底计划模式防止拜访故障的呈现。
05、强化管控能力，满足简单业务场景
Ⅰ. 反对公共云海内部署状态，助力客户寰球业务拓展
OceanBase 私有云在海内公布，在平安个性（SSL 加密、TDE 数据通明加密、VPC 隔离）满足海内平安合规需要的同时，通过数据存储压缩技术劣势，实现老本降落 30%、存储空间降落 90%。
Ⅱ. 反对多租户资源隔离，满足跨业务跨部门简单业务场景
大型简单的业务场景下，不同业务以及部门之间需实现权限及资源隔离，以防止因资源争抢等造成业务间相互影响。针对多租户场景，提供租户级的磁盘空间限度治理能力，通过自动化工作定期被动探测空间应用状况，超出时触发空间限额管理策略。反对租户级的快照备份复原，能够依据业务品种及重要水平指定备份策略，并反对自定义备份目的地。
OceanBase 数据库将继续围绕打造硬核原生分布式 HTAP 数据库，在兼容性、稳定性、混合负载 HTAP、通明扩大等方面进行继续晋升，把简单留给数据库、把简略留给客户，打造满足客户实在业务诉求和场景的硬核数据库。
