Advantages over Open-Source Reds

Service scenarios

Has high requirements on:

• Data security
• System stability to prevent system breakdown during peak hours
• Data consistency

Is suitable if:

• The volume of data involved is small. GeminiDB Redis API helps enterprises lower their costs.
• The volume of data involved is large. GeminiDB Redis API can process data more easily than open-source Redis.

Has low requirements on:

• Low security, which means that core data may be lost or squeezed out of the cache by the LRU (Least Recently Used) page replacement algorithm.
• Low stability, which may cause out-of-memory (OOM) issues and breakdowns
• Data consistency during multi-point access

Is suitable if:

Only small volume of data is involved and the data is valid within a short period of time.

Cost

Cost reduced by 75% to 90%

GeminiDB Redis API supports full flush to disks and uses the GaussDB basic component service at low costs.

Extremely high hardware cost

All data of open-source Redis is stored in memory, and the fork mechanism results in low disk utilization.

Maximum capacity

PB-level data volume

Compute and storage resources are decoupled, so they can be scaled flexibly and separately at the same time to meet performance requirements.

100-GB data volume

As more and more data needs to be stored and processed, hardware costs of a Redis cluster increase sharply, and the Gossip protocol of the cluster becomes inefficient.

Capacity usage

100%

GeminiDB Redis API uses a self-developed architecture and is not affected by fork issues. Almost all the persistent storage space you purchased is available.

<50%

Open-source Redis is affected by the exclusive fork mechanism. The memory required will be doubled theoretically during peak hours when a snapshot is taken, data is replicated between master and slave nodes, or data is rewritten to an AOF file. The memory usage must be less than 50% to ensure data security.

Specifications

1 GB fine-grained and pay-per-use mode

Discontinuous options such as 32 GB, 48 GB, or 64 GB

Assume that the service data volume is about 30 GB. You can only buy a cloud Redis database of 64 GB storage considering that the efficient memory usage is less than 50%, which is a waste of resources.

Data compression

Logical compression and physical compression are combined, saving more space than open-source Redis.

• Logical compression: Values are preliminarily compressed.
• Physical compression: Data blocks in storage medium are compressed for the second time.
• Service tests show that GeminiDB Redis API uses 15% to 30% less space for storing data of common types like string and hash than open-source Redis.

Only logical compression is used.

Latency

The average latency is on par with open-source Redis', but the p9999 latency is higher.

The average latency and the p9999 latency are both low.

Write resistance

Strong

A multi-thread architecture is used, so multiple nodes support concurrent writes, making it easy to double the throughput.

Weak

A single-thread architecture is used, so only the master node in a Redis cluster supports writes. There are OOM risks during peak hours.

Data reliability

High

Data is flushed to disks in real time by command. Three copies of data are stored at the storage layer to avoid data loss.

Low

Memory data is flushed to disks in seconds, but asynchronous replication between master and slave nodes is not timely. This may cause data loss.

Data consistency

Strong

Three-copy storage ensures strong consistency, and dirty reads are prevented during multi-point access

Weak

Data is replicated asynchronously between master and slave nodes, so you may obtain inconsistent data if you access master and salve nodes at the same time.

Availability

High

GeminiDB Redis provides superlative fault tolerance (N-1 reliability).

Medium

• If half of master nodes of a Redis cluster are faulty, the cluster becomes unavailable.
• If any pair of master and slave nodes become faulty, the open-source Redis cluster is unavailable.

Fault recovery

Minute-level recovery. The data recovery duration is irrelevant to the data volume.

In the shared-everything architecture, data can be taken over immediately by available nodes, requiring little time to load.

The larger the data volume is, the longer the restoration takes.

Data is physically distributed on multiple independent nodes. During fault recovery, RDB snapshots are loaded from disks to the memory, which takes a long time.

Load balancing

Supported

Fine-grained data sharding and dynamic load balancing between nodes are supported.

Not supported

Third-party components are required.

Scale out

Seamless scale-out

• Node scale-out: completed in minutes and service awareness in seconds.
• Capacity expansion: completed in seconds without service interruption.
• In the shared-everything architecture, underlying data can be accessed by any node. Capacity expansion is fast and does not require data replication and migration.

Time-consuming and great impact on services

Data shards are stored in the memory of each node. Data migration means that new nodes are added and data is replicated and migrated, which is time-consuming.

Security

High

• Huawei-developed architecture eliminates security vulnerabilities of open-source Redis.
• The security system consists of VPCs, subnets, security groups, Anti-DDoS, and SSL, which collectively can defend against a wide range of attacks to keep your data secure.

Low

• The open-source Redis kernel has security vulnerabilities, such as CVE-2021-32761. If the version is not upgraded in a timely manner, your data may be at risk.
• Network security depends on reliability of the cloud service you used.

O&M

One-stop services

GeminiDB Redis database expert teams provide mature migration solutions, real-time monitoring, fault warning, and 24/7 support.

Depends on quality of the cloud service you used.