More than 70,000 vehicles are associated with a ride-hailing platform, and the number of vehicles keeps increasing rapidly. Each vehicle uploads data such as route and location data every minute to the platform. The platform stores the data in MySQL databases. The excessively large amount of data in the MySQL databases results in slow responses to online queries.
The amount of daily incremental data is about 100 GB, and the vehicle data needs to be stored for three years. Therefore, the total data in three years exceeds 100 TB. This causes high storage costs.
The ride-hailing platform adopts ApsaraDB for Lindorm (Lindorm) and optimizes its original architecture. The ride-hailing platform migrates the full data to Lindorm databases and uses Apache Kafka or Apache Spark to synchronize incremental data to Lindorm databases in real time. This reduces the storage capacity requirements for the on-premises databases of the platform.
The platform needs to store data of the last three years. However, only the data of the last month is frequently accessed. To meet this requirement, the platform can benefit from the tiered storage architecture of Lindorm. Lindorm uses Object Storage Service (OSS) buckets for cold storage. Lindorm can automatically migrate the cold data generated one month ago to OSS buckets and stores the data generated in the current month in ultra disks. The storage separation process is imperceptible to the platform. This frees the platform staff from code modification and O&M and also reduces the storage costs.
Operations staff can use the SQL script templates provided by Lindorm and Apache Phoenix to carry out daily O&M, such as finding the location of a car.
The storage costs are reduced after the Internet of Vehicles (IoV) data is stored in Lindorm databases.
Lindorm provides distributed storage services.
The new architecture can meet the ever-demanding business requirements of the platform even if the vehicle data keeps increasing.