StarRocks Adoption and Application Practices at 360: Performance Comparison and Use Cases

Before adopting StarRocks, 360 relied on a mixture of MySQL, Hive, Spark, Druid and other engines for analytical queries, each with specific strengths but also notable limitations in scalability, latency, and operational complexity.

To meet real‑time ingestion and sub‑second query requirements, the team evaluated columnar OLAP databases—Doris, StarRocks and ClickHouse—using a 40‑core CPU, 128 GB RAM testbed and the SSB 100 GB benchmark. StarRocks showed middle‑range import speed (better than Doris, slower than ClickHouse) while consuming the least CPU and delivering superior query performance over both Doris and ClickHouse in single‑ and multi‑table tests.

Beyond raw performance, StarRocks offers simpler operations (FE/BE nodes with auto‑scaling), richer external table support (MySQL, Iceberg, Hive), transactional capabilities, and advanced features such as vectorized pipelines, CBO optimizer, federated queries, materialized views, and bitmap indexes, making it a better fit for 360’s diverse workloads.

In production, StarRocks is used in two main ways: native OLAP tables (loaded via Flink streaming, Kafka, Spark load, broker load, or HTTP streaming) and external tables that query data directly from MySQL, Iceberg, and Hive without prior import. These capabilities power several internal products, including a data analysis platform, a user‑profile platform, and a search‑advertising reporting system, each replacing legacy architectures that suffered from high‑volume MySQL sharding, Druid’s limited set handling, and Hive/TiDB’s slow joins.

The migration from an existing Doris cluster to StarRocks (first to 1.18, then to 1.19) yielded 20‑30% faster query responses, demonstrating the practical benefits of the upgrade path and the compatibility of metadata between the two systems.