存储成本降71%,怪兽充电历史库迁移OceanBase

2023-12-14 03:56:16

怪兽充电作为共享充电宝第一股,业务增长迅速,以至于业务架构不停地增加组件。在验证 OceanBase 可以简化架构并带来更大的业务价值后,首次尝试在历史库中使用 OceanBase 替代 MySQL,存储成本降低 71%。本文为怪兽充电运维架构部王霖对本次数据升级的经验总结、思考。

图片

2017 年,“共享经济”成为年度热词,彼时共享单车 ofo 正红极一时,共享充电宝也正在市场扩散。就在这一年,怪兽充电成立,并后来者居上于 2021 年在纳斯达克上市。早在三年前怪兽充电的累计注册用户超 2 亿,到今年第二季度,注册用户数已经到了 3.625 亿,日均单量达 190 万笔。

持续涌入的用户带来了业务的快速增长,业务系统架构逐渐变得复杂。目前采用的是混合云架构,由于系统中微服务和数据组件较多,因此我们开发了维护云+IDC、覆盖基础设施/中间件/微服务的 DevOps 平台 Hydra 进行统一维护管理。下表是目前我们用到的数据库。

图片

图片

在我看来,使用新技术通常有两种路径,一种是当前技术无法满足需求进而寻求解决方案,另一种是新技术能够提供更高的效率,带来更大的价值。

而我们属于后者,之所以会替换现有数据库方案,源于 OceanBase 的技术分享。当我们听完产品特性和技术方案的介绍后,认为 OceanBase 是对怪兽充电现有架构和业务比较有利的工具,但也存在一些疑虑。

其一,面向 C 端用户的业务尤其是关键业务,在数据库选型时需要更加严苛的考虑,避免切换数据库带来的任何潜在风险;

其二,对于 IDC 中的用户而言使用开源产品是更合适的,但以过往使用开源产品的经验来说,来自社区的支持力度较小;

其三,我们对 OceanBase 的底层语言 C++ 不是很熟悉,担心上手门槛较高。

在深入了解 OceanBase 产品及社区后,上述疑虑都打消了。OceanBase 有很活跃的用户答疑群、社区论坛,能够及时解答用户提出的问题。此外,社区会举办丰富的线上、线下交流活动,对于开源用户的支持力度让我们对 OceanBase 建立了信心,所以我们决定试试。

在 IDC 中部署 OceanBase 后,我们对比了 OceanBase 与 MySQL 的使用效果,对怪兽充电的业务情况而言,OceanBase 的优势主要有以下两方面。

第一,可扩展性强。OceanBase 既可以垂直扩容,也可以水平扩容,扩缩容快速、透明、方便,而 MySQL 水平扩容的方式是分库分表,维护成本相对更高。

第二,节省存储资源损耗。此前部署 MySQL 时,我们制定了统一的物理机标准,采购相同标准的 CPU 和内存,在此基础上做虚拟化及资源的分配。为此我们还自研了一个调度系统,目的是跟不同的 CPU 内存和磁盘的比例做调配,尽量减少资源损耗。由于 IDC 的容量并不大,导致存储碎片化严重:比如创建的某个数据库存储用量比较大源,而 CPU 内存占用却很少,这时候虽然物理机上 CPU、内存使用率低但因为磁盘空间已被占用而无法分配新的数据库实例,造成极大的资源浪费。我们对单数据库 OceanBase 和 MySQL 的数据占用:

如果部署单实例,数据占用对比是 1:6.8;如果部署 OceanBase 三副本,MySQL 做主从的话,数据占用对比为 1:4.6。可见,OceanBase 在存储方面的优势显著,可以显著降低我们 IDC 的存储用量。

此外,在我们测试性能时,发现了 OceanBase 的另一个特点。在低并发情况下,OceanBase 4.0 版本的性能比 MySQL 5.7 低 ,而在高并发环境下,OceanBase 4.0 表现的性能优于 MySQL 5.7。

综合上述测试情况和优劣势分析,我们部署了OceanBase 4.0,接下来介绍当前应用情况。

图片

怪兽充电的订单业务主要是充电宝,其特点是客单价较低、单量大,下图是订单业务使用的数据库情况。

图片

从图中可以看到,订单业务涉及的数据库包含三部分。

  • 实时数据库支持用户下单,涉及高并发场景。为了提升高并发能力,我们按照用户分了 8 个库,并使用 ShardingSphere JDBC 接入迁移服务。

  • ElasticSearch 集群是为满足后台多字段的联合查询需求。在业务数据量不断扩大的情况下,后台查询若是用实时库查询,其索引无法覆盖所有的查询场景,由此引入 ElasticSearch 集群。迁移服务也写入 ElasticSearch 集群,通过 Binlog 订阅实时数据库的数据。

  • 历史数据库在使用 MySQL 时采用分库分表方案,它的特点就是更新的需求很少。每天会有一个实时的任务,去把实时数据库中的历史数据定时写入历史数据库。历史库的数据量较大,从 8 个库分到 64 个库(schema),放到 8 个实例中,总体数据量约 9.6TB,单库中最大的表数据超过 2 亿行。

基于订单业务的数据库情况,我们决定第一步将历史数据库迁移至 OceanBase,降低存储成本与运维成本。原因是:其一,历史库的数据量级庞大,OceanBase 的优势之一就是降存储成本;其二,从 MySQL 的 64 个库到 OceanBase 单库,运维与维护成本会极大降低;其三,历史库读写场景较少,涉及少量精确的查询,且不影响用户下单,迁移的风险较小。

图片

第一步,我们在 IDC 部署 OceanBase 集群。OBCluster 分了三个 zone 和三个server,分别部署在三组机架中;单主机规格为 40 核 128G,考虑到日常读写量和存储成本,我们仅仅在日志盘上使用了 SSD,数据盘使用的是机械硬盘。由于 OBProxy 是无状态服务,因此通过 Helm 被部署在 K8S 集群里。

图片

第二步,使用 OMS 同步数据。首先我们使用 OMS 同步 64 个数据库到 OceanBase,这里面存在一个多库汇聚到一个库的问题,那么,我们需要建 64 个数据同步对象吗?其实不用,OMS 的配置迁移对象的匹配规则能力,使分库分表的数据源迁移到 OceanBase 变得非常简单高效,对于我们 8 个数据库实例共 64 个库,建 8 个同步对象就行了,通过简单的配置可以实现每个实例上多个库的数据汇聚同一个 OceanBase 库。

为了确认 OceanBase 的稳定性,我们服务会保持一段时间的双写,等验证完会完全切换到 OceanBase 上。

接入 OceanBase 后,我们的存储成本节约了 71%,总的存储量从原来的 9.62TB*2(9.62 为单 MySQL 实例,考虑主从高可用部署所以乘以 2)到现在的 5.6 TB(三副本的总存储量),短期之内我们不用再考虑数据库扩容的问题了。

另外,我们在迁移过程中也遇到一些问题,可供大家参考。

第一,OBServer 与 Dell Raid 高速缓存兼容性问题:Dell Raid 卡高速缓存配置中,写策略为默认“回写”,改为“直写“后恢复;

a. 有租户 clog 满,扩容之后也会一直上涨;

b. 租户无法正常合并;

c. OBServer 启动日志中有大量关键字为"ret=\-4070"的 WARN 报错,有个关键信息"failed to fetch and submit single log",就是合并时无法读取日志,已经可以定位到 OBServer 合并场景中,有 I/O 操作不成功;

d. 后续定位到 Dell 阵列卡高速缓存配置中,写策略为默认的“回写”时,会引发单测复现问题,改为“直写“后恢复,相关问题也已经反馈 Dell。

第二,机械盘部署问题:在 OceanBase 实例上做压测时,因为磁盘性能不佳,导致日志流同步出现落后,进一步触发副本 rebuild。OceanBase 社区表示后续会优化一下对机械盘的兼容性。

图片

目前订单业务的历史数据库迁移已完成,正式用于生产环境。经测试验证,在查询场景下 OceanBase 同样有着优秀的性能表现。接下来我们考虑将查询场景也迁移至 OceanBase,包括服务后台查询和报表查询。

  • 服务后台查询:服务后台查询和上文提到的订单后台查询类似,用 MySQL 做相关的 OLTP 的操作,数据通过 Binglog 订阅同步写入Elasticsearch,整体成本较高,包括 MySQL 和 Elasticsearch 存储的重叠、中间链路数据同步服务的支撑等。因此,后续计划通过 OceanBase 替代 MySQL + Elasticsearch 的架构。

  • 报表查询:报表查询当前的现状是,数据存储在 MySQL,遇到一些数据聚合量比较大的 SQL 查询时非常慢,影响系统稳定性。因为涉及一些 OLAP 的场景,考虑到 OceanBase 会比 MySQL 更合适,接下来会部署 OceanBase 对应的规格,并做流量回放比对验证。

在使用 OceanBase 的过程中,也让我们对其产生了一些功能上的期望,主要包括以下四点。

第一,期望 OMS 支持 MySQL 到 Rocket MQ 的数据迁移。在 IDC 侧,数据迁移的场景包括两部分。一部分是 MySQL 到 MySQL 的数据同步使用某其他国产数据库开源的 DM 工具,包括全量同步和增量同步;另一部分是从 MySQL 到 Rocket MQ 的数据同步使用 canal。我们调研了OceanBase 的 OMS,虽然使用体验不错,但发现社区版不支持数据从 MySQL 同步到 Rocket MQ。因此,我们希望能否将 OMS 开源,以共建的方式补全功能。这样一来,我们就可以将整体的迁移框架统一到 OMS 中。

第二,监控告警,以方便接入开源的监控告警体系。我们希望相关的组件能够提供 metrics 指标,以便接入我们内部的监控告警,同时提供一些 Grafana 面板,提供建议的告警表达式。

第三,问题排查更加智能化。当前,我们依赖 OCP 中比较完善监控指标和专家知识,而我们希望这部分变成自动化工具,包括自动分析、自动提供解决方案或工具等。

第四,开源或开放流量回放工具。

文章来源:https://blog.csdn.net/OceanBaseGFBK/article/details/134880997
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。