千亿大表存储空间节省超八成，oceanbase 在教育行业的落地实践-c7电子娱乐

编者按：希沃作为广州视源股份（cvte）旗下专注教育的品牌，一直以来在数据库基础设施方面主要采用mysql。然而，随着业务规模的不断增长，mysql在高可用性、性能、成本和功能方面逐渐暴露出瓶颈和问题。在此背景下，希沃选择引入oceanbase，对数据库架构进行了全面升级。通过采用oceanbase，希沃在高并发、大存储和轻量级数仓、htap等多个业务场景下，实现了降本增效和增强稳定性的目标。本文将分享希沃在数据库运维中遇到的挑战、选型过程中的思考，以及引入oceanbase后的具体成果和使用经验。

作者：王胜状，广州视睿电子科技有限公司dba

希沃是广州视源股份（cvte）旗下的自主品牌，专注于智能化和数字化技术，通过提供产品、c7电子娱乐的解决方案和服务，推动教育与科技的智慧互联。希沃的主营业务包括教学硬件、教学应用、管理平台和教师发展等领域。其中，希沃的交互智能平板产品连续12年在全国交互智能平板行业中市占率第一，覆盖超过19.2万所中小学校和280万间教室，为超过800万名教师提供服务。

mysql使用现状

随着业务的快速发展，数据库实例数量呈指数级增长。希沃的主要业务部署在全球六个区域的四朵云上。目前，希沃大约拥有500个数据库集群，数据规模在500tb到1pb之间。由于集群数量庞大、数据量巨大且种类繁多，以及多云多区域的复杂分布，日常运维压力显著增加。

在2021年，我们对mysql进行了容器化改造，以期利用kubernetes的节点池化和operator的标准化、自动化能力来实现降本增效，稳定性提升。下图展示了希沃mysql operator的架构示意图。

该架构的核心是中间的statefulset，构建了一个一主多从的mysql集群，通过mysql原生复制进行数据同步。orchestrator实时监测主从复制的拓扑结构，并负责高可用性（ha）切换。operator根据orchestrator探测到的拓扑信息，为statefulset中的pod打上相应的标签。架构中包含三个loadbalancer类型的服务，这些服务会根据每个pod的标签来分配读写、只读或快捷查询流量。此外，每个pod中还有一个pmm-agent的sidecar容器，在启动时将自己注册到pmm（percona monitoring and management）中，用于采集数据库的指标和慢日志。

operator还基于kubernetes的cronjob实现了mysql的xtrabackup物理备份和磁盘快照备份。在kubernetes中，我们还部署了externaldns和cmdb operator。cmdb operator负责将集群信息自动同步到配置管理数据库（cmdb），而externaldns则根据kubernetes中loadbalancer服务的信息，自动进行所有数据库域名的私有域名解析。

在上述架构中，通过operator，我们已经将数据库常见的日常工作标准化和自动化，包括安装，cmdb录入，监控，备份，ha，慢日志采集等。但目前mysql架构仍面临一些痛点和挑战。主要是随着公司业务量不断增长，业务对服务sla的要求越来越高，对mysql的性能和稳定性的要求也逐步提升，同时还有降本增效的需求。

使用mysql 痛点和挑战

随着业务的不断扩大，mysql在多个维度逐渐表现出难以应对的趋势。

1.高可用问题

• 在高可用层面，mysql 在非“双1”情况下进行故障切换（failover）时容易丢失数据，导致1032/1062复制错误。
• 资源隔离问题， kubernetes 基于 cgroup 实现资源隔离，垂直升配有一些限制。
• 跨机器的垂直升配需要重建 mysql pod，导致主从切换。
• kubernetes 版本升级频繁，对容器化的 mysql 运维带来了一些挑战。例如资源对象弃用、api版本兼容，甚至在升级 kubernetes 版本时，由于不同版本间可能存在 pod 哈希计算的差异，可能会导致pod重建。

2.性能问题。

• 单机性能瓶颈。例如，在 iot 业务中，qps 需求最高可达 300k，单机 mysql 难以承受此负载。
• 业务响应时间长，出现慢查询风暴。
• 主从复制延迟大，导致读写分离无法读到最新数据。
• 磁盘 ioutil 高，云盘 io出现瓶颈。

3.成本高 利用率低。

• 整体资源利用率偏低，cpu 利用率仅在 15% 左右。
• 从库资源闲置。
• 业务存在波峰波谷，为了应对波峰需求，mysql常态化配置较大规格
• mysql 压缩能力较弱，导致存储成本不断上涨。
• 为支持第三方工具的在线 ddl 能力，需要预留一定的磁盘容量。

4.读写分离问题。

• 架构无代理层, 读写分离不透明, 需要开发引入多种数据源，侵入业务。
• 主从延迟无法保障一致性读, 核心业务逻辑只能使用主库。

5.分库分表问题。

• 分库分表也会侵入业务, 业务改造周期较长。
• 分库分表运维迁移工作量大。
• 部分sql有损, 如跨库join问题, in查询跨库表无法分表裁剪, 聚合时间长等。

6.ddl问题。

• mysql原生ddl 会导致主从延迟，影响读写分离和flink cdc等
• 某些类型ddl不是online的
• ddl速率慢，大表ddl时间按天记
• 第三方 ddl工具存在一些问题，这些工具通常通过影子表模式进行表结构变更，每次修改表结构时都会克隆一张影子表，导致磁盘空间需求翻倍。然而，kubernetes 的 pvc 只能扩容，不能缩容，因此在 ddl 完成后，这部分磁盘空间被浪费。

7.功能性问题。

• 业务期望获取更多数据库功能，如全文索引、向量、图、时序等，这导致数据库技术栈日益增多，异构数据库之间的同步需求不断增加。
• 分析处理（ap）需求持续增长，但由于 mysql 不支持 ap 需求，需要将数据引流到大数据平台进行处理。etl 流程时间较长（t 1），并且无法保证数据的一致性。
• 缺少高级功能如熔断限流和执行计划绑定。在面对异常流量或sql执行计划异常时，缺少干预手段。

数据库选型思考

鉴于 mysql使用过程中的这些痛点，我们开始寻找更符合业务需求的数据库。我们需要支持以下六个方面。

第一，兼容mysql生态

• 完全兼容mysql 协议，应用能够无缝迁移，无需任何改动。
• 兼容mysql binlog, 方便下游mysql生态工具进行消费。
• 兼容mysql 运维工具。

第二，ha高可用

• 无数据丢失风险：希望新数据库在内核层面采用分布式一致性协议（raft 或 paxos），确保数据的完整性和一致性。
• rto 为秒级，rpo 为 0。
• 资源隔离能力
• 支持多中心、多活架构
• 高级功能支持：如熔断限流和执行计划绑定，能迅速应对异常流量或 sql 执行计划异常，确保数据库稳定运行。

第三，性能强劲。

• 高并发支持, 轻松应对高并发场景。
• 支持海量数据存储和高效管理。
• 具备分布式扩展能力, 支持在线变配, 跨机变配, 避免熬夜操作。
• 支持ap 分析能力, 支持mpp 计算能力, 以适应多样化的应用场景。
• 单机性能好, 支持边缘小实例。

第四，成本低。

• 计算成本低。
• 存储成本低, 支持强劲压缩能力。
• 学习成本低, 具备完善的学习文档。
• 迁移成本低, 支持双向同步等迁移功能。
• 运维成本低, 提供白屏化操作界面，简化运维工作。

第五，易用

• 原生支持读写分离
• 分布式透明，无需分库分表，
• 在线ddl方便，速度快，对业务无感
• 多租户

第六，安全性

• 大厂背书，技术先进性保证
• 有企业版、cloud版，售后响应迅速，问题厂商兜底
• 开源最好 社区活跃成熟
• 国产化、信创要求
• 多云支持，不被云厂商绑定，屏蔽多云基础设施差异

数据库调研

基于上述选型思考，我们在2023年6月份开始调研oceanbase数据库。

从整体架构来看，oceanbase 由无状态的 obproxy 和一体化的 observer 组成。observer 采用三副本架构，具备强一致性特性，支持分布式扩展和多租户功能。

从存储架构来，oceanbase 数据库的存储引擎基于 lsm-tree 架构，将数据分为静态基线数据（放在 sstable 中）和动态增量数据（放在 memtable 中）两部分，其中 sstable 是只读的，一旦生成就不再被修改，存储于磁盘；memtable 支持读写，存储于内存。数据库 dml 操作插入、更新、删除等首先写入 memtable，等到 memtable 达到一定大小时转储到磁盘成为 sstable。在进行查询时，需要分别对 sstable 和 memtable 进行查询，并将查询结果进行归并，返回给 sql 层归并后的查询结果。同时在内存实现了 block cache 和 row cache，来避免对基线数据的随机读。因此具有压缩率高，写入友好，高性能等优点。

oceanbase 还拥有完善的生态系统，涵盖多个关键组件，包括 odp 数据中间件、oms 迁移平台、面向开发者的 odc 平台以及面向运维的 ocp 平台等。

我们之所以选择 oceanbase，主要是由于它几乎符合我们上述对数据库的需求。

oceanbase落地场景与收益

目前，oceanbase 已在希沃部署了5套集群，共33个节点和11个租户，线上生产环境容量达30tb，单表数据量超过1000亿。我们已经将五个核心业务迁移到 oceanbase。与此同时，我们的 devops 平台也集成了 oceanbase，提供一系列自动化功能，包括资源自动申请、快捷查询、sql 工单处理，以及 oceanbase 的健康度监测和慢查询告警等功能。

指标告警

通过采用oceanbase，希沃在高并发、大存储和轻量级数仓、htap等多个业务场景下，实现了降本增效和增强稳定性的目标。下面是我们的业务实践。

收益 1：iot 高并发场景，数百万设备稳定在线

第一个实践是oceanbase 在希沃的 iot场景的落地。

我们的 iot 场景管理着数百万设备，数据的实时性要求非常高。每天早晨八点学校设备开机时，mysql 主库的 qps 高达 70k，tps 达到 20k，尽管业务侧已进行了每秒1万的设备限流。在这种情况下，mysql 主从延迟可以达到 6 分钟，并持续约 1 小时。为减轻主库压力，业务采用了多数据源实现了读写分离，但每当主从延迟发生时，业务无法读取最新的设备状态。此外，在异常场景如网络故障时，大量设备会断线重连，如果不进行熔断限流，数据库将立刻被打爆。

主库 qps 70k tps 20k

早高峰主从延迟持续1个小时，最大延迟6分钟

相比之下，oceanbase 的内存写友好特性以及透明垂直扩展能力非常适合这种高并发场景。因此，我们决定将 iot 数据库迁移到 oceanbase 上。

在迁移到 oceanbase 之前，我们使用了一主三从32核（32c）机器组成的 mysql 集群，支持70k qps和20k tps，业务层限流在每秒1万个设备上线。迁移到 oceanbase 后，由于 oceanbase 的租户规格对业务透明且可灵活调整，我们初期选择了 62核（62c）400g 的规格，支持 250k qps 和 75k tps，每秒5万个设备的上线速度。后续通过持续观察oceanbase的性能指标，我们开始下调租户规格，最终调整到 30核（30c）180g，支持 100k qps、20k tps 和每秒2.5万个设备上线速度。这样的配置下，平均响应时间（rt）保持在 0.5ms 以内。

5w/s 设备上线速度

收益 2：大存储场景压缩6倍，消除 ioutil过高风险

第二个实践是 oceanbase 在处理希沃的大表、大存储、分区和分表场景中的应用。

我们的业务存储需求很大，数据量大导致磁盘的 ioutil 通常高达 50%-85%，影响性能并可能引起主从复制延迟。为了解决块存储的 i/o 瓶颈风险，我们给 mysql容器上配置了很高的内存规格，增加了成本。当垂直升配无效时，常见的处理方式是进行读写分离，使用多台机器来处理流量。此外，业务层使用 sharding-jdbc 进行了大量分表，并将部分大表迁移到某分布式数据库中。

在开发方面，开发人员迫切希望接入分布式数据库，以避免繁琐的分库分表和读写分离改造，并解决业务瓶颈。为此，我们利用了 oceanbase 的特性优势，将大存储量业务迁移到了 oceanbase 上。迁移后，之前早高峰时的块存储ioutil告警风暴成为了历史，计算资源使用率显著提升。核心大表迁移到 oceanbase后，节约了 143t 存储，约 82.7%。

此外，迁移过程中数据库完成了分布式改造，大大提升了系统的能力上限。未来在面对更多流量时，只需增加租户的 unit 数量即可扩展系统容量。这一举措不仅简化了架构，还提高了系统的稳定性和扩展性，大幅提升了业务的可持续发展能力。

由于 oceanbase 具有高压缩率，我们选择了阿里云的大数据本地盘机型来部署 oceanbase 集群，以实现历史冷数据归档。我们的 devops 平台集成并封装了归档工具pt-archiver，同时利用 odc 的数据清理和归档能力，自助高效地完成数据归档任务。

收益 3： 轻量级数仓场景，慢sql 响应时间优化10 倍

第三个实践场景是轻量级数仓。

emr平台将计算结果回流到 mysql，并通过 mysql 提供对外服务。这个业务的最大瓶颈在于 mysql 的响应速度缓慢，导致核心接口在早高峰期间延迟达到 1-8 秒，严重影响用户体验。此外，该业务从大数据平台回流数据，每晚大约需要处理233个任务，总计约7亿条数据，峰值每秒约7万条记录。为了完成这些任务，系统需要从凌晨两点运行到早上六点多，导致 mysql 的 io util 持续达到100%，并且主从延迟增加到 7 小时，存在回流性能瓶颈和ha风险。

业务响应时延大

io util 持续 100%

最大主从延迟7个小时，持续9个小时

每晚插入7亿的数据。高峰期平均每秒插入7w 记录

迁移至oceanbase 后，我们利用其 mpp 特性，通过使用 outline 对慢 sql 进行并行度绑定，利用mpp能力使 sql 响应延迟缩短至原来的 1/10。此外，在 233 个回流任务中，有超过 170 个任务的执行速度显著加快。存储压缩率也达到了之前的 10 倍。

top 慢 sql 对比

收益 4： htap场景oceanbase列存性能超预期

从 oceanbase 4.3 版本开始，它引入了列存储功能。我们也对这一新特性进行了探索和应用。

我们首先使用 tpch 工具对 oceanbase 进行了tpch性能压测，选用包含 80 亿条数据的 tpch-1000 数据集。在 mysql 中，该数据集占用约 1tb 空间，而在 oceanbase 中仅占用200多gb。通过对比单节点与三节点模式下的性能，我们得出以下结果：在单节点模式下，oceanbase 运行 22 条复杂查询大约需要 600 秒；在三节点模式下，同样的查询在 oceanbase 仅需 173 秒，性能表现仅略逊于 doris。结果表明，oceanbase 在性能上已经接近顶尖水平，同时还具备出色的稳定性和扩展性。

数据来源说明：

1.polardb 官方性能白皮书https://help.aliyun.com/zh/polardb/polardb-for-mysql/imci-performance

2.doris 官方https://doris.apache.org/zh-cn/docs/benchmark/tpch/

一个 htap 实践案例是负载均衡流量计费。具体业务场景涉及将运维侧的公网流量费用合理地分摊给各个用户。我们的基础架构部门对外提供基础设施服务，因此需要统计每个域名和 url 的访问次数及其响应的 body 大小。通过这一数据分析，我们可以识别出占用资源较多的对象，并采取措施，例如减少 api 请求次数或压缩响应大小，从而有效地降低公网流量费用。每个月，我们会从阿里云拉回 1000 万按天聚合好的数据，约800个域名和250万个url。这些数据会导入clickhouse、polardb和 oceanbase。

可以看到在 oceanbase 中，所有流量的 top10 只需 0.79 秒即可算出，1.4 秒内就可以完成所有流量的排序。这也说明 oceanbase 的列存能力非常好。

迁移到 oceanbase 的总体收益：稳定可靠，降本提效

稳定性方面，自上线14个月以来，oceanbase保持了零故障。

成本方面, oceanbase 实现了巨大的存储节省：相比迁移前基于 mysql 的 173tb 数据，oceanbase 仅需 30tb，节省了高达 143tb 的存储空间，节省率达到 82.7%。

oceanbase 解决了我们不少业务痛点，并显著提升了业务瓶颈。例如，iot 设备的上线速度提升了近五倍，轻量级数仓的慢查询查询速度优化了近十倍。在数据库迁移过程中，我们成功完成了大表的分布式改造，为未来的业务拓展奠定了坚实的基础。

我们还解决了许多潜在的运维风险，如 mysql 块存储的 i/o 瓶颈及主从延迟导致的数据丢失风险。如今，我们的数据库具备了出色的弹性扩容能力，能够应对大流量挑战。

在运维友好性方面，我们也取得了显著提升。过去在假期前后需要熬夜升降配mysql容器pod 规格，现在无需再为此操心，扩缩容变得轻松自如。此外，我们还获得了诸如熔断限流、outline 执行计划绑定以及列存功能等新增能力，这些都极大地增强了数据库的性能和稳定性。

当然还有一些其他收益，比如在压测场景，环境克隆在速度和便捷性方面均显著提升。

使用 oceanbase 时遇到的问题

当然，在使用oceanbase的过程中，我们也遇到了一些问题，不过大多数问题都已得到修复。以下是一些典型问题：

兼容性问题。在版本4.2.1中，某些mysql命令（如 show index、flush 等）存在兼容性缺陷，导致依赖这些命令的mysql生态工具无法正常工作。我们计划在新发布的4.2.5版本中进一步验证这些兼容性问题。

版本升级缓慢。例如，某业务需要进行大表 int 到 bigint 字段的变更，虽然oceanbase 4.2.2已支持该特性，但ob cloud 4.2.1版本还不能直接升级至ob cloud 4.2.5版本，

spm问题。在动态sql场景中，不同的 in 条件数量会被spm识别为不同的sql，开启spm后，会存储大量执行计划，导致磁盘空间占用过大，进而造成磁盘不均衡。

oms问题。在使用oms时，遇到雪花id同步过慢。以及原表主键在目标表上不是主键或唯一键的情况下，导致全量校验报错的问题。此类问题目前已修复。此外，云上的ob cloud当时无法自行配置双向防回环同步，导致线上数据被覆写，现在此功能已支持。

使用问题。

• 在分区维护时导致全局索引失效。
• 压测时 sql audit 快速刷掉，增加问题定位的难度。
• 大表的全局索引没有分区，导致磁盘使用不均衡，信息收集时更加倾斜。
• 二级分区表添加分区时，导致二级分区模板丢失。

性能问题。高并发场景下，表中存在 text 字段时，每次操作需申请6mb内存，导致内存分配瓶颈。高并发下自增id插入时，可能因内部锁等待时间过长。

htap过程中的问题。

• 查询分区表时，若sql条件中存在恒false条件，htap会将查询默认发送至0号分区所在节点，造成该节点流量激增和集群不平衡。
• 多索引分区查询（如跨月查询）时，如跨月查询时命中两个月分区，直方图估算的dop可能不准确，导致查询性能下降。
• 目前相关行转列或行转列存与行存混合的ddl操作大多为offline，预计将在4.3.5版本中进行优化。

oceanbase 实践经验总结

在使用 oceanbase 的过程中，我们积累了一些经验：

在迁移业务至 oceanbase前，首先与开发团队深入沟通，明确核心和次要业务场景。开发需要扭转思维，根据分布式数据库的特征，去设计核心大表。对大表进行分区，并根据业务核心需求选择合适的分区键和分片策略。对于无法满足分片条件的查询，采用全局索引。同时，开发团队还会利用表组或索引表来优化查询性能。

在实际应用 oceanbase 集群时，我们根据业务特性和重要性进行集群划分，鸡蛋不要放在一个篮子里。多个集群，升级时先从非核心集群开始，以降低升级风险。避免将数仓应用与tp业务混用， olap 和 oltp 集群也要分开管理。使用 ob cloud 时，我们并未完全依赖多租户模式，因为默认未启用 iops 隔离。

在高并发业务场景下，我们选择独立部署的 obproxy 和 observer，并适当提高 observer 每个核心的 cpu 并发度。由于 ob cloud 不支持超卖，我们也将相同业务置于同一租户内，以实现弹性阈值的共享。同时我们发现，主可用区对集群性能影响显著。如果对可用区要求不高，ap业务可选择单个可用区部署。此外，我们会定期分析租户负载，调整租户规格以提高资源利用率。

监控方面, ob cloud接入arms，可以使用prometheus的remote_read直接采集ob cloud的指标，简单成本低。

运维方面, 在进行 ddl 操作前，事先进行验证，并通过比较 ddl 前后table id是否变化来判断操作是否为online或offline，降低ddl风险。

未来展望

我们将在以下几个方面持续推动oceanbase的落地和优化：

1. 版本升级与兼容性提升。

• 版本升级: 升级当前 oceanbase 版本至4.2.5，以提升数据库兼容性。
• 验证oceanbase新版本4.2.5是否完全兼容mysql生态工具。如goinception、pt工具、es同步工具、debezium同步工具等。
• 在devops平台上提升对开发人员的支持，使其能够更方便地查看和监控oceanbase的数据。
• 完善ddl流程，提高安全性。

2.新特性应用。

• 列存储: 在业务ap场景中广泛使用列存储，以大幅提升查询性能。
• ap新特性: 我们计划使用oceanbase ap新功能，如物化视图和roaringbitmap，优化部分业务场景。如使用roaringbitmap提高消息推送服务中大规模集合运算的效率。
• 向量特性: 积极调研oceanbase对向量数据库的支持情况，以满足ai应用对数据处理的需求。
• serverless架构: 探索和验证serverless架构在oceanbase中的应用，以实现资源的更高效利用。
• 灾备能力提升: 利用oceanbase的跨云主备库 异地多云多活c7电子娱乐的解决方案，加强跨云灾备能力。
• 国产化落地: 实现oceanbase在边缘项目的国产化落地。

3.分布式数据库规范与性能优化。

• 规范建设: 建立和完善分布式数据库的使用规范，全面提升团队的技术水平。
• 性能诊断:  dba团队将持续积累性能诊断与分析经验，确保系统的稳定性和性能优化。

通过以上展望和规划，我们期望在未来进一步提升oceanbase的使用体验，为业务发展提供更强有力的支撑。