Case Study of iQIYI’s Adoption of TiDB for Scalable High‑Availability Database Services

iQIYI, a leading Chinese video entertainment provider, launched in April 2010 and has rapidly grown its user base. The company’s original MySQL clusters faced severe bottlenecks: limited single‑instance storage, growing table sizes that slowed queries, and the need for frequent data deletion.

Since mid‑2017, iQIYI evaluated TiDB and began deploying TiDB clusters within its database cloud department. After TiDB 2.0’s release, the company migrated several critical services—Edge Control Center, Video Transcoding, and User Login Information—to TiDB.

1. Edge Control Center stores machine security statistics and provides periodic statistical queries. TiDB was chosen over Apache Druid for its flexible aggregation and full MySQL compatibility, reducing migration cost. The deployment included a dedicated TiDB cluster, a TokuDB backup cluster, TiDB‑Binlog for real‑time data replication, a custom load‑balancing middleware, and Prometheus‑Grafana monitoring with alert integration.

Key issues encountered and resolved:

Connection timeouts caused by stale statistics; solved by TiDB’s automatic statistics collection.

Long index‑building times due to delayed DDL updates and oversized Regions; addressed by PingCAP’s Region batch‑split improvements.

Minor TiKV node errors during version upgrades (e.g., "region is unavailable", "tikv server timeout"); mitigated by retry mechanisms.

The system demonstrated stable query performance despite continuous data growth, thanks to TiDB’s automatic sharding (default 96 MB per region) and sophisticated scheduling.

2. Video Transcoding required long‑term storage of historical transcoding data for analysis. A TiDB‑Lightning pipeline was built to import data directly as SST files into TiKV, achieving 1 TB migration in 5–6 hours. After migration, traffic was shifted to TiDB, and the service has run stably.

3. User Login Information faced massive data volume and complex sharding logic in MySQL. Migration to TiDB eliminated the need for sharding, simplified the data access layer, and leveraged TiDB’s indexing for fast queries. Incremental synchronization used PingCAP’s Syncer tool, which supports multi‑source, multi‑table aggregation and automatic conflict resolution.

TiDB’s multi‑datacenter deployment ensures high availability: each TiKV node is labeled, PD automatically schedules reads to appropriate replicas, and Drainer enables point‑in‑time and reverse synchronization.

Overall, iQIYI found TiDB solved the primary pain points of horizontal scalability and high availability, outperforming traditional MySQL + proxy architectures, especially as data volume grows.

Future Plans include testing TiDB for mixed OLTP/OLAP workloads with TiSpark, optimizing TiSpark’s impact on OLTP, deploying dedicated TiDB clusters for OLAP, contributing PRs to enhance TiDB‑Binlog, and integrating TiDB with downstream systems such as Kudu and HBase.