Why Pika Beats Redis for Large-Scale KV Storage: Advantages, Ops, and Real-World Use

Background

As business traffic grows, users demand a fast yet durable KV cache. Redis provides AOF persistence, but large memory footprints cause oversized AOF files, lengthy bgrewriteof operations, and expensive memory costs. Pika was created by 360 DBA and infrastructure teams as a disk‑based, Redis‑compatible storage system that eliminates memory bottlenecks while supporting master‑slave replication, full and partial sync, and migration tools for seamless transition.

01 Pika vs Redis

Pika complements rather than replaces Redis, serving scenarios where Redis’s data volume exceeds memory capacity, thereby reducing cost by using disk space.

Advantages

Capacity: No memory limit; storage size equals available disk space.

Fast DB loading: Data is persisted on write, so node restarts recover without full memory reload or replay.

Quick backup: Backup speed approximates cp copy time, enabling rapid full‑sync for large databases.

Disadvantages

Performance: Disk‑based design is slower than pure in‑memory Redis, though SSDs narrow the gap.

Multi‑threaded Pika can match or exceed Redis’s single‑threaded command throughput in many benchmarks.

02 Pika Usage at 360

Over 2,000 master‑slave instances run internally, supporting more than 80% of 360’s services (mobile browser, video, cloud storage, feed, search, etc.). Codis‑based Pika clusters handle millions of QPS and terabytes of data, with several clusters deployed in search and anti‑fraud services. External users also adopt Pika (see Qihoo360/Pika repository).

03 Business Benefits

Using Pika reduces memory costs, improves backup speed, and maintains Redis‑compatible APIs, allowing applications to switch without code changes.

04 HULK Cloud Platform Automation

HULK, 360’s private cloud platform, integrates Pika as a unified Redis‑like service. Users request new Pika instances via the HULK portal, choosing storage packages (10 GB–100 GB) and deployment options (single‑ or multi‑datacenter, master‑slave topology).

04‑01 Pika Instance Request

Applications submit requests through the HULK UI; DBA approves them on the management console.

04‑02 Management Operations

The console supports creating, decommissioning, maintaining, reconfiguring, and scaling instances, as well as master‑slave role switches, port expansion, and online parameter editing. Maintenance mode suppresses alerts during troubleshooting; role changes are auto‑detected; consoles provide direct DB access.

04‑03 Monitoring

HULK displays per‑port metrics such as capacity usage, client connections, request rates, memory, CPU, and key counts.

04‑04 Alerting & Self‑Healing

Zabbix alerts are routed via internal messaging and SMS. Automated remediation handles replication errors, role mismatches, and node failures, dramatically reducing manual intervention.

04‑05 Data Migration

When Redis memory limits are reached, workloads migrate to Pika via the HULK‑integrated Redis DTS tool, supporting seamless Redis‑to‑Pika data transfer.

04‑06 Upgrades

Most clusters run Pika 3.2.8; newer deployments use 3.3.6. Upgrade procedures involve port expansion, coordinated master‑slave upgrades, data directory restructuring, and script‑guided version transitions.

04‑07 Backup & Recovery

Agents perform daily bgsave backups, syncing to remote storage. HULK monitors backup status, logs failures, and periodically validates restores by randomly selecting ports for test recovery, reporting results via email.

Summary

For over five years, 360 has operated thousands of Pika instances across multiple business lines with high stability. Continuous development, DBA collaboration, and open‑source contributions to the OpenAtom foundation have expanded Pika’s ecosystem, positioning it as a widely applicable solution for large‑scale KV storage.