就职于作业帮基础架构 DBA 团队，负责分布式数据库的探索和使用，协同研发团队在公司内部推进分布式数据库在业务上的落地。
* 本文来自社区用户的分享，不代表 OceanBase 立场，仅限交流探讨。原文地址：https://open.oceanbase.com/blog/2460246784
在作业帮刚上线 OceanBase 4.0 时，我分享过作业帮的业务架构痛点。目前，作业帮是多云架构（阿里云、百度云、腾讯云），并同时使用 MySQL、Redis-Cluster、MongoDB、Elastisearch、TiDB 、OceanBase 这几款数据库。出于高可用和降本需求，我们决定将更多 MySQL业务场景升级为 OceanBase，本文将和大家分享具体原因，以及 OceanBase 4.0 与 MySQL5.7 的对比数据。
由于作业帮业务的多样性和复杂性，我们对于分布式数据库的使用需求主要基于以下几个方面。
第一，在海量数据的情况下，希望减少分库分表的复杂度，并解决单机存储瓶颈。
第二，对 I/O 密集型的 SQL 及 CPU 密集型的 SQL 来说，我们希望能够提高响应速度，减少它在 MySQL 中对线上业务的影响。
第三，每个业务内部都需要业务人员频繁查询、录取线上数据，并有相应的报表服务以供上级 Leader 查看，而且大数据部门也会有报表需求接入线上数据，这对于线上 MySQL 来说难以支撑，在数据归档及汇总的情况下，也缺乏良好方案。
第四，由于 MySQL 的特性限制，我们需要基于一个外部的高可用组件来实现 MySQL 的高可用架构，在多云环境下，网络环境相对复杂，这对高可用的稳定性提出了更高要求。如果部分业务的请求链路长或复杂，跨云访问会使业务相应耗时增加，影响用户体验。
因此，我们需要探索良好的双活架构方案，初步方案是基于 MySQL ，并引入 DTS 来实现双活架构。这种架构的复杂性及引入过程中 DTS 的异常或中断，对于数据的一致性有很大的挑战。同时，在使用公有云的情况下，也希望能够最大程度降低硬件的使用成本。
出于高可用和降本需求，我们决定将更多 MySQL 的业务场景升级为 OceanBase，并对 OceanBase 和 MySQL5.7 进行了多方面的对比。
OceanBase 4.0 对比 MySQL5.7
1. 性能对比
我们使用 32C64GB 的硬件规格分别对 OceanBase 和 MySQL 进行性能、CPU 使用率、磁盘空间占用的测试。
首先，从图1可见，OceanBase 性能明显超过 MySQL。
图1 OceanBase 和 MySQL 的性能对比
其次，从图2得知，在相同的并发环境下，OceanBase 的 CPU 使用率比 MySQL 低至少一倍以上。
图2 OceanBase 和 MySQL 的CPU使用率对比
另外，由于 OceanBase 数据压缩及编码的技术相较于 MySQL，能够节约 2/3 以上的磁盘空间，因此，综合上述三方面的对比结果，我们认为 OceanBase 能为作业帮的降本增效提供极大帮助。
在性能方面，我们还测试了 DDL 的执行速度。对于耗时较长的 DDL，MySQL 会有补充延时问题，需要我们引用额外的审核工具来控制它的延迟，而 OceanBase 不存在延时问题。对于执行速度，MySQL 和 OceanBase 相差不大，这让我们更加期待 OceanBase 4.1 的数据旁路导入功能，可以将 DDL 的执行速度大幅提升。不过，我们也发现了一些语法兼容性的问题，例如，OceanBase 对主键的操作语法不支持多个 DDL 合并执行，只能各自单独执行。
2. 架构对比
除了降本增效的需求，高可用也是我们在探索双活架构中最看重的一方面。相较于 MySQL ，OceanBase 的高可用是有延伸的，不需要额外的高可用组件，这有利于解决数据不一致的问题。再加上OceanBase 的日志具备多副本特性，能够支持在多机房或多城市灵活部署。OceanBase 还便于作业帮实现一些单元化的需求，我们可以将业务单元内的 Leader 数据调度在某一个机房内，实现业务访问的流量闭环，减少跨域读写。
3. 字符集对比
最后，我们测试了字符集的支持程度。作业帮成立十年，我们使用 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 实现读写分离。
图 4 为 OceanBase 的物理资源隔离方案，基于只读副本，再增加逻辑机房的情况下，在 OBProxy 中配置逻辑机房的位置。所有 OLAP 的只读流量都会录入只读副本中，避免与 OLTP 副争抢资源。
对于成本敏感的逻辑资源隔离，OceanBase 在同一租户内就可能实现 OLAP 和 OLTP 的物理资源共享，进而实现资源隔离。
对于逻辑隔离来说，首先 OceanBase 定义了一个大查询，默认将执行时间超过 5 秒的请求判定为大查询，当大查询和短查询同时争抢 CPU 时，大查询会被降低优先级，待 CPU 资源充足时再被挂起，我们可以设置 Large_query_worker_percentage 在同一租户内，大查询最多可以占用 30% 的用户线程数。在这种情况下，我们可以有效隔离大查询对 OLTP 业务的影响，优先保证了 OLTP 业务的执行。
我们使用了一些线上业务数据和 SQL 来对比 MySQL 和 OceanBase。在作业帮的业务场景中，一个大业务部门的报表需要多级 Leader 甚至上百人频繁查看，因此，即使是 OLAP 类型的业务，QPS 也可以达到几十甚至上百。我们使用了 60 个并发去压测较复杂的 SQL，通过图 5 可以看出，OceanBase 比 MySQL 最起码快了一倍以上。OceanBase 的 CPU 使用率也基本控制在 25% 以下。
图5 OceanBase 与 MySQL执行SQL耗时
在 60 个并发执行 OLAP 业务的同时，我们也用 256 个并发去运行 Sysbench 任务，在 OLAP SQL 扫描量较大的情况下，我们可以看到它的耗时出现了一些抖动（见图6）。
以上就是作业帮对 OceanBase 4.0 的探索过程，目前，我们已经使用 OceanBase 半年了，总结出一些心得及建议，供大家参考。
首先，对于 OceanBase OCP 管理平台有如下几点建议：
-
建议增加 DDL 任务列表显示，需要在每一个租户下，可以看到有多少任务正在执行。
-
建议增加 SQL 审核的功能，如果有业务正在从 MySQL 迁移，可以尽快保证业务上线，减少 DBA 工作，聚焦于对业务的落地。
-
在使用过程中我们发现，每个租户下磁盘的使用量、数据库的大小及表的大小，这一部分数据的监控是缺失的，需要完善。
-
在集群中测试时，需要实时监控性能数据，比如 QPS 响应时间、CPU 的使用率等，建议在现有能力上再缩短延迟。
其次，对 OceanBase 集群的一些问题，我们也给出反馈，希望得以提升：
-
DDL 无法实时查看任务的进度百分比，希望后续可以增加该功能。
-
现在集群升级时需要确保每个租户的 leader 都聚集在单个 Zone 下，这样对于每个集群有上百个租户来说，操作会比较繁琐，希望可以优化。
-
对于大家在使用过程中需要注意大小写敏感的参数设置，一旦创建后业务上线不合理则无法通过 SQL 语句进行修改，希望优化。
-
建议注意 redo log 磁盘跟内存大小的配比，防止出现当磁盘空间还有富裕的时候，创建 redo log ，显示磁盘空间不够的问题。
最后，还有一些关于 OMS 数据迁移平台的小建议，目前存在的问题有三个：第一，在数据迁移过程中不支持新增 DB 的同步，对于数据归档或汇总的需求不友好；第二，OpenAPI 开放的太少，不利于我们内部平台的改造；第三，ghc 的临时表忽略写法过于繁琐，需要每一个 DB 都写一个配。
今天分享到这里就结束了，关于本期内容，如果大家有什么想交流的，欢迎评论区留言探讨~
发表评论