All Products
Search
Document Center

ApsaraDB for Redis:Instructions for selecting an appropriate ApsaraDB for Redis instance

Last Updated:Jan 16, 2024

When you create an ApsaraDB for Redis instance, you must select the most cost-effective and stable instance type that can suit your performance, price, scenario, and workload needs. This topic describes the instance types, engine versions, architectures, and storage mediums of ApsaraDB for Redis to help you select instances.

Selection procedure

In most cases, you select instance types and specifications based on your performance, price, scenario, and workload needs. For example, you may want to use instances as high-speed caches or in-memory databases. The following table describes the recommended selection procedure.

Note

When you select an instance, you can use the price calculator to obtain the prices of different instance specifications. For more information, see Price calculator.

Operation

Description

Select Community Edition or Enhanced Edition (Tair)

ApsaraDB for Redis is available in Community Edition and Enhanced Edition (Tair). Enhanced Edition (Tair) is developed based on Tair to provide higher performance, more data modules, and more flexible storage methods. Tair is an internal service of Alibaba Cloud.

Select cloud disk-based or local disk-based instances

We recommend that you select a cloud disk-based instance.

Select a deployment architecture

ApsaraDB for Redis provides instances that use the standard architecture, cluster architecture, or read/write splitting architecture. You can select an architecture that suits your business data volume and your requirements for read and write capabilities and business performance.

Select a disaster recovery solution

An ApsaraDB for Redis instance may fail due to unexpected reasons, such as a device failure or a power failure in a data center. In this case, disaster recovery can help ensure data consistency and service availability. ApsaraDB for Redis provides a variety of disaster recovery solutions to meet the requirements of different business scenarios.

Select a major version

We recommend that you use the latest major version that is bundled with more features.

Estimate the memory size

We recommend that you estimate the size of memory that is required. This reduces costs and prevents your business from being affected by frequent specification changes.

Create an ApsaraDB for Redis instance

After you perform the preceding operations, you can create an ApsaraDB for Redis instance by using the ApsaraDB for Redis console or by calling an API operation of ApsaraDB for Redis.

Check and adjust the instance capabilities

After you create and start to use an ApsaraDB for Redis instance, monitor the performance of the instance when your business is running as expected. This allows you to check whether the instance meets your expectations.

Select Community Edition or Enhanced Edition (Tair)

ApsaraDB for Redis is available in Community Edition and Enhanced Edition (Tair). Enhanced Edition (Tair) is an in-memory enterprise-grade database service that is developed based on Tair. Tair is an internal service of Alibaba Cloud. Enhanced Edition (Tair) provides a variety of series of instances based on storage mediums such as dynamic random-access memory (DRAM), non-volatile memory (NVM), and enhanced SSDs (ESSDs) to meet your requirements for low-latency access, persistence, and reduced overall costs. Enhanced Edition (Tair) provides you with higher performance, more data modules, and more flexible storage methods. This meets your business requirements in different scenarios.

Important

Edition

Series type

Feature

Scenario

Enhanced Edition (Tair)

DRAM-based instances

Performance-centric business scenarios

Persistent memory-optimized instances

  • Offers ultra-high cost-effectiveness. The price of persistent memory-optimized instances is 30% lower than that of ApsaraDB for Redis Community Edition instances with the same capacity. The performance of persistent memory-optimized instances reaches 90% of that of native Redis databases. For more information, see Performance white paper of persistent memory-optimized instances.

  • Supports enhanced data modules. These modules include exString (including commands that enhance Redis string functionality), exHash, and Cpc.

  • Prevents data loss caused by power failure. These instances implement persistence for each command. The system returns a success response for each write operation only after the data is persistently stored. You can use persistent memory-optimized instances as in-memory databases instead of caches.

Data caching and storage scenarios that require high performance and high data persistence, and can bear high costs

ESSD-based instances

  • Reduces costs. These instances reduce up to 85% of costs compared with ApsaraDB for Redis Community Edition instances. For more information, see Performance white paper of ESSD-based instances.

  • Stores data in cloud disks. These instances store data in ESSDs to ensure high data reliability. The capacity of a ESSD-based instance reaches hundreds of terabytes.

  • Optimizes memory usage for large Redis databases. These instances reduce the amount of memory that is reserved for the forks of native Redis databases.

  • Offers high compatibility. These instances are compatible with most data modules and commands of open source Redis.

Data storage scenarios that require a large capacity and low costs, involve only infrequent data access, and can bear high access latency

Community Edition

N/A

Community Edition instances are compatible with open source Redis and provide high performance.

Standard Redis usage and data migration scenarios

Select cloud disk-based or local disk-based instances

The following table compares cloud disk-based instances and local disk-based instances.

Item

Cloud disk-based instance (recommended)

Local disk-based instance

Architecture

Uses the new-generation Tair management architecture.

Note

This architecture serves as a basis for subsequent development.

Uses the conventional Tair management architecture that comes with a complete set of features.

Scalability

  • Cloud disk-based instances provide higher scalability than local disk-based instances.

  • No transient connections occur when you scale out a cluster instance.

  • You can change the number of data shards in a cluster instance within the range of 2 to 256 and with a minimum step size of 1. Additionally, a data shard can be scaled up or down. This capability allows you to effectively address various requirements for performance and capacity in different scenarios.

  • You can change the number of read replicas in a read/write splitting instance within the range of 1 to 5.

  • A scale-out consumes more time.

  • Transient connections occur when you scale out a cluster instance.

  • In a scale-out, you can only double the number of data shards in a cluster instance. For example, if the original cluster instance has two shards, you can scale the instance to four or eight shards.

  • The number of read replicas in a read/write splitting instance is fixed at 1, 3, or 5.

Select a deployment architecture

ApsaraDB for Redis instances support three deployment architectures. You can select an architecture that suits your business data volume and your requirements for read and write capabilities and business performance.

Figure 2. Deployment architecture comparison部署架构对比

Note

The following table describes the high availability (HA) architectures. The standard and cluster architectures also support standalone instances without HA that are suitable for tests and cache-only use cases.

Architecture

Description

Scenario

Standard architecture

Standard instances adopt a master-replica architecture. The master node serves your workloads, whereas the replica node stays in hot standby mode to ensure HA. If the master node fails, the system switches the workloads to the replica node within 30 seconds after the failure occurs. This ensures the HA of your instance.

  • Support for more native Redis features.

  • Persistent storage in ApsaraDB for Redis.

  • Stable query rate on a single node of your ApsaraDB for Redis instance.

  • Use of simple commands, where only a few sorting and computing commands are required.

Cluster architecture

  • An instance that uses the cluster architecture contains proxy nodes, data shards, and the Configserver. You can scale out a cluster instance by increasing the number of data shards.

  • A cluster master-replica instance contains multiple data shards. Each data shard works in an HA architecture in which a master node and a replica node are deployed on different devices. If the master node fails, the cluster master-replica instance fails over to the replica node to ensure HA.

  • Large data volume.

  • High queries per second (QPS).

  • High throughput and high performance.

Read/write splitting architecture

  • A read/write splitting instance contains proxy nodes, master and replica nodes, and read replicas.

  • Read replicas support chained replication. This allows you to add read replicas to increase the read capacity.

  • High QPS scenarios, such as scenarios in which hot data is frequently accessed.

  • Support for more native Redis features. You can use read/write splitting instances to overcome the limits of cluster instances. For more information, see Limits on commands supported by cluster instances.

Note

Data synchronization to read replicas has a latency. Therefore, in scenarios that require high data consistency, we recommend that you use cluster instances instead of read/write splitting instances.

Note

Cluster instances are available in the following connection modes:

  • Proxy mode: Proxy nodes forward requests from clients to the data shards in the instance. This mode provides features such as load balancing, read/write splitting, failover, proxy query cache, and persistent connections. The proxy query cache feature is supported only for DRAM-based instances. For more information, see Features of proxy nodes.

  • Direct connection mode: You can bypass proxy nodes and directly connect to backend data shards of your instance in a similar manner as you connect to an open source Redis cluster. Compared with the proxy mode, the direct connection mode reduces the routing time and accelerates the response of ApsaraDB for Redis.

Select a disaster recovery solution

Figure 3. Disaster recovery evolution of ApsaraDB for RedisRedis容灾架构演进

Disaster recovery solution

Protection level

Description

Single-zone HA solution

★★★☆☆

The master node and the replica node are deployed on different machines in the same zone. If the master node fails, the HA system performs a failover to prevent service interruption caused by a single point of failure (SPOF).

Zone-disaster recovery solution

★★★★☆

The master node and the replica node are deployed in two different zones of the same region. If the zone in which the master node resides is disconnected due to force majeure factors such as an outage or network failure, the HA system performs a failover to ensure continuous availability of the entire instance.

Cross-region disaster recovery solution

★★★★★

In the architecture of Global Distributed Cache, a distributed instance consists of multiple child instances that synchronize data among each other in real time by using synchronization channels. The channel manager monitors the health status of child instances and handles exceptions that occur on child instances, such as a switchover between the primary and secondary databases. Global Distributed Cache is suitable for scenarios such as geo-disaster recovery, active geo-redundancy, nearby application access, and load balancing. For more information, see Overview.

Select a major version

You can select a major version based on your business requirements. Each major version is maintained on a long-term basis. We recommend that you use a newer major version to support more features. For more information, see New features and compatibility changes of major versions of Redis.

You must consider the following limits when you select a major version.

Instance and its creation method

Supported instance edition and series type

Supported engine version

Supported architecture

Local disk-based instance

Create a local disk-based instance

ApsaraDB for Redis Community Edition

5.0

4.0

Cluster architecture

Standard architecture

Read/write splitting architecture

Enhanced Edition (Tair) DRAM-based instances

5.0

Cluster architecture

Standard architecture

Read/write splitting architecture

Cloud disk-based instance

Create an ApsaraDB for Redis cloud disk-based instance

ApsaraDB for Redis Community Edition

7.0

6.0

5.0

Standard architecture

Cluster architecture

Read/write splitting architecture

Enhanced Edition (Tair) DRAM-based instances

6.0

5.0

Standard architecture

Cluster architecture

Read/write splitting architecture

Enhanced Edition (Tair) persistent memory-optimized instances

6.0

Standard architecture

Cluster architecture

Read/write splitting architecture

Enhanced Edition (Tair) ESSD-based instances

4.0

Standard architecture

Estimate the memory size

To create an ApsaraDB for Redis instance, you must estimate the size of memory required based on the following factors and select the most suitable memory specifications. This reduces costs, prevents your business from being affected by frequent specification changes, and allows you to migrate your business to the cloud at a faster pace.

Important

When you determine the memory size of an ApsaraDB for Redis instance, you must first consider the volume of the business data to be stored. In addition, you must take into account the memory required for the operation of the instance itself, such as the memory occupied by the process metadata, replication buffer, and fragments.

For self-managed Redis databases, you must consider the memory overhead caused by the write-time replication of forks and advanced features such as whitelist configuration, audit logging, large key management, and hotkey management. If you use ApsaraDB for Redis instances, the preceding memory overhead is borne by Alibaba Cloud and is not included in the memory size of the purchased instance.

  • The data types, lengths, and quantity of keys.

    Note

    If a key, such as a key of the hash type, contains elements, you must consider the quantity and lengths of these elements.

  • The lengths of values.

  • The expiration time and eviction policy of each key.

  • The access model. For example, if the access model involves a large number of client connections, Lua scripts, or transactions, you must reserve memory for them.

  • Medium- and long-term business growth.

Create an ApsaraDB for Redis instance

After you perform the preceding operations, you can create an ApsaraDB for Redis instance by using the ApsaraDB for Redis console or by calling an API operation of ApsaraDB for Redis. For more information, see the following topics:

Check and adjust the instance capabilities

ApsaraDB for Redis supports a variety of metrics. After you create and start to use an ApsaraDB for Redis instance, we recommend that you monitor the performance of the instance when your business is running as expected. This allows you to check whether the instance meets your expectations. For more information, see View performance monitoring data.

Note

You can also use the Redis-benchmark tool to perform a performance stress test. For more information, see Redis-benchmark instructions.

For example, if the performance monitoring data of an ApsaraDB for Redis instance indicates high memory usage, you must check whether an anomaly exists. If no anomaly exists, upgrade the instance specifications. For more information, see Change the configurations of an instance. For more information about how to troubleshoot performance issues for ApsaraDB for Redis instances, see the following topics: