刘强：作业帮给OceanBase提了九条意见

3 月 25 日，第一届 OceanBase 开发者大会在北京举行， 作业帮数据库架构师刘强为大家带来了《作业帮基于 OceanBase 的 HTAP 实践》的分享 ，为大家介绍了 OceanBase 上线作业帮半年来的体验与心得。

以下内容由大会演讲整理而成：

在作业帮刚上线 OceanBase 4.0 时，我分享过作业帮的业务架构痛点（移步《作业帮：探索多云架构下的数据库集群解决方案》可阅读）。目前，作业帮是多云架构（阿里云、百度云、腾讯云），并同时使用 MySQL、Redis-Cluster、MongoDB、Elastisearch、TiDB 、OceanBase 这几款数据库。出于高可用和降本需求，我们决定将更多的 MySQL 业务场景升级为 OceanBase，本文将和大家分享具体原因，以及 OceanBase 4.0 与 MySQL 5.7 的对比数据。

高可用双活架构方案升级需求

由于作业帮业务的多样性和复杂性，我们对于分布式数据库的使用需求主要基于以下几个方面。

第一，在海量数据的情况下，希望减少分库分表的复杂度，并解决单机存储瓶颈。

第二，对 I/O 密集型的 SQL 及 CPU 密集型的 SQL 来说，我们希望能够提高响应速度，减少它在 MySQL 中对线上业务的影响。

第三，每个业务内部都需要业务人员频繁查询、录取线上数据，并有相应的报表服务以供上级 Leader 查看，而且大数据部门也会有报表需求接入线上数据，这对于线上 MySQL 来说难以支撑，在数据归档及汇总的情况下，也缺乏良好方案。

第四，由于 MySQL 的特性限制，我们需要基于一个外部的高可用组件来实现 MySQL 的高可用架构，在多云环境下，网络环境相对复杂，这对高可用的稳定性提出了更高要求。如果部分业务的请求链路长或复杂，跨云访问会使业务相应耗时增加，影响用户体验。

因此，我们需要探索良好的双活架构方案，初步方案是基于 MySQL ，并引入 DTS 来实现双活架构。这种架构的复杂性及引入过程中 DTS 的异常或中断，对于数据的一致性有很大的挑战。同时，在使用公有云的情况下，也希望能够最大程度降低硬件的使用成本。

OceanBase 4.0 对比 MySQL 5.7

出于高可用和降本需求，我们决定将更多 MySQL 的业务场景升级为 OceanBase，并对 OceanBase 和 MySQL 5.7 进行了多方面的对比。

▋ 性能对比

我们使用 32C64GB 的硬件规格分别对 OceanBase 和 MySQL 进行性能、CPU 使用率、磁盘空间占用的测试。

首先，从下图可见，OceanBase 性能明显超过 MySQL。

OceanBase 和 MySQL 的性能对比

其次从下图得知，在相同的并发环境下，OceanBase 的 CPU 使用率比 MySQL 低至少一倍以上。

OceanBase 和 MySQL 的CPU使用率对比

另外，由于 OceanBase 数据压缩及编码的技术相较于 MySQL，能够节约 2/3 以上的磁盘空间，因此，综合上述三方面的对比结果，我们认为 OceanBase 能为作业帮的降本增效提供极大帮助。

在性能方面，我们还测试了 DDL 的执行速度。对于耗时较长的 DDL，MySQL 会有补充延时问题，需要我们引用额外的审核工具来控制它的延迟，而 OceanBase 不存在延时问题。对于执行速度，MySQL 和 OceanBase 相差不大，这让我们更加期待 OceanBase 4.1 的数据旁路导入功能，可以将 DDL 的执行速度大幅提升。不过，我们也发现了一些语法兼容性的问题，例如，OceanBase 对主键的操作语法不支持多个 DDL 合并执行，只能各自单独执行。

▋ 架构对比

除了降本增效的需求，高可用也是我们在探索双活架构中最看重的一方面。相较于 MySQL，OceanBase 的高可用是有延伸的，不需要额外的高可用组件，这有利于解决数据不一致的问题。再加上 OceanBase 的日志具备多副本特性，能够支持在多机房或多城市灵活部署。OceanBase 还帮助作业帮实现了一些单元化的需求，我们可以将业务单元内的 Leader 数据调度在某一个机房内，实现业务访问的流量闭环，减少跨域读写。

▋ 字符集对比

最后，我们测试了字符集的支持程度。作业帮成立十年，我们使用 MySQL 的场景和字符集种类都比较多。OceanBase 4.0 当前支持图 3 中显示的几种字符集，在 4.1 版本中增加了对拉丁字符的支持。后续我们也希望 OceanBase 能够扩展字符集及校验集的支持种类。

以上是作业帮对 OceanBase 和 MySQL 的主要对比数据。在将更多业务场景切换至 OceanBase 的过程中，我们发现，在高可用双活架构方案之外， OceanBase 4.0 的 HTAP 和资源隔离能力也为我们带来许多意外之喜。

低成本与低延时更好地降本增效

OceanBase 是一个具备 HTAP 能力的原生分布式数据库，如何理解 HTAP？引用 OceanBase CTO 的一句话： HTAP 就是在高性能 OLTP 数据库的基础上扩展 OLAP 的能力，能很好支持实时分析。

在作业帮的业务场景中，我们感受到 HTAP 的两大显著优势：低成本和低延时。

低成本：我们希望一套系统能同时支持 OLTP 场景和 OLAP 场景，相比两套系统拥有更高的性价比。

低延时：省去了繁琐费时的 ETL 过程，降低延时，更好支持实时分析。

我们知道，在一套系统同时实现 OLTP 和 OLAP 的能力，其中一项挑战是资源隔离，使业务之间互不影响。这便是 OceanBase 带给我们惊喜的地方。

对于核心业务来说，我们希望能够使用物理资源管理，比如行存副本服务 OLTP，列存副本服务 OLAP，这两种业务是不共享物理资源的，可以做到绝对的隔离。OceanBase 可以增加额外的只读副本，再通过配置 OBProxy 的 proxy_idc_name 实现读写分离。

下图为 OceanBase 的物理资源隔离方案，基于只读副本，再增加逻辑机房的情况下，在 OBProxy 中配置逻辑机房的位置。 所有 OLAP 的只读流量都会录入只读副本中，避免与 OLTP 副争抢资源。

OceanBase 的物理资源隔离方案

对于成本敏感的逻辑资源隔离，OceanBase 在同一租户内就可能实现 OLAP 和 OLTP 的物理资源共享，进而实现资源隔离。

对于逻辑隔离来说，首先 OceanBase 定义了一个大查询，默认将执行时间超过 5 秒的请求判定为大查询，当大查询和短查询同时争抢 CPU 时，大查询会被降低优先级，待 CPU 资源充足时再被挂起，我们可以设置 Large_query_worker_percentage 在同一租户内，大查询最多可以占用 30% 的用户线程数。

在这种情况下，我们可以有效隔离大查询对 OLTP 业务的影响，优先保证了 OLTP 业务的执行。

我们使用了一些线上业务数据和 SQL 来对比 MySQL 和 OceanBase。在作业帮的业务场景中，一个大业务部门的报表需要多级 Leader 甚至上百人频繁查看，因此，即使是 OLAP 类型的业务，QPS 也可以达到几十甚至上百。

我们使用了 60 个并发去压测较复杂的 SQL，通过下图可以看出， OceanBase 比 MySQL 最起码快了一倍以上。OceanBase 的 CPU 使用率也基本控制在 25% 以下。