共计 6139 个字符，预计需要花费 16 分钟才能阅读完成。
作为企业级原生分布式数据库，OceanBase 自创建以来始终保持原生分布式的倒退路线，其高兼容、金融级容灾和高可用、通明扩大、稳固平安等能力曾经在金融、政府、运营商、互联网等各个行业失去了充沛验证以及认可。去年 6 月，OceanBase 公布定位为 HTAP 企业级数据库的里程碑 3.1 版本，反对不限大小的超大事务，引入向量化引擎、并行 DML、简单查问优化。3.2 版本在继续加强诊断监控能力、安全性、兼容性等企业级性能的根底上，进一步欠缺向量化引擎，以 1526 万 QphH@30000GB 的性能问题，发明 TPC-H 剖析型基准测试新的世界纪录，目前排名第二。
2022 年 4 月 18 日，OceanBase 3.2.3 正式公布 ，该版本是 3.x 的第一个 LTS（Long Term Support）版本，也是 HTAP 能力的里程碑版本。
性能亮点及用户价值
一、加强 HTAP 能力
全面实现向量化引擎，反对所有根底算子向量化，简单查问场景下带来数量级的性能飞跃，配合继续加强的优化器改写优化能力及大规模分布式并行执行引擎，使得该版本成为打造残缺 HTAP 能力的一个重要里程碑，TPC-H 性能相比 OceanBase 2.2.x 晋升 10 倍。
二、性能大幅晋升
优化 Nest Loop Join，性能晋升 1 倍。反对多表关联 SQL 语句转化为 Nest Loop Join 执行打算，通过算子优化大幅晋升多表关联性能。
晋升 Table API 流式扫描性能，OceanBase 3.2.3 流式扫描性能达到 HBase 2.4.6 的 2.2 倍。
晋升 CDC（OMS）数据传输性能，一个主键加一个非惟一键索引场景下全量迁徙工夫节俭 33%。经场景实测，在齐全不影响业务的状况下，全量迁徙速度可达到 38 万 RPS（64GB 内存、128 个并发）。
三、欠缺企业级性能
Oracle 模式新增 DBLink 性能，反对用户通过 DBLink 拜访 Oracle 的数据，满足用户 Oracle 迁徙到 OceanBase 后跨实例拜访远端数据库数据的需要。
MySQL 模式引入 Oracle 模式的 Sequence 性能，相比 MySQL 的自增列，Sequence 性能反对用户通过更加灵便的形式生成惟一序列值，并设置序列值生成形式，例如反对重设序列终点，反对循环取值，反对指定缓存大小等。值得一提是，该版本兼容了 MySQL 8.0 的 CTE（Common Table Expression）和 CHECK 查看束缚性能，反对用户通过 CTE 性能来模仿 Oracle 的 CONNECT BY 递归查问性能，提供 CHECK 束缚性能便于用户对数据进行合法性校验。
四、增强诊断监控能力
存储过程反对 GET DIAGNOSTICS 诊断，可应用该性能获取 SQL 语句或者存储过程执行时的错误信息, 帮忙用户疾速定位、排查解决问题。
OCP 引入 SQL 画像和事务画像性能，用户可通过 SQL 画像、事务画像获取 SQL 执行时的统计信息、每个算子的资源耗费，事务持有资源和期待状况以及分布式和并行执行状况，帮忙用户更快更准的定位 SQL 执行慢、事务卡住等问题。
五、加强企业级安全性
新增备份复原完整性校验性能，帮忙用户疾速发现磁盘静默故障，最大限度防止因备份数据损坏导致无奈用于应急复原的危险。
ODC 反对操作记录审计性能，自动记录所有的数据库变更操作，确保所有变更可审计、可回溯。
向量化引擎加强 HTAP 能力，简单查问性能再降级
打算编译执行和向量化引擎，是近十几年数据库学术界提出的两种重要执行优化思路。前者在工业界以 SingleStore（原 MemSQL ) 为代表进行了初步摸索。向量化引擎以 MonetDB/X100 零碎最早实际，因 Vectorwise 的大规模应用带来杰出的性能体现，让业内看到这项技术微小的性能价值和技术前景。尔后，包含 Oracle、SQL Server 别离通过 RowSets 等形式实现了向量化执行引擎能力。
OceanBase 3.2.3 版本全面实现了向量化引擎，从新设计执行引擎外围数据结构，以 Architecture-aware 的设计革新全副算子和最罕用的执行表达式，充沛挖掘古代 CPU 的 Cache 个性以及优化指令，并利用于 TPC-H 的 benchmark 中。向量化带来了大量的算法优化可能，通过在向量化的框架下进行算法和数据结构优化。相比非向量化执行引擎，实测整体执行性能性能晋升 5 倍，局部算子和单场景可实现 10 倍以上性能晋升。
向量化引擎能够在简单查问场景下实现数量级的性能飞跃，配合继续加强的优化器改写优化能力及大规模分布式并行执行引擎，使得 OceanBase 3.2.3 版本成为打造残缺 HTAP 能力的一个重要里程碑，TPC-H 性能相比 OceanBase 2.2.x 晋升 1 个数量级。
性能大幅优化，晋升典型业务场景的解决能力
Nest Loop Join 性能优化
Nest Loop Join 是多表关联、索引回表等 SQL 语句背地的根底算子，OceanBase 3.2.3 针对单分区表和多分区表进行了深度优化，相比 3.1.x 版本，无论是并发 QPS 还是单查问耗时方面，晋升均达到 1 倍左右。
场景一：50 并发测试 QPS，2 张表各 10 万行数据，查问 SQL 对 200 行数据进行关联。
场景二：单并发测试耗时（RT），右表有 16 个分区，每张表写入 100 万行数据，关联查问 20 万行数据。
晋升 Table API 流式扫描性能
在 Table API 程序扫描 OceanBase 的典型场景下，当扫描的数据量比拟大时，一次接口调用须要屡次客户端和服务端的交互能力获取残缺数据，这种扫描操作称为流式扫描。在整个交互过程中，服务端的事务以及迭代器状态等都须要持续保持。此前版本采纳同步期待实现形式，工作线程记录了申请的上下文，服务端须要放弃工作线程用于期待客户端发送下一个申请。在流式扫描并发量较大的状况下，可能会呈现服务端还有解决能力，然而所有的工作线程都在期待，无奈解决客户端申请的景象。
OceanBase 3.2.3 实现了异步化革新，将申请上下文与工作线程解耦。通过本次优化，流式扫描整体性能晋升 2 倍以上，达到 HBase 2.4.6 的 2.2 倍左右。
以下为模仿流式扫描测试场景，每次扫描波及 8 次客户端与服务端交互。经测试，OceanBase 的各版本以及 HBase 2.4.6 的最大吞吐比照如下：
晋升 CDC（OMS）数据传输性能
在理论的数据迁徙工作中，用户常常要面对表数据量较大的场景，当建表语句中蕴含索引创立时，整表的全量迁徙会因为实时保护索引造成效率低下，须要消耗很长的工夫能力实现迁徙。
为了解决此问题，OceanBase 3.2.3 通过 CDC（OMS）提供在全量数据加载实现后创立非惟一键索引的能力，借助 CDC 自身的调度能力，千万 / 亿级别的表整体迁徙工夫节俭 33%（测试环境单表具备一个主键和一个非惟一键索引状况下）。值得一提的是，单表非惟一索引越多的状况下，性能晋升越显著。经客户现场环境测试，OMS 在不影响业务的状况下全量迁徙速度能够达到 38 万 RPS（64GB 内存、128 个并发），帮忙用户轻松应答百 TB 级别的数据库的迁徙工作。
面向 B 端客户欠缺企业级性能，打造更好用的数据库
Oracle 模式：反对数据库链接到 Oracle（DBLink)
在企业理论业务中，Oracle 迁徙到 OceanBase 过程中用户通常会呈现数据曾经迁徙到 OceanBase，但还有少部分数据留在 Oracle 数据库的状况，须要通过相似 DBlink 的形式跨实例拜访远端数据库的数据。
为了更好地满足用户诉求，OceanBase 3.2.3 版本新增了 DBLink 性能，通过分布式数据库的跨数据源拜访的能力，帮忙用户以拜访本地数据库的形式拜访远端数据库，并且反对跨数据源的分布式事务能力。在 SQL 查问执行过程中采纳动静链接 OCI 驱动以只读的形式链接到 Oracle 数据库，通过将 Oracle 数据库的拜访操作内嵌到 OceanBase 的算子执行，大幅升高业务零碎多数据源拜访的设计复杂度。目前已反对 DBlink 到 Oracle 数据库的分布式读事务能力，分布式事务写能力将在后续版本继续迭代欠缺。
MySQL 模式：反对 Sequence 对象
作为 Oracle 业务零碎里被高频应用的数据库对象，Sequence（序列）能够依照肯定的规定主动生成惟一序列值，通过批改序列的属性，能够让这组值递增、递加、循环。
2018 年开始，OceanBase 提供 Oracle 模式下 Sequence 对象的反对。随着一些 DB2、Oracle 业务迁入 OceanBase MySQL 模式，OceanBase 3.2.3 在 MySQL 语法模式下正式引入了 Sequence 反对。绝对于自增列（auto_increment），用户能够对生成序列值的形式有更灵便的管制，如 Sequence 反对指定缓存大小、反对循环取值、反对重设终点等。
值得注意的是，Sequence 十分实用于对“递增”没有强需要，仅须要生成惟一值的场景。能够尝试在正当的前提下设置较大 Sequence 的缓存（例如 100 万），此时 Sequence 的取值将会在各个服务器实例的本地缓存实现以提供卓越性能。
MySQL 模式：兼容 8.0 的 CTE
Common Table Expressions（下文简称 CTE）是指在一条查问语句中能够定义一个长期后果集，或者能够了解为一个长期视图，该视图仅在这条查问中无效，能够被屡次援用。一条查问中能够定义多个长期视图，后定义的视图能够援用先定义的视图。
CTE 性能罕用于定义长期视图，这类视图个别存在以下几个特点：1) 不是通用视图，仅在这条查问中会被应用；2）有肯定复杂性或在查问中被屡次援用。除此之外，CTE 还经常被当成 CONNECT BY 嵌套查问的代替计划。CONNECT BY 是 Oracle 中一个罕用性能，在 MySQL 中并不反对。一个简略的 CONNECT BY 示例如下:
EMPLOYEE 表中记录了一个公司的员工信息，MANAGER_ID 示意每个员工的管理者的 ID。这条 CONNECT BY 语句展现了 ID 等于 1 的员工的所有间接和间接上司，能够将 CONNECT BY 的后果了解为树状构造，满足 START WITH 条件的数据是树的根节点，CONNECT BY 子句定义了父子结点间的关系，这个例子中要求父结点的 ID 和子结点的 MANAGER_ID 相等。LEVEL 示意结点的深度，即处于树中的第几层。
和上述 CONNECT BY 语句等价的 CTE 语句如下：
MySQL 模式：兼容 8.0 的 CHECK 束缚
数据库中 CHECK 束缚的作用是，通过一个布尔表达式限度表中某些列中可承受的值来保障表中数据的合法性。每次在表中插入或更新数据时，会对表中 CHECK 束缚的布尔表达式进行计算，如果新行的值在该表达式中计算的后果为 FALSE，则违反 CHECK 束缚，此时数据库会回绝新行的数据变更操作。
MySQL 在 8.0.16 版本之前，容许应用创立 CHECK 束缚的语句，然而语法解析时会疏忽 CHECK 束缚局部。从 8.0.16 版本开始反对了残缺的性能。
OceanBase 在 3.2.3 版本之前 MySQL 模式下容许应用创立 CHECK 束缚的语句，但和低版本 MySQL 相似仅被用来进行分区裁剪优化，不会让所创立的 CHECK 束缚真正失效。从 OceanBase 3.2.3 版本开始，反对残缺的 CHECK 性能，用户能够在 CREATE/ALTER/DROP TABLE 语句中创立、批改、销毁 CHECK 束缚。
加强诊断监控能力，让运维更简略
反对 GET DIAGNOSTICS 诊断
在应用 SQL 或者 PL 的过程中遇到谬误时，用户须要疾速诊断具体产生了什么谬误，以不便定位、排查和解决问题。OceanBase MySQL 模式实现了 Get Diagnostics 的性能，该性能用于获取错误信息，与诊断区域中的内容相干。Get Diagnostics 次要用于展现 SQL 命令执行之后产生的一些错误信息和其余的反馈信息。
SQL 画像和事务画像
大型企业零碎的 SQL 往往比较复杂，变动频繁，且可能因为运行中的数据变动或者数据库版本升级等因素变坏。因而，把业余的 SQL 诊断能力变成产品，对于 IO 密集的大型数据库系统尤为重要。OceanBase 通过 OCP 的 SQL 诊断模块，从诊断 - 优化倡议 - 调优应急角度，全面的监控分析线上的运行 SQL。首先，通过可疑 SQL,TOPSQL,SLOWSQL 和并行 SQL 模块发现有问题的或者须要优化的 SQL。其次，通过 SQL turning advisor 工具提出优化倡议，包含索引绑定举荐、最优索引创立举荐、历史执行打算举荐、SQL 限流举荐、租户 CPU 扩容举荐等；最初，执行调优应急操作，例如绑定举荐索引、疾速敞开存在问题的会话，对拜访的 SQL 进行限流等。
OceanBase 3.2.3 版本通过 OCP 引入 SQL 画像和事务诊断性能。其中，SQL 画像展现的信息包含：SQL 执行统计信息、资源耗费、算子 / 步骤的运行耗时、分布式查问、并行查问波及多节点的运行状况期待相干信息。除 SQL 画像展现 SQL 根本信息之外，OCP 还提供事务画像展现 SQL 所在事务持有的资源和工夫，以及该事务阻塞的其余事务状态（蕴含分布式事务）。用户能够通过 SQL 画像和事务画像剖析 SQL 事务耗时或者耗资源的具体起因，从而疾速定位 SQL 执行慢、事务卡住等问题的根因。
新增备份校验和变更操作审计，晋升数据库的安全性
备份文件完整性校验
数据备份和日志备份是晋升用户数据安全的重要辅助伎俩，当备份介质呈现磁盘静默谬误等故障时，通常会导致备份数据损坏无奈用于后续的应急复原。
新版本反对备份复原完整性校验性能，利用数据备份和日志归档文件中记录的校验和（checksum）来提前发现数据损坏的状况。该性能实现的难点在于须要充分利用 OceanBase 的分布式计算能力，将备份校验工作散发到所有 OBServer 工作节点。通过其内置的散布式调度能力，以分区组为粒度将校验工作批量发送给 OBServer，帮忙用户疾速发现磁盘静默谬误。用户能够通过 CDB_OB_BACKUP_VALIDATION_JOB_HISTORY 来查看本次数据校验的后果，如果呈现磁盘静默谬误，将会在 RESULT 字段上察看到相应的错误码。
变更操作审计
ODC 公共连贯只读权限用户被禁止执行数据库操作（DDL/DML），为保障数据库变更过程的平安，管理员可在 ODC 公共资源管控台工作流程内配置审批流，如定义危险等级数、抉择工作子类、指定变更的 SQL 数量范畴和设置审批节点等。管理员配置审批流后，被调配相干只读权限的用户可在工作核心创立模仿数据 / 导入 / 导出 / 数据库变更等工作，并在创立工作后依据所创立的工作类型来匹配对应的审批流程进行审批。OceanBase 3.2.3 版本引入变更操作审计性能，自动记录所有的数据库变更操作，真正做到所有变更可审计、可回溯。
OceanBase 3.2.3 作为 3.x 的 LTS 版本，是残缺 HTAP 能力的一个重要里程碑。该版本全面实现了向量化引擎，进一步晋升性能，欠缺诊断监控、安全性、兼容性等企业级性能。在版本研发过程中，OceanBase 借鉴了局部来自 Oracle 数据库的优良设计理念，联合 OceanBase 开源社区的用户反馈，在此向经典数据库的探索者和社区用户致以高尚的敬意。
