分享:作业帮在多云环境下的高可用双活架构优化实践

欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

分享:作业帮在多云环境下的高可用双活架构优化实践_第1张图片


本文来自OceanBase社区分享,仅限交流探讨。作者介绍:刘强,就职于作业帮基础架构 DBA 团队,负责分布式数据库的探索和使用,协同研发团队在公司内部推进分布式数据库在业务上的落地。

在作业帮刚上线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。

分享:作业帮在多云环境下的高可用双活架构优化实践_第2张图片

图1 OceanBase 和 MySQL 的性能对比

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

分享:作业帮在多云环境下的高可用双活架构优化实践_第3张图片

图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 能够扩展字符集及校验集的支持种类。

分享:作业帮在多云环境下的高可用双活架构优化实践_第4张图片

图3 OceanBase 4.0支持的字符集

以上就是作业帮对 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 副争抢资源。

分享:作业帮在多云环境下的高可用双活架构优化实践_第5张图片

图4 OceanBase 的物理资源隔离方案

对于成本敏感的逻辑资源隔离,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%以下。

分享:作业帮在多云环境下的高可用双活架构优化实践_第6张图片

图5 OceanBase 与 MySQL执行SQL耗时

在60个并发执行 OLAP 业务的同时,我们也用256个并发去运行 Sysbench 任务,在 OLAP SQL 扫描量较大的情况下,我们可以看到它的耗时出现了一些抖动(见图6)。

1680761741

图6 并发量256 运行 Sysbench 任务

以上就是作业帮对OceanBase 4.0 的探索过程,目前,我们已经使用 OceanBase 半年了,总结出一些心得及建议,供大家参考。

使用 OceanBase 的心得和建议

首先,对于 OceanBase OCP 管理平台有如下几点建议。

• 建议增加 DDL 任务列表显示,需要在每一个租户下,可以看到有多少任务正在执行。

• 建议增加 SQL 审核的功能,如果有业务正在从 MySQL 迁移,可以尽快保证业务上线,减少 DBA 工作,聚焦于对业务的落地。

• 在使用过程中我们发现,每个租户下磁盘的使用量、数据库的大小及表的大小,这一部分数据的监控是缺失的,需要完善。

• 在集群中测试时,需要实时监控性能数据,比如 QPS 响应时间、CPU 的使用率等,建议在现有能力上再缩短延迟。

其次,对 OceanBase 集群的一些问题,我们也给出反馈,希望得以提升。

• DDL无法实时查看任务的进度百分比,希望后续可以增加该功能。

• 现在集群升级时需要确保每个租户的 leader 都聚集在单个 Zone 下,这样对于每个集群有上百个租户来说,操作会比较繁琐,希望可以优化。

• 对于大家在使用过程中需要注意大小写敏感的参数设置,一旦创建后业务上线不合理则无法通过 SQL 语句进行修改,希望优化。

• 建议注意redo log 磁盘跟内存大小的配比,防止出现当磁盘空间还有富裕的时候,创建 redo log ,显示磁盘空间不够的问题。

最后,还有一些关于 OMS 数据迁移平台的小建议:目前存在的问题有三个,一是在数据迁移过程中不支持新增 DB 的同步,对于数据归档或汇总的需求不友好;二是 OpenAPI 开放的太少,不利于我们内部平台的改造;三是 ghc 的临时表忽略写法过于繁琐,需要每一个 DB 都写一个配。由于 OMS 数据迁移是测试中常用的功能,我们希望后续能有统一的配置,可以将 ghc 临时表统一过滤掉。


欢迎访问 OceanBase 官网获取更多信息:https://www.oceanbase.com/

你可能感兴趣的:(数据库oceanbase)