头图

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

Image

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

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

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

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

Image

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

第二,对 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。

Image

OceanBase 和 MySQL 的性能对比

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

Image

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

Image

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

Image

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% 以下。

Image

OceanBase 与 MySQL执行SQL耗时

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

Image

并发量256 运行 Sysbench 任务

作业帮想对OceanBase说

以上就是作业帮对 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 都写一个配。

由于 OMS 数据迁移是测试中常用的功能,我们希望后续能有统一的配置,可以将 ghc 临时表统一过滤掉。

今天分享到这里就结束了,如果大家有什么想交流的,欢迎评论区留言与我探讨。


OceanBase技术站
22 声望122 粉丝

海量记录,笔笔算数