Qihoo 360’s Use of MongoDB: Architecture, Practices, and Lessons Learned

Qihoo 360 Technology Co., Ltd. is a leading Chinese internet company with about 500 million monthly active PC users and over 640 million mobile users as of June 2014, providing comprehensive security products and services for both internet and mobile platforms.

Since 2011, Qihoo has been an early adopter of MongoDB, initially using version 1.8, and has since built more than 100 different applications on the platform, running over 1,500 instances daily and handling roughly 20 billion queries.

Three representative use cases illustrate their workload:

Location‑based mobile search : Leveraging MongoDB’s geospatial indexes to deliver location‑aware search results to mobile users, processing about 1.2 billion queries per day.

Single sign‑on (SSO) authentication cache : Storing SSO session data in MongoDB to support tens of thousands of concurrent users, handling around 30 k operations per second and 1.8 billion queries per day.

Log analysis platform : Streaming logs from Linux, Apache, and Tomcat servers directly into MongoDB, where 2.5 billion documents are stored across 18 shards, with about 1 billion write operations per day.

In addition to MongoDB, Qihoo also uses MySQL for relational workloads and Redis for high‑concurrency caching. Migrations to MongoDB are driven by the need for better scalability and flexible data modeling.

The majority of their applications run on PHP on x86 hardware with CentOS, using SSD‑backed MongoDB instances (versions 2.4, 2.6, and testing 3.0). Deployments span multiple data centers across China, employing replica sets and sharding to achieve high availability and disaster recovery.

Management of MongoDB clusters is handled through the internal "HULK" private‑cloud platform, which provides one‑click deployment, scaling, monitoring, and backup. Backup strategies include full backups (by temporarily stopping a replica set member), incremental backups based on the oplog, and delayed replication for rapid recovery in critical scenarios.

Best‑practice recommendations shared by the team include:

Accurately assess business scenarios, data volume, and QPS, adding a safety margin (e.g., 50 %) to estimates.

Prefer SSD storage for latency‑sensitive workloads, as MongoDB’s performance heavily depends on disk I/O.

Monitor and periodically reclaim disk fragmentation caused by high write/delete workloads.

MongoDB’s flexible document model enabled rapid development; for example, during the 2014 Yunnan earthquake, a new application was designed, coded, and launched within a single workday.

The team is eager for MongoDB 3.0, especially for document‑level concurrency control and compression, which would improve write scalability and reduce storage costs on SSDs.

Advice for prospective MongoDB users emphasizes disciplined schema design: avoid storing multiple unrelated data dimensions in a single collection, keep collections focused, and use tooling to detect oversized or overly complex documents.