Enterprise-Level Features

GeminiDB Redis APIs uses a cloud-native distributed architecture with decoupled storage and compute and is fully compatible with Redis 6.2, 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 are 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 10 million-level 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.
  • The 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, this API has a simpler architecture, more reliable data storage, and higher comprehensive performance and cost-effectiveness.
• 3-AZ deployment
  • 3AZ instances allow compute and storage resources to be evenly distributed in three 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. In the unique storage and compute decoupling architecture,GeminiDB Redis API provides fault tolerance (N-1 reliability) to allow you to restore service access in seconds, achieving ultra-high availability.
• Cross-region active-active DR
  • GeminiDB Redis API supports enterprise-level active-active DR capabilities. You can create two independent instances (in the same region or across regions) and establish a DR relationship. If one instance is faulty, the other instance can continue to provide reliable database services.
  • It also provides bidirectional data synchronization and resumable data transfer.
• 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. A group of hash commands are added to the GeminiDB Redis API. 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 Solution 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.
  • The 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).