MOI connects procurement document parsing, item confirmation, multi-source research, supplier recommendations, price analysis, and report export in one evidence-backed workflow.
China Mobile IoT Company is a wholly-owned subsidiary of China Mobile, the world's largest mobile operator by subscriber count. It specializes in IoT hardware, connectivity modules and smart device manufacturing, managing large-scale procurement of components such as 5G CPE terminals, connectivity modules and industrial gateways.
This project centres on the operator's connected-vehicle business, where it provides real-name authentication and connectivity management for data SIMs supplied to automakers. Three core systems — the connected-vehicle real-name registration platform, the 5G intelligent connected management platform, and the automaker real-name registration business platform — each ran on its own MySQL 8.0 database, totalling over 2 TB and growing by hundreds of gigabytes a year. The systems already served dozens of automaker customers, with over a hundred expected.
Rising concurrency pushed MySQL into performance bottlenecks. Relief came from manual sharding, which raised operational cost and made both reads and writes more complicated.
Multi-table joins were worse: queries could take minutes or upwards of ten minutes. The team had to reshape data structures to avoid joining more than three tables and push a great deal of computation up into the application, which then became the thing that slowed down.
Hardware utilization was also poor. Capacity had been planned against an optimistic commercial scale, so every MySQL primary-standby cluster sat on very high-specification physical machines — up to 80 cores and 504 GB. In practice the business was still early, and load spiked only when an automaker ran a batch activation, so most of the time the hardware idled. Under broad cost-reduction pressure, that was an uncomfortable position for the business unit.
The answer had to fix the data architecture without a large rewrite of existing business logic, which is what a cloud-native HTAP approach on MatrixOne offered.
MatrixOne is designed for containers and deploys natively on Kubernetes. With storage and compute fully separated, CN compute nodes and TN transaction nodes both run stateless in Kubernetes-managed containers and can be started, stopped or scaled at any time; the storage layer runs on object storage and scales accordingly; and the stateful write-log nodes are made reliable by three-replica Raft. When load rises, a single operational command adds CN compute nodes in seconds, transparently to the application.
Container-based pooling means underlying compute is drawn on demand. Early in the business, with light load, MatrixOne runs on smaller and fewer compute containers; as load grows, one command scales those containers vertically or horizontally in seconds. Resources consumed track resources needed, which is what lifts hardware utilization.
Multi-tenancy completes the picture. Within one MatrixOne cluster, different tenants log in to entirely separate data spaces, and one or more CN compute nodes can be pinned to a given tenant to isolate compute load. So all the database hardware under the three business applications can be pooled, with each application living as a tenant in a shared cluster.
The POC began with deployment on Kubernetes and object storage. MatrixOne covered all three business systems using 76 vCPU, 304 GB of memory and 4 TB of object storage — close to 80% less than the previous one-primary-one-standby MySQL physical machines.
Application compatibility was tested next: of 43 application interfaces, 42 passed on the first attempt. The one exception traced to a non-standard use of MySQL integer-to-string type conversion; the customer corrected the code on our recommendation and the 43rd interface passed.
Performance testing followed on the more demanding interfaces. The customer's requirement was end-to-end application latency within 10 seconds at 100 concurrent users; MatrixOne held average performance under 3 seconds, close to 20× faster than MySQL. For the heaviest queries, spinning up additional compute nodes for instantaneous parallel execution improves that further.