Updated on 2025-09-04 GMT+08:00

Enterprise-Level Features

GeminiDB Redis API uses a cloud-native distributed architecture designed to decouple storage resources from compute resources and is 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.
  • Autoscaling in seconds, easily coping with traffic fluctuations
    • Storage and compute resources can be scaled independently. A single instance supports tens of millions of QPS and dozens of TB of storage space.
    • When data volume increases, you can scale up storage with a few clicks without interrupting applications.
    • To handle sudden surges in traffic (for example, games and e-commerce activities with higher QPS requirements), you can add nodes or increase specifications. You can also easily reduce the nodes or specifications in the future. It takes only milliseconds to re-establish a network connection.
  • 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 can set read-only or read/write permissions as well as accessible databases for subaccounts to prevent misoperations between tenants.
  • Setting an expiration time for each field of a hash key
    • Redis only supports an overall expiration time for 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, no 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 instance data can be stored in a high-performance storage pool and backed up automatically, using strong consistency, three-copy storage. In this way, dirty reads will not occur.
  • Enhanced transactions
    • The MULTI/EXEC transaction 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. The scanning complexity of open-source Redis is O(N), which is slower.
  • Real-time persistence
    • GeminiDB Redis API uses the persistence mechanism of write-ahead logging (WAL) to ensure data atomicity and durability. To ensure write performance, a response is returned immediately after data is written to the OS buffer. Data is written to disks in real time asynchronously to ensure real-time persistence and high-speed low-latency writes.