5000 万台物联设备搭载 OceanBase，写入性能提升 100 倍

本文作者来自某大型制造企业，文中讲述了该企业使用 OceanBase 替换 MySQL 的过程及经验总结。

我们的业务场景主要基于物联网领域周边的服务，做企业级 SaaS 的应用，如全国连锁店面视频服务系统、客流分析系统、智慧养殖系统、气象温度湿度监测、社区和校园安全系统、工厂生产线安全系统等。这些应用场景有四个主要特点：

👉 对数据上报的实时性要求较高。👉 设备量大，这是因为整个城市的智能化进程几乎都依赖物联网设备，且对设备的需求量越来越大。👉 感知能力强，一些边缘设备自带传感器以感知周围环境的变化，比如气温、光照、位移等。👉 应用广泛，5G 的普及加速了带宽的传输，时设备传输数据的能力极大加强，应用于社会基础设施的各个方面，如智慧社区、智慧医疗、智慧教学、智慧养殖、智慧交通、气象观测、车联网、品牌店面、工厂制造等。

上述应用系统通过不同的中台搭载 MySQL 数据库和内部自研的存储系统，底层连接着超过 5000 万台物联设备。在逐渐增长的设备量面前，这套存储系统支撑压力极大。首先是写入压力，在部分高并发写入场景，延迟较高；在部分场景存在写倾斜的问题，分布不平衡。最关键的是这套系统无法在线扩容。其次是资源无法隔离，大部分业务线都在一个集群中，对于业务而言，会面临大 SQL 风险和业务高峰期的高并发风险。此外，随着业务的增长，磁盘也要相应增加，存储成本不断升高。

面对上述困境，我们毅然决定选型一款新数据库，并确定以下六大诉求。

✅ 分布式能力：分布式的弹性扩展能力可以解决大存储、高并发的问题，是未来数据库选型的趋势。✅ 资源隔离：业务分散导致运维管理不方便且资源利用率不高，使用租户能力可以将业务统一管理且解决了资源争抢问题。✅ 兼容 MySQL：业务使用上还是以 MySQL 为主，那么旧系统移到新系统只需要少量的改造甚至不需要大量业务改造。✅ 运维简单：尽量使用一套标准运维平台来管理，减少不必要的工具平台开发运维，减少学习成本。✅ 写入性能高：由于业务写入场景占比较高，我们希望系统对写入比较友好。

✅ 存储成本低：我们希望能降低大规模数据的存储成本，做到锦上添花。

在调研过程中，我们了解到 OceanBase 具备上述所有能力，除了兼容 MySQL、性能高之外，OceanBase 是原生分布式，多租户模式下天然具备资源隔离能力，且架构为单机分布式一体化、AP、TP 一体化，可以为后续业务发展提供便利，减少再次替换数据库的风险。同时，OceanBase 拥有丰富的生态工具，便于运维。对于存储成本，OceanBase 极致的数据压缩能力可以释放大量磁盘空间，这一点我们也早有耳闻。因此，在 2021 年 12 月，我们开始搭建测试集群，并学习 OceanBase 基础知识。一个月后开始测试，包括 Sysbench 压力测试、兼容性测试、高可用场景验证、周边工具可用性验证、扩缩容验证，各方面都符合我们的预期。紧接着我们迁移了第一个业务，进行功能性验证，期间遇到一些小问题，官方社区人员都及时帮忙修正和解决。2022 年 9 月，我们将边缘业务切换到 OceanBase 生产系统中，一直稳定运行。随着业务陆续从旧存储系统迁移至 OceanBase，2023 年 8 月，我们终于完成系统的 100% 替换，目前，我们已经应用 OceanBase 超过一年，取得的收益较为显著。1、写入性能提升百倍。

在体温、疾病检测场景中，通常我们需要利用 loT 设备将大规模的动物体温、疾病等数据上报到业务中台。经过疾病分析系统分析后，将有价值的数据推送到用户端，指导用户做出相应的预防举措。

这是典型的写入、更新频繁的场景，旧系统难以支撑频繁写入、实时查询和聚合查询的需求。迁移到 OceanBase 后，类似这样的高写入场景，写入性能从 100~120ms 提升到 1~10ms。

2、查询性能极大提升。在一些用户报警场景中，我们通过 loT 设备监控用户的实时状况。例如，当某个用户表现出异常行为或发生盗窃等事件时，设备可以及时感知并将告警信息发送给用户端。在报警发出的同时，信息会被存储在数据库中，因此每天的增量数据也较为可观。在此前的旧系统中，面临严重的写倾斜问题，且查询性能低，系统延迟高。而在 OceanBase 中，通过分区即可解决上述问题。当前每天写入 1 亿数据量，我们使用每天拆分一个分区的方式存储数据，并保留 7 天。使用分区裁剪功能减少了不必要的数据过滤操作，查询性能得到了极大提升。3、多业务资源共享存储、资源隔离。在文章开头已经提到旧系统资源无法隔离的问题，替换为 OceanBase 后，我们实现了：

🚀 租户资源可以在服务器间迁移。🚀 单独业务租户之间资源隔离，避免争抢情况。🚀 业务数据安全得到保障。🚀 租户资源可以快速弹性扩缩容。🚀 不同租户根据具体读写特点通过 primaryzone 在服务器端可以混合负载，最大化利用服务器资源。

4、周边工具解决 90% 的运维工作量。OceanBase 的生态工具丰富且便捷，以我们目前使用的三款工具为例：

👨‍💻 迁移工具 OMS：从 MySQL 到 OceanBase 的高效迁移就靠它，且自带数据校验，支持回退。👨‍💻 开发者平台 ODC：开发者或 DBA 可以使用 ODC 查询、更改数据，以及导入、导出数据等，小功能非常多。👨‍💻 运维平台 OCP：这个工具涵盖了 90% 以上的运维工作量，包括 SQL 治理排查、统一集成监控告警、统一巡检与日志查看，以及服务器、租户资源等扩容、缩容。在很大程度上节省了我们的工作量。

1、应用经验总结在应用数据库的过程中难免会有一些小问题，此处分享我们在使用 OceanBase 时遇到的问题和解决方案，供 DBA 们参考。第一个问题是上线 OceanBase 后，我们发现某张表的文件远远大于其真实大小，也就是说这张表中的数据膨胀严重。经过排查，发现一个 JSON 类型的字段存储的是某物体的坐标信息，字符串非常长导致数据膨胀。我们和开发同事沟通后，一致决定将这类数据放到对象存储中，后续再没出现这样的问题。此外，在一些其他场景中也有数据膨胀的情况，可以通过设置参数来调整。第二个问题和 Buffer 表相关，简而言之，频繁更新小表，查询速度慢于预期。这是由于底层的 LSM 机制将频繁更新、删除的数据进行标记，但事实上数据并没有及时被清理，而是在每日合并数据后进行清理。因此，在数据被清理前，如果有查询操作就会在查询时扫描那些被标记的数据，比如表中只有 1000 条数据，但因为更新了上万次，所以在查询时会扫描被标记的上万条的标记数据块，使查询速度拉长。这个问题也很好解决，给表增加属性 table_mode=’queuing，在查询时就不会再扫描被标记的数据块，使查询速度回复正常。第三个问题是业务大表与基础小表在 JOIN 场景中可能存在分布式执行计划，众所周知分布式的数据传输比较昂贵，尤其是数据量较大的情况下，所以通常我们要尽量减少分布式执行计划的开销。从 OceanBase 官方文档中了解到，可以将小表设置成一个复制表。其本质是将小表的数据复制到每个 OBServer，这样的话无论大表在哪个服务器，都有小表对应。在一台服务器上进行计算，提升整体 SQL 性能。

2、未来规划

目前，我们使用的是 OceanBase 3.x 版本，后续将升级为更为稳定、性能更强的 OceanBase 4.x 版本。但在此之前，我们想进行 SQL 性能对比测试（大表聚合查询，大表 JOIN等）、数据文件膨胀问题测试，以及其他的功能测试。我们希望在新版本中可以避免数据膨胀问题。

此外，我们也希望 OceanBase 可以更加完美，比如在 OCP 中增加表级别的运维、支持 phpmyadmin 客户端工具等，覆盖几乎 100% 的运维工作。

想了解更多干货，可通过下方扫码关注