MOI 将采购材料解析、标的物确认、内外部寻源、供应商推荐、价格分析与报告导出串成一条完整流程，为采购人员提供有来源依据的决策支持。
中移物联网是中国移动的全资子公司，在物联网领域深耕多年，为企业与个人提供智能连接、设备管理、数据采集与分析等核心服务，采购团队每季度需完成大量品类的寻源比价。
本次与 MatrixOne 合作的项目主要面向于车联网相关的业务。在车联网业务中，该运营商主要为车企提供流量卡实名认证，连接管理等服务。其核心系统由三个核心部分组成：车联网实名登记平台、5G 智能网联管理平台和车企实名登记业务平台，这三个平台分别采用一套 MySQL 8.0 数据库，目前总数据量达 2TB+。同时每年新增数据量达数百GB，该系统已支持数十家车企客户，未来预期增加至百余家。
高并发请求的增加导致 MySQL 数据库出现性能瓶颈，用户只能手动通过分表形式来分散压力，运维成本较高，读写操作都较为复杂。
面对多表关联操作，MySQL 的查询性能会慢到几分钟甚至十几分钟。用户不得不对数据结构进行精细的修改，以避免进行三表以上的 join 操作，同时把大量的计算压力由业务应用来完成，这样会经常导致应用层的性能受到影响。
系统整体硬件使用率不高。由于业务初期规划是以较大的商业规模来估算的，因此实际上每套系统底层的MySQL主备集群都配备了非常高规格的物理机，最大使用到80核504G内存。但是实际上因为业务发展还处于早期，以及车企仅会在批量进行开通操作的时候才会有一定业务洪峰，而绝大部分情况下硬件使用率较低。在整体大环境降本增效的背景下，业务部门的IT成本压力较大。
为了解决当前车联网数据架构中的关键挑战，同时避免对现有业务逻辑进行大规模改造，基于MatrixOne的云原生HTAP解决方案应运而生。
MatrixOne 作为一款完全面向容器而设计的云原生数据库，天然支持了 K8s 容器环境部署。同时 MatrixOne 是完全存算分离的数据库，CN 计算节点及TN事务管理节点均运行在基于K8s管理的容器上，这两种节点均无状态，可以随时启停或者扩展。存储层运行在对象存储上，天然具备很强的扩展性。需要有状态保证的写入日志节点通过三副本的 Raft 协议来保证可靠性。因此其天然可以利用容器平台超强的扩展能力，来实现扩展性。在业务负载上升的时候，仅需1条运维命令即可秒级无感知的增加 CN 计算节点来匹配更高的业务并发量。
MatrixOne 基于容器的池化能力，可以按需调用底层计算资源，在业务发展初期，整体负载压力较小的时候，MatrixOne 可以使用较小和较少的计算容器节点。而在业务负载逐渐加大的时候，MatrixOne 仅需一条简单的运维命令即可秒级对现有计算容器节点进行垂直扩展或者水平扩展，这也实际使用的底层资源始终可以匹配业务需要的资源，可以极大的提高硬件使用率。
MatrixOne 支持多租户能力，在一套 MatrixOne 集群内，允许用户用不同的租户登陆，将完全看见不一样的数据空间，同时可以将1个或多个 CN 计算节点绑定到不同的租户上，确保计算负载的隔离性。因此用户三套业务应用底层的所有数据库硬件均可以被池化，而上层每套业务应用数据库可以作为一个 MatrixOne 集群中的租户存在，共享一套 MatrixOne 集群。这种使用模式将进一步提高硬件整体使用率。
客户在详细了解 MatrixOne 的整体技术细节之后，明确了要进行数据库云原生化改造的方案，项目开始进入到 POC 实施阶段。
首先进行了基于 K8s 及对象存储部署的测试，MatrixOne 整体使用了76 vCPU，304G 的内存资源，及4TB的对象存储资源，即完成了面向三套业务系统的整体部署，比过去1主1备的 MySQL 物理机资源整体少了近80%。
其次进行了业务应用适配性的测试，业务侧准备了43个应用接口进行测试，42个接口测试一次性通过，其中1个应用接口因为碰到了 MySQL 在整型和字符串数据类型转换方面不正规的使用方式而出现差异，在我们的建议下客户修正了自己的代码，并通过了第43个接口的测试。
第三，我们对相对性能要求较高的部分业务接口进行了性能测试。客户要求在100并发下，应用侧端到端的接口时延在10秒以内。MatrixOne 将平均性能水平控制在了3秒以内，比 MySQL 快了近20倍。而且针对部分要求更高的查询，MatrixOne 通过快速拉起新的计算节点进行瞬时的并行计算，可以进一步提高查询性能。