instance types, engine versions, architectures, and storage mediums of Tair - Tair

When you create a Tair instance, you want to 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 Tair to help you select instances.

Select a Tair instance

In most cases, you select instance types and specifications based on your performance, price, scenario, and workload needs. For example, you 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.

Step	Operation	Description
1	Select a series type	Tair provides DRAM-based, persistent memory-optimized, and ESSD-based instances to suit your performance, cost-effectiveness, and large-capacity needs.
2	Select an architecture	Tair provides instances that run the standard, cluster, 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.
3	Select a disaster recovery solution	A Tair instance may fail due to unexpected reasons, such as a device or power failure in a data center. In this case, disaster recovery can help ensure data consistency and service availability. Tair provides multiple disaster recovery solutions for different use cases.
4	Estimate the memory size	We recommend that you estimate the memory size to be consumed. This reduces costs and prevents your business from being affected by frequent specification changes.

After you perform the preceding steps, use the Tair console or a Tair API operation to create a Tair instance. For more information, see the "Create a Tair instance" section of this topic.

Note

After you create and start to use a Tair 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 type and specifications of the instance are suitable. For more information, see the "Verify and adjust the selected instance" section of this topic.

Select a series type

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, data persistence, and reduced overall costs. Additionally, Tair provides you with higher performance, more data structures, and more flexible storage methods. This helps you meet business requirements in different scenarios.

Scenario	Recommended series type	Benefit
Performance-centric business scenarios	DRAM-based instances	Provides ultra-high performance. These instances use the multi-threading model to provide read and write performance three times that of native Redis databases or ApsaraDB for Redis Community Edition instances of the same specifications. For more information, see Performance whitepaper of Redis 5.0-compatible Tair DRAM-based instances and Performance whitepaper of Redis 6.0-compatible Tair DRAM-based instances. Provides a variety of self-developed enhanced data modules. These modules include exString (including commands that enhance Redis string functionality), exHash, GIS, Bloom, Doc, TS, Cpc, exZset, Roaring, Vector, and Search. With these modules, you can spend less time writing code, improve business performance, and focus on innovation. Provides enterprise-class features, such as data flashback based on point-in-time recovery (PITR), proxy query cache, and Global Distributed Cache for Tair. Supports enterprise-class encryption methods, such as Transport Layer Security (TLS) encryption and transparent data encryption (TDE). For more information, see Enable TLS encryption and Enable TDE.
Data cache and storage scenarios that require high performance and high data persistence, and may incur high costs	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 storage scenarios that require large capacity at low costs, involve only infrequent data access, and can bear high access latency	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 whitepaper of ESSD-based instances. Stores data in cloud disks. These instances store data in ESSDs to ensure high data reliability. The capacity of an 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 structures and commands of open source Redis.

For more information about the supported commands and parameters, see Overview and Parameters that can be configured for Tair instances.

Cloud disk-based or local disk-based instances

If you want to create a DRAM-based instance, you can choose between the cloud disk-based and local disk-based deployment modes. The following table describes the comparison between these two deployment modes.

Item	Cloud disk-based instance (recommended)	Local disk-based instance
Architecture	Uses the new-generation management architecture that offers greater flexibility and enhanced scalability. This architecture serves as a basis for subsequent development.	Uses the conventional management architecture. Cluster instances come with predefined specifications that cannot be changed.
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 9.	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.

Note

For more information, see Comparison between cloud disk-based instances and local disk-based instances.

Select an architecture

Tair 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.

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 Tair. Stable query rate on a single node of your Tair 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 and read/write splitting 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 your 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 Tair.

Select a disaster recovery solution

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 a power 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.

Estimate the memory size

To create a Tair instance, you must estimate the size of memory to be consumed based on the following factors and select the most suitable memory specifications. This reduces costs and prevents your business from being affected by frequent specification changes.

Important

When you determine the memory size of a Tair instance, you must first consider the volume of the business data to be stored. Then, you must take into account the memory that is required for the operation of the instance itself, such as the memory that is occupied by the process metadata, replication buffer, and fragments. Unlike an open-source Redis database, when you use a Tair instance, you do not need to consider the memory overhead associated with copy-on-write forking during Tair persistence or advanced features of Tair such as whitelist configuration, audit logging, large key management, and hotkey management. The preceding memory overhead is borne by Alibaba Cloud and is not counted towards 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 time to live (TTL) and eviction policy of keys. The key eviction policy can be specified by using the maxmemory-policy parameter. For more information, see Parameters that can be configured for Tair instances.
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 a Tair instance

After you determine the instance type and specifications, you can create a Tair instance by using the Tair console or a Tair API operation. For more information, see the following topics:

Console: Create a Tair instance
API operation: CreateTairInstance

Verify and adjust the selected instance

Tair supports a variety of metrics. After you create and start to use a Tair 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 type and specifications are suitable. 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.

If the performance monitoring data of a Tair instance indicates high memory usage, you must check whether an exception exists. If no exceptions exist, upgrade the instance specifications. For more information, see Change the configurations of an instance. For more information about how to troubleshoot performance issues for Tair instances, see the following topics: