Enterprise-Level Features

GeminiDB Redis API uses a cloud-native distributed architecture designed to decouple storage resources from compute resources and is fully compatible with Redis 7.0, 6.2 (including 6.2.X), 5.0 and earlier editions, so it provides more enterprise-grade features.

• Exclusive resources, no traffic limiting for shards
  • Compute nodes are deployed in exclusive containers. Tenants are isolated from each other, ensuring high stability. In the case of high concurrent traffic, traffic on nodes is unlimited.
  • Built-in exclusive load balancers provide higher forwarding performance and stability.
  • Public IP addresses can be bound to compute nodes, facilitating cloud migration and remote debugging.
• Second-level auto scaling, easily coping with service peaks and valleys
  • Independent scaling is supported for storage and compute resources. A single instance supports up to tens of millions of QPS and 36 TB capacity.
  • In scenarios where data volume increases, capacity expansions can be performed with a few clicks, without affecting service applications.
  • In scenarios where workloads increase suddenly (for example, gaming and e-commerce activities have higher QPS requirements), you can expand the capacity by adding nodes or increasing specifications. In the future, you can easily reduce the capacity. Only second-level reconnection may occur to services.
• A unified database used to simplify the service architecture
  • With high-performance storage pools, instances automatically load frequently accessed hot data to the memory of compute nodes and exchange cold and hot data internally. Services preferentially read hot data from the memory, ensuring high data reliability and low latency.
  • GeminiDB Redis API is suitable for storing ever-increasing important service data (such as game player data, user profiles, behavior logs, and article information). Compared with the Redis+MySQL architecture, it has a simpler architecture, more reliable data storage, and higher comprehensive performance and cost-effectiveness.
• 3-AZ deployment
  • 3-AZ instances allow compute and storage resources to be evenly distributed across the AZs. The deployment rules strictly comply with anti-affinity groups, delivering ultra-high reliability.
  • If a node is faulty, services can be taken over in seconds. With the dedicated, decoupled storage and compute, GeminiDB Redis API provides fault tolerance (N-1 reliability) to allow you to restore service access in seconds, achieving ultra-high availability.
• Account management for database-level permission control
  • A maximum of 65,536 databases can be used, and up to 200 subaccounts can be created.
  • You cannot only set read-only or read/write permissions for sub-accounts, but also configure accessible databases for sub-accounts, preventing misoperations between tenants.
• Setting an expiration time for each field of a hash key
  • Open-source Redis supports only the setting of the expiration time for all hash keys. GeminiDB Redis API adds a group of hash commands. This allows you to set an expiration time for a specified field in a hash key and implement the elimination logic at the service layer in the database, simplifying the service architecture.
  • For details about the best practices of EXHASH, see EXHASH for Ad Frequency Control.
• Strong data consistency, preventing dirty reads
  • Open-source Redis adopts asynchronous replication, and data copies are weakly consistent. In common service scenarios where counters, rate limiters, and distributed locks are used, dirty reads may occur, which may cause service logic disorder.
  • GeminiDB Redis API connects data copies to a high-performance storage pool. Once data is successfully written into the storage pool, the three copies of data are stored consistently, preventing dirty reads from occurring in subsequent service access.
• Enhanced transactions
  • The transaction MULTI/EXEC is supported. Compared with the open-source Redis, GeminiDB Redis API has transactions complying with the ACID feature. It supports rollback from the bottom of its architecture, to meet transaction atomicity.
• Better prefix scanning
  • When you run a SCAN command, for example, match prefix*, on an instance, the scanning performance is much higher than that of open-source Redis. GeminiDB Redis API optimizes the complexity of delivering commands to O(logN + M), where N indicates the overall data volume and M indicates the matched data volume. However, for open-source Redis, the complexity of scanning commands is O(n).