Why GaussDB for Redis Outperforms Open‑Source Redis: Architecture, Benefits, and Real‑World Performance

What is GaussDB for Redis?

GaussDB for Redis (Gauss Redis) is a NoSQL database that implements the Redis protocol while providing persistent storage.

Limitations of open‑source Redis

AOF bloat : Append‑Only File grows continuously; rewrite requires a fork that doubles memory usage and blocks performance.

Snapshot backup : Consistent snapshots use copy‑on‑write via fork, causing kernel‑level locking and performance jitter.

Master‑slave lag : Asynchronous replication can lose data or become inconsistent under heavy write load, leading to buffer buildup and possible OOM.

Fork overhead : Fork reserves an extra copy of memory and adds locking, limiting vertical scaling.

Capacity limits : Fork and inefficient gossip‑based cluster management hinder both vertical and horizontal scaling.

Why compute‑storage separation?

Separating compute from storage enables elastic scaling, better resource utilization, and aligns with multi‑AZ/region cloud‑native deployments. Database services have evolved through three generations:

Dedicated physical servers (first generation).

Virtual machines or containers hosting the database (second generation).

Stateless compute layer + durable storage layer with strong consistency (third generation).

Architecture of GaussDB for Redis

The system consists of a compute layer and a storage layer built on Huawei’s Distributed File Volume (DFV) system.

Compute layer

cfgsvr

, proxy, datanode modules.

Data is first written to RocksDB, then transformed into SST files by GeminiFS (a user‑space file system), and finally pushed to DFV.

Storage layer

DFV provides three‑replica strong consistency, elastic expansion, and high availability. It is also used by other Huawei services such as EVS, OBS, and block storage.

Network and tenancy

Tenant resources are deployed on anti‑affinity physical machines within the same VPC, ensuring data isolation. Compute containers are dedicated per tenant, while storage resources are shared.

Disaster recovery

Region‑level 3‑AZ strong consistency : Writes are acknowledged after a majority of three replicas across three AZs persist (RPO = 0, RTO < 10 s).

Cross‑region asynchronous replication : An Rsync‑Server captures write logs, encodes them, and forwards them to a standby instance for replay. Supports bidirectional sync, breakpoint continuation, and conflict resolution per Redis data structure.

Key advantages

Strong consistency : DFV’s three‑replica mechanism ensures client responses only after all replicas commit.

High availability : N‑1 compute node failures are tolerated without data migration, thanks to shared storage and automatic slot takeover.

Hot‑cold separation : Frequently accessed data stays in memory; less active data is evicted to persistent storage automatically.

Elastic scaling : Compute and storage can be scaled independently; storage scaling often requires only quota adjustment.

High performance : Utilizes RDMA, user‑space protocols, and persistent‑memory optimizations, delivering double‑digit performance gains over traditional Redis in both in‑memory and out‑of‑memory workloads.

Implementation notes

Gauss Redis belongs to the Gauss NoSQL family, which provides a distributed KV engine, a user‑space file system, and a storage pool. The compute modules interact with DFV via its SDK to select local and remote AZ storage nodes for majority writes. The cross‑region Rsync‑Server handles log capture and replay, with conflict‑resolution algorithms tailored to each Redis data type.