tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

Release Notes and Announcements
Release Notes
Announcements
User Tutorial
Product Introduction
Overview
Product Strengths
Use Cases
Storage Engine
Product Series
Product Versions
Specifications and Performance
Read/Write Separation
Multi-AZ Deployment
Regions and AZs
Terms
Service Regions and Service Providers
Purchase Guide
Billing Overview
Pricing Center
Instance Purchasing
Renewal (Yearly/Monthly Subscription)
Refund (Yearly/Monthly Subscription)
Overdue Payments
Switching from Pay-as-You-Go to Yearly/Monthly Subscription
Getting Started
Quickly Creating an Instance
Connecting to Redis Instance
Operation Guide
Operation Overview
Connecting to a Database Instance
Managing Instances
Upgrade Instance
Management Node (Redis/ValKey Edition)
Multi-AZ Deployment Management
Backup and Restoration
Managing Accounts
Parameter Configuration
Slow Query
Access Management
Network and Security
Monitoring and Alarms
Event Management (Redis/ValKey Edition)
Data Migration
Global Replication for Redis Edition
Performance Optimization
Sentinel Mode
Development Guidelines
Naming Rules
Basic Usage Guidelines
Design Principles of Key and Value
Command Usage Guidelines
Design Principles of Client Programs
Connection Pool Configuration
Command Reference
Command Reference Overview
Redis Edition and Valkey Edition Command Compatibility
Version Command Usage Differences
Differences Between the Proxy Architecture and Direct Connection Mode
More Command Operations (Redis/Valkey Edition)
Memcached Edition Command Compatibility
Practical Tutorial
Building TencentDB for Redis® Client Monitoring Based on Spring Boot
Redis Client Connection Configuration Policy and Practice
Global SCAN Guide for Cluster Architecture
Eliminating Instances Securely
Hot Key and Big Key
AZ Migration Scheme
Troubleshooting
Connection Exception
Exception Analysis and Solution of Redisson Client Timeout Reconnection
Performance Troubleshooting and Fine-Tuning
API Documentation
History
Introduction
API Category
Making API Requests
Instance APIs
Parameter Management APIs
Other APIs
Backup and Restoration APIs
Region APIs
Monitoring and Management APIs
Log APIs
Data Types
Error Codes
FAQs
General
Connection and Login
Purchase
Service Agreement
Service Level Agreement
Terms of Service
Glossary
Contact Us

Design Principles of Key and Value

PDF
Focus Mode
Font Size
Last updated: 2024-11-05 10:22:22

Key Design Principle

Redis keys should be readable and manageable. We recommend that you not use an ambiguous and long key name.
Conciseness: Shorten the length of Key while ensuring the semantic meaning. When there are large number of keys, they take up more space, so simplify the key name. For example, simplify cx:cxdb:cxdb_user_info:000110011 to cx:cxdb:user:000110011.
Naming rule: It can only contain letters, digits, symbols (|_.:) and start with a letter.
Semantic segmentation: Separate words with the same business logic meaning by English semicolons (:); while separate words with same business logic meaning by English periods (.), indicating a complete semantic meaning.
Readability: To improve readability, Key name should end with the value type of the key, such as user:basic.info:userid:string.
Do not use a long key name, as a long key name takes up space too.
The key name can’t contain symbols, such as \\, *, ?, {}, [], (), space, single and double quotes, and escape characters.

Key lifecycle policy

We recommend that you set the expiration time with expire command to control the lifecycle for keys.
> set cx:cxdb:user:000110011 xiaoming
> expire cx:cxdb:user:000110011 3600  # set the key to expire one hour later
Distribute expiration time evenly , preventing the centralized expiration.
For data without expiration set, pay attention to the idletime and clean it up when the it is very large. For example, execute > object idletime cx:cxdb:user:000110011 ,
and the returned information is shown below:
:(integer) 150039   # It indicates that the key has not been accessed for 150039 seconds.
Clear the cold data which has not been accessed for more than 1 month.

Value Design Principle

Reject big key

A big key indicates that the key has a large value and takes more space. The following are examples of big keys in common Redis data structures:
In String data structure, the value of a string takes up space more than 10 MB (a large value).
In Set data structure, there are 10000 values (a large number of members) in a set.
In List data structure, there are 10000 values (a large number of members) in a list.
In Hash data structure, there are only 1000 values, but the total value reaches 1000 MB (a large total value) in a hash table.
Big key is prone to causing slow queries, blocking other requests. It also poses EIN under pressure To prevent the creation of big keys, we have provide you with the following suggestions:
Maintain the value in String type within 10 KB; maintain the members in hash, list, set, and zset within 5000.
Don’t delete big keys unless necessary.
For non-string big keys, we recommend that you delete them with the hscan, sscan, zscancommand in a progressive manner.
Prevent big keys from being deleted automatically upon expiration.
For example, setting a zset with 2 million members to expire in 1 hour can trigger a deletion operation, causing blocking.

Select proper data type

Redis provides various data types, including strings, hash tables, lists, sets, and sorted sets. An appropriate data type can improve the performance and reliability of Redis.
Strings: It is suitable for storing the simple string data, such as configuration information and counters. To store binary data, use Redis binary-safe string.
Hash tables: It is suitable for storing data with multiple fields and values, such as user information and product information. Hash tables can save memory space and support easy batch operations.
List: It is suitable for storing ordered element set, such as message queues and task lists. List allows you you to insert and delete operations at both ends, and operate list by various commands provided by Redis.
Set: It is suitable for storing unordered element set, such as tag lists and friend lists. Set allows you to perform operations such as union, intersection, difference. You can operate sets by using various commands provided by Redis.
Sorted set: It is suitable for storing ordered element set, such as leaderboards, voting lists. Sorted set allows you to sort based on scores. You can operate ordered sets by using various commands provided by Redis.
Control and use memory encoding optimization configurations for data structures in a reasonable way. For example, ziplist, as a special data structure, can store small lists, hash tables, and sorted sets in a continuous memory block, which saves memory. As ziplist does not have an index, linear scanning is required for operations such as search, insertion, or deletion on ziplist, which may compromises performance. Therefore use ziplist as needed in your actual business. ziplist may be a good choice for a scenario where data volume is small and frequent traversal operations are required. Try other data structures in other scenarios.
Replace String with HashMap structure for a key with multiple attributes. HashMap is a key-value data structure in Redis for storing multiple fields and values. In Redis, you can use the HSET command to store multiple fields and values in a hash table, and get the value of the specified field by using HGET command. To store multiple attributes in String structure, you need to use a specified delimiter to concatenate them into one string. But this operation is complicated and memory-consuming.

Negative example

set user:1:name tom
set user:1:age 19
set user:1:favor football

Positive example

hmset user:1 name tom age 19 favor football



Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback