What Is GeminiDB Redis API?

GeminiDB Redis API is a database service compatible with Redis 7.0, 6.0, 5.0, and 4.0. With high availability, reliability, and scalability, GeminiDB Redis instances support the following types: primary/standby, proxy cluster, and Redis Cluster. A single instance can store hundreds of terabytes of data and handle tens of millions of QPS. GeminiDB Redis API can meet requirements for high throughput, low latency, specification changes, and large capacity.

Enterprise-class Features and Advantages

Ease of use:

GeminiDB Redis API is compatible with Redis 7.0 and earlier versions and supports primary/standby, proxy cluster, and Redis Cluster instances.
Third-party clients, such as Jedis and Redisson, can access GeminiDB Redis API without refactoring.
You can use Huawei Cloud Data Replication Service (DRS) to migrate data from self-managed Redis to GeminiDB Redis API.
You can monitor instance statuses, configure alarms, change specifications, and back up instances.

High scalability:

Thanks to decoupled storage and compute, storage and compute resources can be scaled separately. A single instance can handle tens of millions of QPS and store tens of terabytes of data, meeting demands for high concurrency and large capacity.

When data volume increases, you can scale up storage from hundreds of GB to several TB in seconds without interrupting applications.
When service requests increase sharply (for example, during game play and e-commerce promotions), you can scale out or up resources without downtime. No data migration is required, and only seconds of jitter may occur.
GeminiDB Redis API uses a multi-thread architecture. A single node supports 1 to 32 vCPUs, and you can change the specifications on the console. The QPS can increase linearly as CPUs are added. GeminiDB Redis API is well-suited for fluctuating workloads.

High reliability:

3 AZs: Compute and storage resources are evenly distributed across three AZs, ensuring high reliability.
Ultra-high availability: Decoupled storage and compute can tolerate N-1 node failures, and faulty nodes can be taken over within seconds.

Enterprise-class features:

Standard and capacity-oriented instances with shared storage support reads and writes on all nodes, improving resource utilization and system performance.
By offering a compression rate four times higher than open-source Redis, GeminiDB Redis API significantly reduces storage costs.
Bloom filters are supported.
You can set an expiration time for a specified field in a hash key. This simplifies the service architecture as the elimination logic is implemented in the database.
GeminiDB Redis API offers Point-In-Time Recovery (PITR), which allows you to restore a database to its previous state before any errors occurred.
DB Cache can automatically transfer data from RDS for MySQL or TaurusDB to GeminiDB Redis instances, simplifying service development.
Enhanced transactions: Unlike open-source Redis, GeminiDB Redis API supports ACID. If any operation fails, the entire transaction is rolled back, leaving the database unchanged.
Enhanced prefix scan: Compared with open-source Redis, GeminiDB Redis API reduces the time complexity of matching a specified prefix (match prefix*) from O(N) to O(logN + M), accelerating the retrieval efficiency.

Storage, Product, and Instance Types

Storage Type

GeminiDB Redis supports the classic and cloud native storage with different storage pools. You can access and use the two storage types in the same way. If both classic and cloud native storage types are available in the same region, the classic storage is preferred.

**Table 1** Storage types
Storage Type	Description
Classic	Classic storage uses a traditional architecture. A large storage pool ensures stability and reliability. Classic storage requires more initial resources and supports fewer regions than cloud native storage.
Cloud native	Cloud native storage is a more flexible, new-gen version with support for more AZs.

Product Type

Standard, capacity-oriented, and performance-enhanced instances are supported. Each type has different focus on performance and costs.

**Table 2** Product types
Product Type	Description
Standard	The memory is not limited. Hot data is stored in the memory, and cold data is stored in high-performance NVMe SSDs. Storage can reach twice the memory. Standard instances offer high I/O performance, reliability, and low costs, with response latency of just sub-milliseconds and 30% lower costs. Standard instances can be used in most scenarios.
Capacity-oriented	Capacity-optimized instances provide large-capacity SSDs, and the storage can reach 20 times the instance memory. The cost is up to 90% lower than open-source Redis. Large-capacity key-value storage is provided, suitable for average performance requirements and expectations of low costs.
Performance-enhanced	Performance-enhanced instances provide high I/O performance and can handle up to millions of QPS per shard, with low latency.

Standard and capacity-oriented instances both read data from memory first. If the data is not found in memory, data is read from the high-performance SSDs. Standard instances can cache most data in memory, which achieves higher performance. Capacity-oriented instances are suitable for big data scenarios where the memory hit ratio is relatively low. In most scenarios, data needs to be read from SSDs. Performance-enhanced instances can read all data from memory, achieving higher QPS with lower latency.

DB Instance Type

Primary/Standby, proxy cluster, and Redis Cluster are supported. For details, see Instance Type.

**Table 3**
DB Instance Type	Description
Primary/Standby	A primary/standby instance is compatible with a standalone Redis node and Redis Sentinel. A maximum of 32 vCPUs and 128 GB of memory are supported. Compared with a proxy cluster instance, a primary/standby instance has limited scalability and the standby node cannot be read or written. So proxy cluster is recommended.
Proxy cluster	In a sharded cluster, a proxy cluster GeminiDB Redis instance is connected through proxies to a standalone Redis instance, Redis Sentinel, and Redis Cluster. This type is easy to use. Sharding is not a concern.
Redis Cluster	With the native Redis Cluster architecture, a Redis Cluster GeminiDB Redis instance is directly connected to Redis Cluster. No proxy is required. Clients are directly connected to shards, so a single shard can handle more QPS with lower latency. Up to 128 nodes are supported.