关键字：T+0 混合负载 | 分布式执行框架 | 多模场景支持
HTAP 混合事务与实时分析处理是行业强诉求，OceanBase 基于分布式架构做好交易处理场景的同时，能够完成分析、跑批等分析性场景，一套引擎支持 OLAP + OLTP 工作负载，同时实现两套系统功能，真正通过“一个系统”提供同时处理交易及实时分析，“一份数据”用于不同的工作负载，从根本上保持数据的一致性并最大程度降低数据冗余，帮助企业大幅降低成本。
场景
企业级应用的业务场景通常可以分为两个类别：联机交易和实时分析，我们通常称为 OLTP 和 OLAP 的业务应用。
大型企业往往会选择多款数据库产品分别支持 OLTP 和 OLAP 类的应用场景。这种组合式的解决方案需要数据在不同系统间进行流转，数据同步的过程会带来时间延迟和数据不一致的风险；同时，多套不同的系统也会产生冗余数据，增加存储成本。
解决方案
行业现状与挑战
- 离线数仓实时性差：离线数仓往往仅能提供 T+1 的数据能力，数据更新能力较弱，导致在线业务团队的实时分析、会员营销等需求无法及时满足。而单独建设实时数仓对中小企业又相对复杂，还需要投入额外人力成本维护数据同步链路。
- HTAP 隔离性差：HTAP 的核心在于一套引擎支持多种负载，而资源的隔离性如果无法得到保障，承担关键交易的数据库一旦被分析型、批处理类的业务影响，往往直接导致在线交易下跌，业务严重受损。
- 传统主备能力单一 ：依靠主备复制的读写分离方案，备节点仅能处理只读查询，无法进行批处理操作 ；数据实时性也强依赖同步延迟，当遇到大型事务/DDL 时无法保证实时一致性。再加上本身能力有限的 SQL 优化器，无法灵活支持跨分片的多表复杂分析。
方案描述
- 通过 OMS 将异构数据库分库分表同步至 OceanBase 原生分区表（多表汇聚同步）。
- 迁移至 OceanBase 后多个实例融合为一个实例，摆脱维护中间件的苦恼，大幅提升存储可扩展性。
- OceanBase 的 HTAP 模式，满足了业务上分析查询的业务得以前置，无需等待 T+1 数据，直接于在线库实现实时营销决策等分析需求 。
方案优势
- 强大的数据更新能力：基于关系型数据库的更新能力，副本间毫秒级极低延迟。
- HTAP 一体化：一套引擎处理 OLTP 和基本的 OLAP 场景，同时基于资源组隔离技术，提供 OLTP/OLAP 业务资源隔离的可靠方案，免去复杂的实时数仓建设。
- 分布式并行计算引擎：强大的 SQL 优化器和执行器，支持向量化计算和海量数据的并行计算分析。
- 多模场景支持：完全兼容 MySQL 语法 , 同时支持 HBase 和 Table 模型 API ，并且支持 JSON 半结构化数据格式和场景。强大的 CDC 能力支持，方便多种类型的下游进行数据消费。
- 灵活的动态扩容：单集群最大可超过上千节点，数据容量超过 PB 级。
OceanBase 通过 Flink CDC 组件作为流处理引擎，同时以 OceanBase 的 PL/SQL + Job Package 实现批处理任务，完成数据集成以及数据建模的流批一体处理。同时通过向量引擎 + 多副本架构，实现数据与业务的协同以及时效性的保障。
OceanBase HTAP 关键技术介绍
读写分离策略
数据库的读写分离策略是一种将数据库的查询操作和写入操作分离的方案，目的是降低读写操作的相互影响并提升资源利用率。在 HTAP 数据库中，读写分离的应用场景非常普及，只读的业务场景主要包括 BI 查询业务、大数据 ETL 取数、缓存的拉取等。两种类型的业务同时跑在一套数据库集群上，这对数据库的配置等要求就相对较高，因此我们一般会采用读写分离的方式，将一部分的读请求，路由到 Follower 副本上，从而降低复杂分析计算对资源的侵占，影响在线业务的响应延迟。
OceanBase 数据库天然支持读写分离的功能，即通过 OBProxy 代理服务和修改 OBServer 的配置即可实现业务的读写分离策略。
OceanBase 数据库在读取数据时，提供了两种一致性级别：强一致性和弱一致性。强一致性是指请求路由给主副本读取最新数据；弱一致性是指请求优先路由给备副本，不要求读取最新数据。
OceanBase 通过应用侧为执行的 SQL 添加 SQL Hint 来显性开启弱一致性读就可以实现基于注释的读写分离功能，同时也衍生出如下三种常用的读写分离策略，用户还可以根据实际情况，对读写分离策略进行灵活的配置：
备优先读
- 默认情况下，强一致性读以及增删改的 SQL，会访问 Leader 副本。
- 可以通过修改 OBproxy 的路由策略为 follower_first ，将业务读流量指定到该 OBProxy 从而保证读请求优先访问 follower 副本，对应 OBProxy 默认会将请求路由到本地 Follower 副本。如果本地该数据的副本为 Leader 副本，则会自动路由到同 Region 中其他 IDC 的 Follower 副本。
优点：配置相对简单，只修改 OBProxy 配置，无需修改 OBserver 配置；读流量均摊到全部 follower 副本上。
缺点：如果本地副本是 Leader 副本，读请求则会跨 IDC（zone） 访问；在不调整副本 leader 的情况下，同 zone 或同 server 下不同副本的 leader 和 follower 可能共存，不能完全实现 zone 级别或者 server 级别的读写隔离。
只读 zone
路由策略：
- 设置 Primary Zone为 zone1,zone2;zone3，注意这里 zone1 和 zone2 之间是逗号，zone2 和 zone3 之间是分号，表示 zone1 和 zone2 会被设置为 primary zone，因此所有的 Leader 副本都被迁移到了 zone1 和 zone2 中，zone3 默认情况下都为 Follower 副本，那么 zone3 的副本就可以只给弱一致性读的分析计算类SQL提供服务。
- 需要弱一致性读的 SQL，连接设置了弱读的 OBProxy；其余 SQL 连接正常 OBProxy。
- 通过连接弱读的 OBProxy 的所有 SQL，会基于 LDC 路由策略，以及 FOLLOWER_FIRST 策略，自动访问本地的 Follower 副本。
优点：通过设置只读 zone 实现了 zone 级别隔离读写请求，隔离性相比备优先读的方案更高。
缺点：需要人工设置 Primary Zone，写流量会被集中打到 zone1 和 zone2。
适用场景：读写比较均衡，存在少量分析的场景。
只读副本
OceanBase 中除了默认的全功能性副本之外，还有一种只读型副本，只读型副本的名称为 READONLY，简称 R，区别于全功能副本，只读副本提供读的能力，不提供写的能力，只能作为日志流的 Follower 副本，不参与选举及日志的投票，不能当选为日志流的 Leader 副本。利用只读副本，我们就可以专门再配置一个zone，只放只读型副本，专门提供给OLAP分析计算类请求，并且只读副本出现故障，并不会影响主集群服务。
路由策略：
- 主集群正常提供服务。
- AP 类请求走独立的OBProxy，访问只读型副本。
优点：OLAP 与 OLTP 的请求可以做到完全隔离，互相不受任何影响。
缺点：需要为只读型副本提供更多资源。
适用场景：业务读请求远大于写请求，且大部分读请求对实时性要求不高，或者有大量的 AP 分析场景。
资源隔离能力
资源隔离并不是一个新概念，传统方式下不共享物理资源，可以理解为物理资源隔离方案。这种方案下不同租户或同一租户内 OLAP 和 OLTP 使用不同的副本，只读副本服务 OLAP，全功能副本服务 OLTP，两种业务不共享物理资源。如果不考虑成本，物理资源隔离无疑是更好的选择。
但现实中，大部分客户都会考虑硬件成本及其资源利用率。一方面，数据库硬件的购买和维护成本高昂，而所有硬件都需要定期换新；另一方面，数据库硬件在进行单项业务处理时，平均占用率水平较低。如果不能充分利用硬件资源，无疑会造成巨大的资源浪费。
而要充分利用硬件资源，不同租户或同一租户内 OLAP 和 OLTP 共享物理资源的逻辑资源隔离方案，自然脱颖而出。实际上，物理资源隔离和逻辑资源隔离不是二选一，而是互为补充的关系。理想的资源隔离方案是在完全物理隔离和逻辑隔离中找到平衡点，OceanBase 会给用户更多自由，帮助用户在面对各类场景下都可以做出最合适的选择。
资源隔离的种类
资源按照使用情况有刚性和弹性的区别，资源隔离的对象通常是弹性资源。刚性资源是保障程序完成功能必须的资源，一旦被占用，短时间内也难以释放。刚性资源的典型是磁盘空间和内存空间，连接数等，这类资源做好静态规划后，每个组可以使用的资源数量就会固定下来。弹性资源是指和程序功能无关，但是和 性能有关的资源，比如 IOPS、CPU 时间、网络带宽等，这类资源一般可以抢占或被迅速释放，因此资源调度策略可以介入，实现闲时共享，忙时隔离。刚性资源比较重要的是内存和磁盘空间，弹性资源比较重要的是 CPU 时间，IOPS 和网络带宽，OceanBase 对以上资源均支持资源隔离。
除此以外，OceanBase 也提供了 SQL 级的资源隔离。通常适用的场景是，业务中存在多个账号，处理一个账号的一个订单时，会开启一个事务，然后执行一批与该账号相关的 SQL （通常是在 WHERE 条件中指定账号的值）。账号中同时存在大账号（数据量较大）和小账号（数据量较小），为了避免大账号把 CPU 资源用完导致小账号的订单无法得到处理，可以将处理不同订单的 SQL 绑定到不同的资源组，绑定后不同订单的 SQL 就会使用不同资源组的资源。
配置资源隔离的步骤
在 OceanBase 中进行 HTAP 资源隔离分为以下两个步骤：
- 定义资源组以及资源组的 QoS，对数据库来说租户就是最常见的资源组，另外 AP 和 TP 也可以是两个不同的资源组。
- 按定义好的 QoS 制定实施资源隔离的策略。
定义资源组
OceanBase 通过 unit config 描述租户的资源要求，比如创建一个租户之前要创建 resource pool（资源池） 、resource pool 的规格描述里就指定了各种资源的限制，详见：《租户的资源管理》。
create resource unit box1
max_cpu 4, max_memory 21474836480, max_iops 128, max_disk_size '5G',
max_session_num 64, min_cpu=4, min_memory=21474836480, min_iops=128;
制定 OLTP 和 OLAP 资源规划
怎样管理租户内 OLTP 和 OLAP 的资源使用计划？OceanBase 参考了 Oracle 经典的 Resource Manager 系统包提供的管理接口。我们观察到，很多客户的跑批业务会安排在业务低峰期，如午夜或者凌晨，此时不用过于担心 OLAP 会影响到 OLTP 类业务，我们可以把集群绝大部分资源分配给 OLAP 类业务，给 OLTP 留下最小资源保证即可。在白天的业务高峰期，通过调整资源隔离方案，可以确保 OLTP 业务资源充足，同时按照预设资源满足基本的 AP 类查询 。在 OceanBase 里，我们只需要预设两套资源管理计划，白天激活 DAYTIME 计划，夜间激活 NIGHT 计划，就可以实现满足基本的隔离需求的同时实现资源利用率的最大化。
比如我们可以通过 DBMS_RESOURCE_MANAGER 系统包来定义一个白天资源使用计划（resource plan)，并且制定了此计划下 OLTP (interactive_group）和 OLAP (batch_group) 的资源百分比。80% 的资源用于 TP，剩下 20% 资源用于 AP。
// 定义 DAYTIME 资源使用计划
DBMS_RESOURCE_MANAGER.CREATE_PLAN(
PLAN => 'DAYTIME',
COMMENT => 'More resources for OLTP applications');
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN => 'DAYTIME',
GROUP_OR_SUBPLAN => 'interactive_group',
COMMENT => 'OLTP group',
MGMT_P1 => 80,
UTILIZATION_LIMIT => 100);
DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE (
PLAN => 'DAYTIME',
GROUP_OR_SUBPLAN => 'batch_group',
COMMENT => 'OLAP group',
MGMT_P1 => 20,
UTILIZATION_LIMIT => 20);
// 激活 DAYTIME 资源使用计划
ALTER SYSTEM SET RESOURCE_MANAGER_PLAN = 'DAYTIME';
按照类似的方式，我们可以定义夜晚的资源使用计划，并在业务低峰期激活它。假设这个业务白天的时候 TP 负载高，AP 集中在晚上。因此我们为白天和晚上设置两个不同的资源使用计划，白天的时候我们希望 80% 的资源用于 TP，剩下 20% 资源用于 AP，夜晚的时候希望 50% 的资源用于 TP，剩下 50% 资源用于 TP。
我们按照上面的描述进行从白天计划切换到夜晚计划的测试。从下图可以看出，切换为夜晚计划后，AP 的 CPU 资源占比变大后，AP 的 QPS 明显变高，而 TP 的 QPS 则会降低。下图中 AP 和 TP 的 QPS 发生变化的点（15:32:30）就是切换资源使用计划的时间。
看起来 TP 的 QPS 降低比较少，和 AP 的 QPS 变化比起来不明显。这里要注意，按理想情况来算，TP 的 QPS 变化本来就要比 AP 的变化小，因为 AP 是从 0.3 到 0.5，增加了 66.7%, TP 从 0.7 到 0.5，降了 28.5%。我们算一下，TP 下降了 24.7%(19000 到 14300)，和理论上的数值实际差距并不大。
配置 QoS 的资源隔离语义 min/max/weight
QoS（Quality of Service，服务质量）作为一种安全机制，可以在资源过载时保障关键进程的平稳运行。以下我们通过权重分配、资源上限和保留资源来描述 QoS。在不同的时间段，业务的流量会有波动，所以 QoS 描述需要有一定的弹性，如果像公有云上的 ECS 一样指定一个固定的 CPU 核数和 IO 带宽，在业务高峰的时候容易出现数据库容量不够而导致的故障。
我们假设这样一个场景：总带宽是 100M，由租户 A 和租户 B 共同使用，基于资源的闲时共享和忙时隔离原则，我们尝试让租户 A 和租户 B 互不干扰地共同使用总带宽。
如果两者的重要程度不同，怎样保证重要进程的优先运行？此时我们可以每个租户的重要程度分配使用资源的比例，如给租户 A 和租户 B 分配 1:3 的权重比，当这两个租户都需要 CPU 时，A 将得到 1 份 CPU 时间，B 将得到 3 份 CPU 时间。这一操作我们称为权重分配，或 < weight >。
有时候物理资源较为充裕，低权重租户可能会占用大量并不需要的资源，如何限制它的使用呢？我们可以在权重分配的基础上给不同的租户定义资源上限 < max >，如租户 A 按照权重比 1/4 时，能使用的带宽最多为 25M，当给它设置资源上限参数 20M 后，它最多能使用 20M 的带宽。
租户数量增减会引发权重配比改变，如何直观判断各租户最低资源需求的满足情况？此时我们可以给各租户设置保留资源 < min >，这样不仅可以保证所有租户基本功能的运行，也能直观清晰地描述 QoS。
资源隔离效果测试
接下来我们用单元测试对 OceanBase 的磁盘 IO 隔离能力进行了一项仿真实验：
- 设置 4 个租户，每个租户启动 64 个线程发送 IO 请求，IO 请求固定为 16KB 随机读。
- 租户 1、2、4 的负载持续 20 秒。
- 租户 3 的负载从第 10 秒开始，持续 10 秒。
- 实验磁盘 IOPS 上限大概在 6w，如果不加限制，任意一个租户单独都可以打满磁盘。
组户间的资源隔离
首先验证租户间磁盘 IO 隔离，各租户通过 DBMS_RESOURCE_MANAGER 进行如下配置：
实验结果如下图所示：
可以看到：
- 在第 10 秒磁盘已经打满时，新加入的租户 3 依然拥有 1 万 IOPS，因为其通过 MIN_IOPS 预留了 1 万；
- 租户 4 的 IOPS 没有超过 5 千，因为其通过 MAX_IOPS 设置了资源上限；
- 无论负载如何变化，租户 1 和租户 2 的 IOPS 比值大概为 2:1，正如权重比例要求。
组户内的资源隔离
接下来，我们将验证租户内负载的隔离。我们在租户 2 内设置了 4 个类别的负载，各负载的配置如下表所示：
实验结果如下图所示：
可以看到租户 2 的 4 类负载：
- B 负载稳定在近 2000 IOPS，哪怕其权重为 0，因为 B 负载通过 MIN_PERCENT 预留了租户 MIN_IOPS 97% 的资源；
- A 负载稳定在 1000 IOPS 左右，因为其 MAX_PERCENT 为 1，最多只能使用租户 MAX_IOPS 1% 的资源；
- C、D 负载的 IOPS 比例始终保持大约 2:1，因为其权重为 50:25。
从上述实验可以看出，OceanBase 在支持租户间资源隔离的同时，还支持租户内负载间的资源隔离，且都满足 QoS 的 reservation（MIN），limitation（MAX），proportion（WEIGHT）三种隔离语义。
大查询队列
对于数据库来说，相比于单条复杂大查询，让大量的 DML 和短查询尽快返回更有意义。为了避免一条大查询阻塞大量简单请求而导致系统吞吐量暴跌，当大查询和短请求同时争抢 CPU 时，OceanBase 会限制大查询的 CPU 使用。当一个线程执行的 SQL 查询耗时太长，这条查询就会被判定为大查询，一旦判定为大查询，就会进入大查询队列，然后执行大查询的线程会等在一个 Pthread Condition 上，为其它的租户工作线程让出 CPU 资源。
配置大查询的参数为 large_query_threshold，执行时间超过这个参数设置的阈值，则认为是大查询。
| 属性 | 描述 |
|---|---|
| 默认值 | 5s |
| 取值范围 | [1ms, +∞) |
如果系统中同时运行着大查询和小查询，OceanBase 数据库会将一部分 CPU 资源分配给大查询，并通过配置参数 large_query_worker_percentage（默认值为 30%）来限制执行大查询最多可以使用的租户活跃工作线程数。
| 属性 | 描述 |
|---|---|
| 默认值 | 30 |
| 取值范围 | [0, 100] |
OceanBase 数据库通过限制大查询能使用的租户活跃工作线程数来约束大查询最多能够使用的 CPU 资源，以此来保证系统还会有足够的 CPU 资源来执行 OLTP（例如交易型的小事务）负载，通过这样的方式来保证对响应时间比较敏感的 OLTP 负载能够得到足够多的 CPU 资源尽快地被执行。
高效的 SQL 引擎
向量化执行技术
要让 HTAP 数据库具备 OLAP 的能力，尤其是大数据量 OLAP 的能力，除原生分布式架构、资源隔离，还需要给复杂查询和大数据量查 询找到最优解。OceanBase 执行引擎的向量化执行，就是解决这个问题的核心技术之一。
为了更好地提高 CPU 利用率，减少 SQL 执行时的资源等待（Memory/Resource Stall) ，向量化引擎被提出并应用到现代数据库引擎设计中。 与数据库传统的火山模型迭代类似，向量化模型也是通过 PULL 模式从算子树的根节点层层拉取数据。区别于 next 调用一次传递一行数据，向量化引擎一次传递一批数据，并尽量保证该批数据在内存上紧凑排列。由于数据连续，CPU 可以通过预取指令快速把数据加载到 level 2 cache 中，减少 memory stall 现象，从而提升 CPU 的利用率。其次由于数据在内存上是紧密连续排列的，可以通过 SIMD 指令一次处理多个数据，充分发挥现代 CPU 的计算能力。
向量化引擎大幅减少了框架函数的调用次数。假设一张表有 1 亿行数据，按火山模型的处理方式需要执行 1 亿次迭代才能完成查询。使用向量化引擎返回一批数据 ，假设设置向量大小为 1024，则执行一次查询的函数调用次数降低为小于 10 万次（ 1 亿/1024 = 97657 ），大大降低了函数调用次数。在算子函数内部，函数不再一次处理一行数据，而是通过循环遍历的方式处理一批数据。通过批量处理连续数据的方式提升 CPU DCache 和 ICache 的友好性，减少 Cache Miss。
由于数据库 SQL 引擎逻辑十分复杂，在火山模型下条件判断逻辑往往不可避免。但向量引擎可以在算子内部最大限度地避免条件判断，例如向量引擎可以通过默认覆盖写的操作，避免在 for 循环内部出现 if 判断，从而避免分支预测失败对 CPU 流水线的破坏，大幅提升 CPU 的处理能力。
存储的向量化实现
OceanBase 的存储系统的最小单元是微块，每个微块是一个默认 64KB（大小可调）的 IO 块。在每个微块内部，数据按照列存放。查询时，存储直接把微块上的数据按列批量投影到 SQL 引擎的内存上。由于数据紧密排列，有着较好的 cache 友好性，同时投影过程都可以使用 SIMD 指令进行加速。由于向量化引擎内部不再维护物理行的概念，和存储格式十分契合，数据处理也更加简单高效。整个存储的投影逻辑如下图：
SQL 向量引擎的数据组织
SQL 引擎的向量化先从的数据组织和内存编排说起。在 SQL 引擎内部，所有数据都被存放在表达式上，表达式的内存通过 Data Frame 管理。Data Frame 是一块连续内存（大小不超过 2MB）, 负责存放参与 SQL 查询的所有表达式的数据。SQL 引擎从 Data Frame 上分配所需内存，内存编排如下图。
在非向量化引擎下，一个表达式一次只能处理一个数据（Cell）（上图左）。
向量化引擎下，每个表达式不再存储一个 Cell 数据，而是存放一组 Cell 数据，Cell 数据紧密排列（上图右）。这样表达式的计算都从单行计算变成了批量计算，对 CPU 的 cache 更友好，数据紧密排列也非常方便的使用 SIMD 指令进行计算加速。另外每个表达式分配 Cell 的个数即向量大小， 根据 CPU Level2 Cache 大小和 SQL 中表达式的多少动态调整。调整的原则是尽量保证参与计算的 Cell 都能存在 CPU 的level2 cache 上，减少 memory stalling 对性能的影响。
并行执行技术
SQL 的执行引擎需要处理很多情况，为什么要对这些情况进行细分呢？是因为 OceanBase 希望在每种情况下都能自适应地做到最优。从最大的层面上来说，每一条 SQL 的执行都有两种模式：串行执行或并行执行，可以通过在 SQL 中增加 hint /*+ parallel(N) */ 来决定是否走并行执行以及并行度时多少。
串行执行
如果这张表或者这个分区是位于本机的，这条路线和单机 SQL 的处理是没有任何区别的。如果所访问的是另外一台节点上的数据，有两种做法：一种是当数据量比较小时，会把数据从远程拉取到本机来，OceanBase 中叫做远程数据获取服务；当数据量比较大时，会自适应地选择远程执行，把这条 SQL 发送到数据所在节点上，将整条 SQL 代理给这个远程节点，执行结束之后再从远程节点返回结果。如果单条 SQL 要访问的数据位于很多个节点 上，会把计算压到每个节点上，并且为了能够达到串行执行（在单机情况下开销最小）的效果，还会提供分布式执行能力，即把计算压给每个节点，让它在本机做处理，最后做汇总，并行度只有 1，不会因为分布式执行而增加资源额外的消耗。
对于串行的执行，一般开销最小。这种执行计划，在单机做串行的扫描，既没有上下文切换，也没有远程数据的访问，是非常高效的。
并行执行
并行执行同时支持 DML 写入操作的并行执行和查询的并行执行，对并行查询分还会再去自适应地选择是本机并行执行还是分布式并行执行。
对于当前很多小规模业务来说，串行执行的处理方式足够。但如果需要访问大量数据时，可以在 OceanBase 单机内引入并行能力，目前，这个能力很多开源的单机数据库还不支持，但只要有足够多的 CPU，是可以通过并行的方式使得单条 SQL 处理能力线性地缩短时间，只要有一个高性能多核服务器增加并行就可以了。
针对同样形式的分布式执行计划，可以让它在多机上分布式去做并行，这样可以支撑更大的规模，突破单机 CPU 的数目，去做更大规模的并行，比如从几百核到几千核的能力。
OceanBase 的并行执行框架可以自适应地处理单机内并行和分布式并行。这里所有并行处理的 Worker 既可以是本机上多个线程，也可以是位于很多个节点上的线程。我们在分布式执行框架里有一层自适应数 据的传输层，对于单机内的并行，传输层会自动把线程之间的数据交互转换成内存拷贝。这样把不同的两种场景完全由数据传输层抽象掉了，实际上并行执行引擎对于单机内的并行和分布式并行，在调度层的实现上是没有区别的。
适用并行执行的场景
并行执行通过充分利用多个 CPU 和 IO 资源，达到降低 SQL 执行时间的目的。当满足下列条件时，使用并行执行会优于串行执行：
- 访问的数据量大
- SQL 并发低
- 要求低延迟
- 有充足的硬件资源
并行执行用多个处理器协同并发处理同一任务，在这样的系统中会有收益：
- 多处理器系统（SMPs）、集群
- IO 带宽足够
- 内存富余（可用于处理内存密集型操作，如排序、建 hash 表等）
- 系统负载不高，或有峰谷特征（如系统负载一般在30%以下）
并行执行不仅适用于离线数据仓库、实时报表、在线大数据分析等 AP 分析型系统，而且在 OLTP 领域也能发挥作用，可用于加速 DDL 操作、以及数据跑批工作等。但是，对于 OLTP 系统中的普通 SELECT 和 DML 语句，并行执行并不适用。
适用串行执行的场景
串行执行使用单个线程来执行数据库操作，在下面这些场景下使用串行执行会优于并行执行：
- Query 访问的数据量很小
- 高并发
- Query 执行时间小于 100 毫秒
并行执行一般不适用于如下场景：
- 系统中的典型 SQL 执行时间都在毫秒级。并行查询本身有毫秒级的调度开销，对于短查询来说，并行执行带来的收益完全会被调度开销所抵消。
- 系统负载本就很高。并行执行的设计目标就是去充分利用系统的空余资源，如果系统本身已经没有空余资源，那么并行执行并不能带来额外收益，相反还会影响系统整体性能。
列存引擎（4.3.0 版本的功能预告）
对于分析类查询，列存可以极大地提升查询性能，也是 OceanBase 做好 HTAP 的一项不可缺少的功能。列存数据通常是静态的，很难被原地更新、而 OceanBase 的 LSM Tree 架构中 SSTable 是静态的，天然就适合列存的实现。MemTable 是动态的，仍然是行存，对于事务处理不会造成额外影响。因此 OceanBase 可以很好地兼顾 TP 类和 AP 类查询的性能。
列存引擎已经完成开发，并在 2023 年 8 月初发布了 Alpha 版本供部分用户进行 poc 验证。即将发布的 4.3.0 版本中会正式支持列存引擎，敬请大家期待。
客户案例
南京银行
业务挑战
- 线上业务增长受传统架构局限：随着南京银行大力发展线上金融业务，传统架构的并行处理能力、存储能力都不足以承接业务增长的高并发挑战。增长规模过快，将严重影响整体系统稳定性。
- IT资源成本高：传统的端应用大部分部署在物理服务器上，只有20%左右使用 VMware虚拟化部署。整体来看，IT资源利用率平均只在10%左右，空闲资源高，整体IT资源成本高。
解决方案
- 强大的混合负载管理能力：客户有很多业务具有在线事务处理和海量数据分析的复杂使用场景。现在市场上只有像 Oracle，DB2 这样的大型商业数据库能够支撑在同一份数据上做实时的计算，而一般通用的做法就是把数据导一份到数据仓库里做离线的计算，那么对资源本身其实是一种浪费。OceanBase 自研的 SQL 引擎和分布式并行计算框架，可以很好地支撑这样的场景。同时 OceanBase 已经在内部经过了众多金融场景多年的打磨，在保障业务事务特性的同时，能够提供海量数据分析能力，以更高效率、更低成本满足多元化的用户需求，是一款真正成熟的金融级分布式数据库产品。
- 良好的水平扩展能力：OceanBase 满足金融场景事务一致性、容灾、高并发的需求，基于其 Share-nothing 大规模并行处理模式，实现数据库的线性扩展能力，突破传统数据库瓶颈，真正实 现系统的平滑扩缩容。
- 业务迁移的无损化：OceanBase 打造的 OMS 数据迁移服务（OceanBase Migration Service），结合蚂蚁十年数据库架构升级的先进经验，真正做到了秒级的数据校验，秒级即时回滚，同时支持多种数据库类型，整个数据迁移链路和回滚机制的搭建基本上都是通过一键操作完成，使用简便。解决了用户的迁移痛点，降低业务迁移成本。
用户收益
- 相较传统核心，“鑫云+” 平台的处理性能提高了 3~5 倍，2000 万贷款借据的计提时间控制在半小时以内；
- 鑫云+平台运用新技术通过 X86 服务器代替了 IBM 高端服务器，轻资产模式使得单账户管理成本约为传统 IOE 架构的 1/5 至 1/10；
- 人员维护成本大幅下降，“鑫云+”平台的维护人员较传统银行业务系统约为 1/5 左右。
中国石化
业务挑战
- 中国石化基于新基建技术构建新一代智慧加油站，推进中国石化生活综合服务商转型战略，原有加油卡系统无法适应互联网化客户营销服务体验和模式创新需求。
- 随着数据应用的层次更深更广，数据类型更多，对数据库提出新要求。现为异构分散式系统，无法满足业务转型所需低系统性风险、管理运维和自主创新。
解决方案
- 基于 OceanBase 强大的 HTAP 混合负载能力：通过读写分离、资源隔离等技术实现了负载均衡和 OLAP 查询性能提升。通过存储引擎的 LSM tree 架构、事务引擎的提前解行锁等技术提升了 OLTP 事务性能。
- 通过“数据+平台+应用”的架构设计，将现有加油卡系统从分省运维的 23 套 Sybase 和 Oracle 单体数据库，统一集中至一套 OceanBase分布式数据库集群中。
- OceanBase对传统集中式数据库具备优异的兼容能力，帮助中国石化原始数据库应用无损迁移，过渡方案确保柔性切割。
用户收益
- 转型：电子券、返利实时化，单一支付方式向多种支付方式转变，有力推进中国石化生活综合服务商战略转型。
- 提效：OceanBase 支撑全国近 3 万个加油站的业务流量，对内支持交易流水由天级降低到秒级，实现一体化班日结和报表需求。数据查询时间由分钟级降低到秒级，支持每分钟 50,000 笔业务交易。
- 降本：23 套分散系统运维降低至 1 套 OceanBase，大幅度降低了软硬件和运维成本，实现 8 倍存储成本节约。
- 可靠：故障恢复时间从小时级降低到分钟级，业务连续性达到 99.99%，安全级别达到网络安全等级保护 2.0 要求。
易仓科技
业务挑战
- 复杂 SQL 查询性能瓶颈：数据库主要承载物流、仓储、供应链相关信息，要求稳定性及高可用能力，目前多表关联 SQL 较多，复杂 SQL 查询耗时长。
- 单租户成本高：原数据库 RDS 有上百个实例数，单实例数据量大，资源碎片率高，需要不定时通过迁移至新实例释放碎片。随着实例数增多，单租户成本攀升。
解决方案
- 借助 OceanBase 的 SQL 执行引擎的并行执行技术，通过均衡分布数据分片到所有服务器，大幅缩短查询响应时间。
- 完整技术降本方案。高级压缩技术降低数据存储成本，多租户混部充分利用系统资源，以及 HTAP 混合负载减少数据冗余。
- OceanBase 多租户能力，实现数据库内核级虚拟化，对 CPU、内存、数据等资源提供隔离机制，并可以根据应用负载灵活配置租户资源占比，将多个单实例整合至 OceanBase 集群中，统一管理、灵活调度，有效提高资源利用率。
- OceanBase 支持 MySQL 语法、存储过程、函数，完全兼容易仓科技当前所 使用的 SQL 语法与数据类型，应用系统得以平滑迁移。
用户收益
- 复杂 SQL 查询性能提升明显，在没有做任何表结构调整与设计的情况下，大部分均有不同程度提升。其中一条在 RDS 中需 43 秒，OceanBase 仅需 0.01 秒。
- 高级压缩技术让易仓科技从 RDS 1.2T 数据迁移至 OceanBase，仅需 140G，数据压缩比高达 88%。加上多租户大集群模式提升资源利用率，使得迁移系统的数据库整体拥有成本降低 60%；
- 通过 OMS，易仓科技从 RDS 迁移至 OceanBase MySQL 模式，共1.2T 数据，数小时应用级别即完成迁移。