MatrixOne 助力某电信运营商构建低成本高性能车联网管理系统

客户基本情况

该电信运营商在物联网领域深耕多年，致力于为企业和个人提供全面的物联网解决方案，包括智能连接、设备管理、数据采集与分析等核心服务。凭借其强大的网络覆盖和技术优势，该运营商为各行业提供高效、安全、可靠的物联网服务，助力实现数字化转型和智能化运营。其以物联网连接为基础，卡位芯片、操作系统、模组、硬件四类入口，打造物联网卡管理平台、连接管理平台、5G 专网平台等三大平台，发展视频物联网、城市物联网、产业物联网三大业务领域。

面临的业务挑战

本次与 MatrixOne 合作的项目主要面向于车联网相关的业务。在车联网业务中，该运营商主要为车企提供流量卡实名认证，连接管理等服务。其核心系统由三个核心部分组成：车联网实名登记平台、5G 智能网联管理平台和车企实名登记业务平台，这三个平台分别采用一套 MySQL 8.0 数据库，目前总数据量达 2TB+。同时每年新增数据量达数百 GB，该系统已支持数十家车企客户，未来预期增加至百余家。

随着车联网业务的快速发展，该运营商的数据库架构面临着一系列挑战。

1.      扩展性问题：高并发请求的增加导致 MySQL 数据库出现性能瓶颈，用户只能手动通过分表形式来分散压力，运维成本较高，读写操作都较为复杂。

2.      查询性能问题：面对多表关联操作，MySQL 的查询性能会慢到几分钟甚至十几分钟。用户不得不对数据结构进行精细的修改，以避免进行三表以上的 join 操作，同时把大量的计算压力由业务应用来完成，这样会经常导致应用层的性能受到影响。

3.      资源利用率问题：系统整体硬件使用率不高。由于业务初期规划是以较大的商业规模来估算的，因此实际上每套系统底层的 MySQL 主备集群都配备了非常高规格的物理机，最大使用到 80 核 504G 内存。但是实际上因为业务发展还处于早期，以及车企仅会在批量进行开通操作的时候才会有一定业务洪峰，而绝大部分情况下硬件使用率较低。在整体大环境降本增效的背景下，业务部门的 IT 成本压力较大。

在这样的背景下，该业务的 IT 人员曾经尝试过将 MySQL 接入为应用系统准备的 K8s 云原生容器集群，来尝试解决资源利用率及扩展性的问题。但是实际测试发现直接将原生 MySQL 上容器，不仅没有达到线性扩展的效果，反而相比过去用物理机的形态性能大幅下降，最后只能放弃该方案。

解决方案

为了解决当前车联网数据架构中的关键挑战，同时避免对现有业务逻辑进行大规模改造，基于 MatrixOne 的云原生 HTAP 解决方案应运而生。

1.      弹性扩展：MatrixOne 作为一款完全面向容器而设计的云原生数据库，天然支持了 K8s 容器环境部署。同时 MatrixOne 是完全存算分离的数据库，CN 计算节点及 TN 事务管理节点均运行在基于 K8s 管理的容器上，这两种节点均无状态，可以随时启停或者扩展。存储层运行在对象存储上，天然具备很强的扩展性。需要有状态保证的写入日志节点通过三副本的 Raft 协议来保证可靠性。因此其天然可以利用容器平台超强的扩展能力，来实现扩展性。在业务负载上升的时候，仅需 1 条运维命令即可秒级无感知的增加 CN 计算节点来匹配更高的业务并发量。

2.      容器池化：MatrixOne 基于容器的池化能力，可以按需调用底层计算资源，在业务发展初期，整体负载压力较小的时候，MatrixOne 可以使用较小和较少的计算容器节点。而在业务负载逐渐加大的时候，MatrixOne 仅需一条简单的运维命令即可秒级对现有计算容器节点进行垂直扩展或者水平扩展，这也实际使用的底层资源始终可以匹配业务需要的资源，可以极大的提高硬件使用率。

3.      多租户：MatrixOne 支持多租户能力，在一套 MatrixOne 集群内，允许用户用不同的租户登陆，将完全看见不一样的数据空间，同时可以将 1 个或多个 CN 计算节点绑定到不同的租户上，确保计算负载的隔离性。因此用户三套业务应用底层的所有数据库硬件均可以被池化，而上层每套业务应用数据库可以作为一个 MatrixOne 集群中的租户存在，共享一套 MatrixOne 集群。这种使用模式将进一步提高硬件整体使用率。

4.      HTAP 能力：MatrixOne 是一款 HTAP 数据库，针对多表关联，聚合分析类的 OLAP 查询比 MySQL 能力强的多，过去需要花十几分钟在 MySQL 进行查询的语句在 MatrixOne 中仅需要秒级即可输出结果，这将极大的降低被迫被推到业务应用层去执行的数据计算负担。

5.      MySQL 兼容：MatrixOne 与 MySQL8.0 高度兼容，对于开发人员来说，所使用的 Java 工具包，包括 ORM 框架 Hibernete，连接池 Druid，建模开发管理工具 DBeaver，MatrixOne 均可以无缝兼容，用户只需要保持与 MySQL 一样的开发习惯即可，极大的降低了迁移适配应用的成本。

实施过程

客户在详细了解 MatrixOne 的整体技术细节之后，明确了要进行数据库云原生化改造的方案，项目开始进入到 POC 实施阶段。

首先进行了基于 K8s 及对象存储部署的测试，MatrixOne 整体使用了 76 vCPU，304G 的内存资源，及 4TB 的对象存储资源，即完成了面向三套业务系统的整体部署，比过去 1 主 1 备的 MySQL 物理机资源整体少了近 80%。

其次进行了业务应用适配性的测试，业务侧准备了 43 个应用接口进行测试，42 个接口测试一次性通过，其中 1 个应用接口因为碰到了 MySQL 在整型和字符串数据类型转换方面不正规的使用方式而出现差异，在我们的建议下客户修正了自己的代码，并通过了第 43 个接口的测试。

第三，我们对相对性能要求较高的部分业务接口进行了性能测试。客户要求在 100 并发下，应用侧端到端的接口时延在 10 秒以内。MatrixOne 将平均性能水平控制在了 3 秒以内，比 MySQL 快了近 20 倍。而且针对部分要求更高的查询，MatrixOne 通过快速拉起新的计算节点进行瞬时的并行计算，可以进一步提高查询性能。

最后，为了确保 MatrixOne 在数据同步和迁移方面的能力，用户分别测试基于 DataX 及 FlinkCDC 的离线及实时方案。MatrixOne 均可以保持与 MySQL 表的数据一致性及秒级同步。

客户收益

通过采用 MatrixOne 的云原生 HTAP 解决方案，该电信运营商在车联网管理系统方面获得了显著的效益：

1.      性能提升：MatrixOne 的 OLAP 高性能查询性能显著提升了系统的响应速度，尤其是在处理复杂查询时，相比原有 MySQL 数据库，查询效率提升了数十倍，从而改善了应用开发模式及用户体验。

2.      成本优化：通过 MatrixOne 的容器化部署和资源池化管理，该运营商能够根据实际业务需求动态调整资源分配，避免了资源浪费，实现了成本的有效控制。

3.      运维简化：完全 K8s 容器化管理极大的简化了运维工作，使得数据库的扩展和管理更加自动化和便捷，降低了运维难度和工作量。同时使得数据库及应用的运维可以形成统一一套运维体系。

通过这些改进，该电信运营商不仅提升了车联网管理系统的性能和稳定性，还实现了成本的有效控制和业务的快速响应，为未来的发展奠定了坚实的基础。