Tair DRAM-based instances are suitable for scenarios that require high concurrency, high performance, and a large number of read and write operations on hot data. DRAM-based instances are designed to enhance multi-threading performance and incorporate a broad set of extended data structures developed in-house by Alibaba Cloud.
Purchase methods
Benefits
Item | Description |
Compatibility |
|
Performance |
|
Architecture |
|
Integration of multiple data modules |
|
Enterprise-grade feature |
|
Data security |
|
Common scenarios
Tair DRAM-based instances are suitable for scenarios such as live video streaming, flash sales, and online education. The following section describes typical scenarios:
Scenario 1: During flash sales, the number of QPS on some cached hotkeys may exceed 200,000. ApsaraDB for Redis Community Edition instances cannot meet this requirement.
Tair DRAM-based instances can efficiently handle requests during flash sales without performance issues.
Scenario 2: ApsaraDB for Redis Community Edition cluster instances have limits on database transactions and Lua scripts.
Tair DRAM-based instances provide high performance and eliminate the limits on the usage of commands in ApsaraDB for Redis Community Edition cluster instances.
Scenario 3: You have created a self-managed Redis instance that consists of one master node and multiple replica nodes. The number of replica nodes and O&M costs increase as your workloads increase.
Tair DRAM-based instances that use the read/write splitting architecture can provide one data node and up to five read replicas to help you handle millions of QPS.
Scenario 4: You have created a self-managed Redis cluster to handle tens of millions of QPS. The number of data shards and O&M costs increase as your workloads increase.
Tair DRAM-based instances can downsize clusters by two thirds and significantly reduce O&M costs.
Comparison between threading models
Threading model | Description |
Figure 1. Single-threading model of Redis | ApsaraDB for Redis Community Edition instances and native Redis databases use the single-threading model. During request handling, native Redis databases and ApsaraDB for Redis Community Edition instances must perform the following steps: read requests, parse requests, process data, and then send responses. In this scenario, network I/O operations and request parsing consume most of the available resources. |
Figure 2. Multi-threading model of Tair | To improve performance, each Tair DRAM-based instance runs on multiple threads to process the tasks in these steps in parallel.
Each DRAM-based instance reads and parses requests in I/O threads, places the parsed requests as commands in a queue, and then sends these commands to worker threads. Then, the worker threads run the commands to process the requests and send the responses to I/O threads by using a different queue. A Tair DRAM-based instance supports up to four concurrent I/O threads. Unlocked queues and pipelines are used to transmit data between I/O threads and worker threads to improve multi-threading performance. Note
|
The multi-threading model of Redis 6.0 consumes large amounts of CPU resources to deliver performance that is up to twice higher than that delivered by the single-threading model of a major version earlier than Redis 6.0. The Real Multi-I/O model of DRAM-based instances provides fully accelerated I/O threads to sustain a large number of concurrent connections and offer a linear increase in throughput.
Performance comparison
ApsaraDB for Redis instances use the same single-threading model as native Redis databases. In the single-threading model, each data node supports 80,000 to 100,000 QPS. Tair DRAM-based instances use the multi-threading model, which allows the I/O, worker, and auxiliary threads to process requests in parallel. Each data node of a DRAM-based instance delivers performance that is approximately three times that delivered by each data node of an ApsaraDB for Redis Community Edition instance. The following table describes the comparison between ApsaraDB for Redis instances and Tair DRAM-based instances of different architectures and their use cases.
Architecture | ApsaraDB for Redis instances | Tair DRAM-based instances |
Standard architecture | These instances are not suitable if the number of QPS that is required on a single node exceeds 100,000. | These instances are suitable if the number of QPS that is required on a single node exceeds 100,000. |
Cluster architecture | A cluster instance consists of multiple data nodes. Each data node provides performance that is similar to that of a standard instance. If a data node stores hot data and receives a large number of concurrent requests for the hot data, the read and write operations on other data that is stored on the data node may be affected. As a result, the performance of the data node deteriorates. | These instances provide high performance to read and write hot data at reduced maintenance costs. |
Read/write splitting architecture | These instances provide high read performance and are suitable for scenarios in which the number of read operations is greater than the number of write operations. However, these instances cannot support a large number of concurrent write operations. | These instances provide high read performance and can support a large number of concurrent write operations. These instances are suitable for scenarios in which a large number of write operations need to be processed but the number of read operations is greater than the number of write operations. |
Integration of multiple data modules
DRAM-based instances integrate a broad set of self-developed data modules to support more scenarios. These modules include exString (including commands that enhance Redis string functionality), exHash, exZset, GIS, Bloom, Doc, TS, Cpc, Roaring, Search, and Vector. These modules simplify business development in complex scenarios and allow you to focus on business innovation.
DRAM-based instances that are compatible with Redis 7.0 or 6.0 support all the preceding data structures.
DRAM-based instances that are compatible with Redis 5.0 support all the preceding data structures other than TairVector.
Data type | Tair extended data structure | Description | |
String | N/A |
Best practices: Implement high-performance optimistic locking by using TairString and Implement bounded counters by using TairString. | |
Hash | N/A | TairHash is a data structure that allows you to specify the expiration time and version number of a field. TairHash is more flexible in use and simplifies application development in most scenarios. This data structure is open-sourced. For more information, visit GitHub. Best practices: Manage multi-device logon from a single user by using TairHash | |
Zset | N/A | TairZset allows Double-type scores to be sorted with respect to 256 dimensions. You can use TairZset to implement general-purpose leaderboards and multidimensional leaderboards. This data structure is open-sourced. For more information, visit GitHub. Best practices: Implement multidimensional leaderboards by using TairZset and Implement distributed leaderboards by using TairZset. | |
GeoSpatial | N/A | TairGIS is a data structure that uses R-tree indexes and supports APIs related to a geographic information system (GIS). TairGIS can be used to query points, linestrings, and polygons. You can use TairGIS to check whether A contains B, whether A is contained by B, or whether A intersects with B. This data structure is open-sourced. For more information, visit GitHub. Best practices: Implement digital fences by using TairGIS and Implement local purchase services by using TairGIS. | |
Doc (JSON) | RedisJSON | Similar to RedisJSON, TairDoc is a data structure that supports the JSON standard and stores data of the document type. TairDoc data is stored as binary trees to allow quick access to child elements of JSON objects. | |
Search | RediSearch | TairSearch uses syntax similar to that of Elasticsearch but provides more and better tokenizers to improve query performance. | |
TimeSeries | RedisTimeSeries | Compared with RedisTimeSeries, TairTS extends the capability of tags. In the TairTS data structure, an extra hash layer is added to support your aggregate queries on timelines. You can also use TairTS to update or add data to historical time series data. Best practices: Implement fine-grained monitoring by using TairTS | |
Sketches | RedisBloom | TairBloom is compatible with RedisBloom, supports dynamic scaling, and provides 64-bit hash algorithms to significantly reduce the probability of collision for large amounts of data. The best practices of TairBloom include the implementation of recommendation and crawler systems. For more information, see Bloom. | |
N/A | TairCpc is a data structure developed based on the compressed probability counting (CPC) sketch. It allows you to perform high-performance computing on sampled data with a small amount of memory. TairCpc supports tumbling and sliding windows to better facilitate data streaming. It also supports common aggregation operators used in big data analytics, such as | ||
Bitmap | N/A | TairRoaring is an efficient computing module that provides high stability. It supports operations on multiple bitmaps, which improves performance and space efficiency. Best practices: Select users by using TairRoaring | |
Vector | Redis Search (Vector Similarity) | TairVector is an in-house data structure of Tair that provides high-performance real-time storage and retrieval of vectors. Best practices: |
Enterprise-grade features
Enterprise-grade feature | Description |
After you enable the data flashback feature for a Tair instance, Tair retains append-only file (AOF) backup data for up to seven days. During the retention period, you can specify a point in time that is accurate to the second to create an instance and restore the backup data at the specified point in time to the new instance. | |
After you enable the proxy query cache feature, the configured proxy nodes cache requests and responses for hotkeys. If the same requests are received from a client within the specified validity period, Tair retrieves the responses to the requests from the cache and returns the responses to the client. During this process, Tair does not need to interact with backend data shards. | |
Global Distributed Cache for Tair is an active geo-redundancy database system that is developed based on ApsaraDB for Redis. Global Distributed Cache supports business scenarios in which multiple sites in different regions provide services at the same time. It helps enterprises replicate the active geo-redundancy architecture of Alibaba. | |
Two-way data synchronization between Tair instances | Data Transmission Service (DTS) supports two-way data synchronization between Tair instances. This synchronization solution is suitable for scenarios such as active geo-redundancy and geo-disaster recovery. |
FAQ
What do I do if a client does not support commands from a new data module?
You can define the commands from the new data module in your application code before you use the commands in your client. You can also use a Tair client that provides built-in support for these commands. For more information, see Tair clients.