Design Principles of Key and Value

다운로드

포커스 모드

폰트 크기

마지막 업데이트 시간: 2026-09-07 14:45:19

AI 번역

Distributed Cache supports multiple storage engines, including Redis, Valkey, and Memcached. This document defines the design principles for keys and values in a cache instance, helping you standardize data model design during development to improve cache performance and maintainability.
I. Key Design Principles
Keys should be named with readability and manageability in mind. Avoid using keys with unclear meanings or excessively long Key names.
Principle
Description
Conciseness
Shorten the Key length appropriately while ensuring semantics. When there are many keys, the memory space occupied by keys cannot be ignored.
Naming Rules
Start with an English letter. Only uppercase letters, lowercase letters, digits, vertical bars, underscores, English periods (.), and English half-width colons (:) can appear in the name.
Semantic Segmentation
Separate different business logic meanings with an English half-width colon (:). Separate words within the same business logic meaning segment with an English half-width period (.). This is used to represent a complete semantic unit.
Readability
End the Key name with the Value type it represents to improve readability. For example: user:basic.info:userid:string.
Length Limit
An excessively long Key name also occupies a certain amount of memory space. It is recommended to keep it within 128 bytes.
Special Characters Prohibited.
Do not use \\, *, ?, {}, [], (), spaces, single or double quotation marks, escape characters, and so on. Otherwise, the Key may become unsearchable or fail to be retrieved.
Correct example:
Example
Description
cx:cxdb:user:000110011
Concise and semantically clear, using colons for hierarchical structuring.
user:basic.info:userid:string
Separate words within the same semantic segment with periods, ending with the Value type.
Incorrect example:
Example
Issue
cx:cxdb:cxdb_user_info:000110011
The table name redundantly contains the database name "cxdb", which is redundant and increases the Key length.
set user 000110011
The Key contains spaces, which are special characters prohibited for use.
II. Key Lifecycle Guidelines
Set an expiration time using the expire command to control the lifecycle of keys.
# Write a Key
> set cx:cxdb:user:000110011 xiaoming
﻿
# Set the Key to expire in one hour
> expire cx:cxdb:user:000110011 3600
Distribute expiration time evenly , preventing the centralized expiration.
For data without an expiration time, focus on the idletime. Clean up the data when the idletime is very large.
Clear the cold data which has not been accessed for more than 1 month.
View an example of Key idle time:
> object idletime cx:cxdb:user:000110011
(integer) 150039   # This indicates that the Key has not been accessed for 150,039 seconds.
Note:
If possible, add a random offset to the expiration time (for example, base TTL ± random seconds) to prevent cache avalanche caused by a large number of keys expiring simultaneously.
III. Value Design Principles
3.1 Avoiding Big Keys
A big Key is characterized by a large Value associated with the Key in a cache instance, which occupies a significant amount of memory space. This is essentially a big Value problem. Common examples for different data structure types are listed below:
Data Structure Type
Big Key Identification Criteria
Issue Description
String
The Value exceeds 10 MB.
Excessively large data value
Set
The number of members exceeds 10,000.
Excessive number of members
List
The number of members exceeds 10,000.
Excessive number of members
Hash
The number of members exceeds 1,000, and the total size of member Values is 1,000 MB.
Excessively large total volume of members
Big keys can easily cause slow queries, block other requests, and also burden the network card. To prevent big keys, follow these guidelines when designing values:
Guideline
Description
Control Value Size
Keep the String type within 10KB. For Hash, List, Set, and Zset, keep the number of elements under 5000.
Avoid Directly Deleting Big Keys.
Do not use del to delete big keys unless necessary.
Progressive Deletion
For non-string big keys, it is recommended to use hscan, sscan, and zscan for progressive deletion.
Monitor Automatic Deletion Upon Expiration
Prevent issues caused by the automatic deletion of big keys upon expiration. For example, setting a 1-hour expiration for a Zset with 2 million elements triggers a del operation, causing blocking.
3.2 Selecting Appropriate Data Types
Cache instances support various data structure types, including strings, hashes, lists, sets, and sorted sets. Selecting the appropriate data structure type improves cache performance and reliability.
Data Structure Type
Application scenarios
Description
String
Simple string data, such as configuration information, counters, and so on
If you need to store binary data, you can use the binary-safe string type.
Hash
Data with multiple fields and values, such as user information, product information, and so on.
It can save memory space and facilitates batch operations.
List
Ordered collection of elements, such as message queues, task lists, and so on
It supports insertion and deletion operations at both ends.
Set
Unordered collection of elements, such as tag lists, friend lists, and so on
Supports union, intersection, difference, and other operations.
Sorted Set
Ordered collection of elements, such as leaderboards, voting lists, and so on.
It is sorted by score and supports range queries.
3.3 Memory Encoding Optimization
Properly control and use memory encoding optimization configurations for data structures. For example, ziplist is a special data structure that can store small lists, hashes, and sorted sets in a contiguous memory block, thereby saving memory space.
Scenario
Recommendation
Small data volume with frequent traversal needs
Use ziplist for better memory efficiency.
Large data volume with frequent insertion, deletion, or lookup needs
Avoid using ziplist. Consider using other data structures instead.
Note:
ziplist lacks an index, so lookup, insertion, or deletion operations require linear scans, which may cause performance degradation with large data volumes. Decide whether to enable it based on the specific data volume and access patterns.
3.4 Using Hash Instead of Multiple Strings
If a Key has multiple attributes, consider using the Hash type instead of the String type. Hash is a key-value pair storage data structure that can store multiple fields and values. Use the HSET command to store multiple fields and values in a hash table, and then use the HGET command to obtain the value of a specified field. If you use the String type to store multiple attributes, you need to use a specific delimiter to concatenate different attribute values into a single string, which complicates operations and may waste memory space.
Bad example: Using multiple String types to store the attributes of a single object leads to Key proliferation and prevents atomic operations.
set user:1:name tom
set user:1:age 19
set user:1:favor football
Running Environment
Operating System: Ubuntu 24.04.3 LTS / x86_64
Runtime Version: GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
Good example: Use the Hash type to aggregate multiple attributes of a single object into one Key, reducing the number of Keys and supporting atomic operations.
hmset user:1 name tom age 19 favor football

도움말 및 지원

문제 해결에 도움이 되었나요?

더 자세한 내용은 문의하기 또는 티겟 제출 을 통해 문의할 수 있습니다.

피드백

tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

Design Principles of Key and Value

I. Key Design Principles

II. Key Lifecycle Guidelines

III. Value Design Principles

3.1 Avoiding Big Keys

3.2 Selecting Appropriate Data Types

3.3 Memory Encoding Optimization

3.4 Using Hash Instead of Multiple Strings

Running Environment

도움말 및 지원

Principle	Description
Conciseness	Shorten the Key length appropriately while ensuring semantics. When there are many keys, the memory space occupied by keys cannot be ignored.
Naming Rules	Start with an English letter. Only uppercase letters, lowercase letters, digits, vertical bars, underscores, English periods (`.`), and English half-width colons (`:`) can appear in the name.
Semantic Segmentation	Separate different business logic meanings with an English half-width colon (`:`). Separate words within the same business logic meaning segment with an English half-width period (`.`). This is used to represent a complete semantic unit.
Readability	End the Key name with the Value type it represents to improve readability. For example: `user:basic.info:userid:string.`
Length Limit	An excessively long Key name also occupies a certain amount of memory space. It is recommended to keep it within 128 bytes.
Special Characters Prohibited.	Do not use `\\`, `*`, `?`, `{}`, `[]`, `()`, spaces, single or double quotation marks, escape characters, and so on. Otherwise, the Key may become unsearchable or fail to be retrieved.

Example	Description
`cx:cxdb:user:000110011`	Concise and semantically clear, using colons for hierarchical structuring.
`user:basic.info:userid:string`	Separate words within the same semantic segment with periods, ending with the Value type.

Example	Issue
`cx:cxdb:cxdb_user_info:000110011`	The table name redundantly contains the database name "cxdb", which is redundant and increases the Key length.
`set user 000110011`	The Key contains spaces, which are special characters prohibited for use.

Data Structure Type	Big Key Identification Criteria	Issue Description
String	The Value exceeds 10 MB.	Excessively large data value
Set	The number of members exceeds 10,000.	Excessive number of members
List	The number of members exceeds 10,000.	Excessive number of members
Hash	The number of members exceeds 1,000, and the total size of member Values is 1,000 MB.	Excessively large total volume of members

Guideline	Description
Control Value Size	Keep the String type within 10KB. For Hash, List, Set, and Zset, keep the number of elements under 5000.
Avoid Directly Deleting Big Keys.	Do not use del to delete big keys unless necessary.
Progressive Deletion	For non-string big keys, it is recommended to use hscan, sscan, and zscan for progressive deletion.
Monitor Automatic Deletion Upon Expiration	Prevent issues caused by the automatic deletion of big keys upon expiration. For example, setting a 1-hour expiration for a Zset with 2 million elements triggers a del operation, causing blocking.

Data Structure Type	Application scenarios	Description
String	Simple string data, such as configuration information, counters, and so on	If you need to store binary data, you can use the binary-safe string type.
Hash	Data with multiple fields and values, such as user information, product information, and so on.	It can save memory space and facilitates batch operations.
List	Ordered collection of elements, such as message queues, task lists, and so on	It supports insertion and deletion operations at both ends.
Set	Unordered collection of elements, such as tag lists, friend lists, and so on	Supports union, intersection, difference, and other operations.
Sorted Set	Ordered collection of elements, such as leaderboards, voting lists, and so on.	It is sorted by score and supports range queries.

Scenario	Recommendation
Small data volume with frequent traversal needs	Use ziplist for better memory efficiency.
Large data volume with frequent insertion, deletion, or lookup needs	Avoid using ziplist. Consider using other data structures instead.