KeyとValueの設計原則

ダウンロード

フォーカスモード

フォントサイズ

最終更新日: 2026-10-20 18:20:58

AI翻訳

Distributed CacheはRedis、Valkey、Memcachedなどの複数のストレージエンジンをサポートしています。本書では、キャッシュインスタンスにおけるKeyとValueの設計原則を定義し、開発プロセスにおいてデータモデル設計を規範化し、キャッシュのパフォーマンスと保守性を向上させるために役立ちます。
一、Keyの設計原則
Keyの命名には可読性と管理性が求められます。意味が不明瞭なKeyや、極端に長いKey名の使用は推奨されません。
原則
説明
簡潔性
セマンティクスを保証する前提で、Keyの長さを適宜短縮できます。Keyが多い場合、Keyが占有するメモリ領域も無視できません。
命名規則
英文字で始め、命名には大文字と小文字の英字、数字、縦線、アンダースコア、英文ドット（.）および英文半角コロン（:）のみを使用できます。
意味的分割
異なる業務ロジックの意味は英文半角コロン（:）で区切り、同一業務ロジック意味セグメント内の単語間は英文半角ドット（.）で区切って、完全な意味を表します。
可読性
Key名は、Keyが表すValueの型で終わるようにして、可読性を高めます。例えば、user:basic.info:userid:string。
長さ制限
Key名が大きすぎると一定のメモリ領域を占有します。128バイト以内に制御することをお勧めします。
特殊文字の使用を禁止します。
\\、*、?、{}、[]、()、スペース、単一引用符と二重引用符、エスケープ文字などの使用は禁止です。そうでない場合、Keyを検索できないか、検索に失敗する可能性があります。
正しい例：
例
説明
cx:cxdb:user:000110011
簡潔で意味が明確であり、コロンを使用して階層化します。
user:basic.info:userid:string
同一意味セグメントはドットで区切り、Value 型で終了します。
悪い例：
例
問題
cx:cxdb:cxdb_user_info:000110011
テーブル名にデータベース名「cxdb」が重複して含まれており、冗長であり、Keyの長さが増加します。
set user 000110011
Keyにスペースが含まれており、使用が禁止されている特殊文字です。
二、Keyのライフサイクル基準
expireを使用して有効期限を設定し、Keyのライフサイクルを制御することをお勧めします。
# Keyを書き込みます。
> set cx:cxdb:user:000110011 xiaoming
﻿
# Keyの有効期限を1時間後に設定します。
> expire cx:cxdb:user:000110011 3600
条件が許せば、有効期限を分散させて、集中失効を防ぐことができます。
有効期限が設定されていないデータについては、idletimeに重点的に注意してください。idletimeが非常に大きい場合はクリーンアップを行ってください。
あるKeyが1か月以上アクセスされていない場合、コールドデータとみなしてクリーンアップを行うことができます。
Keyのアイドル時間を確認する例：
> object idletime cx:cxdb:user:000110011
(integer) 150039   # このKeyが150039秒間アクセスされていないことを示します。
説明：
条件が許せば、有効期限にランダムなオフセットを追加することをお勧めします（例えば、基本TTL ± ランダム秒数）。これにより、大量のKeyが同時に集中して期限切れになり、キャッシュ雪崩が発生するのを防ぎます。
三、Valueの設計原則
3.1 大規模Keyの拒否
大Keyは具体的には、キャッシュインスタンス内のKeyに対応するValueが非常に大きく、メモリ空間を大きく占有するという形で現れ、本質的には大きいValueの問題です。データ構造の種類によって、一般的な例は以下の通りです：
データ構造タイプ
大Key判定条件
問題説明
String
値が10MBを超えています。
データ値が大きすぎます。
Set
メンバー数が10000個を超えています。
メンバー数が多いです。
List
メンバー数が10000個を超えています。
メンバー数が多いです。
Hash
メンバー数が1000個を超え、かつメンバー全体のValue値サイズが1000MBです。
メンバー全体のサイズが大きすぎます。
大Keyはスロークエリを引き起こしやすく、他のリクエストをブロックし、同時にネットワークカードにも負担をかけます。大Keyの発生を防ぐために、Valueを設計する際は以下の基準を参考にすることをお勧めします：
基準
説明
Value のサイズを制御してください。
String型は10KB以内に制御します。Hash、List、Set、Zsetの要素数は5000を超えないようにします。
大規模なKeyの直接削除は避けてください。
必須でない限り、delを使用して大規模なKeyを削除しないでください。
段階的な削除
非文字列の大規模なKeyについては、hscan、sscan、zscanを使用して段階的に削除することをお勧めします。
期限切れによる自動削除に注意してください。
大規模なKeyの有効期限切れによる自動削除問題を防止します。例えば、200万件のZsetに1時間の有効期限を設定すると、del操作がトリガーされ、ブロッキングが発生します。
3.2 データ型の適切な選択
キャッシュインスタンスは、文字列、ハッシュテーブル、リスト、セット、ソート済みセットなど、複数の異なるデータ構造タイプを提供します。適切なデータ構造タイプを選択することで、キャッシュのパフォーマンスと信頼性を向上させることができます。
データ構造タイプ
適用シナリオ
説明
文字列（String）
シンプルな文字列データ。例えば、設定情報、カウンターなどです。
バイナリデータを保存する必要がある場合は、バイナリセーフな文字列型を使用できます。
ハッシュテーブル（Hash）
複数のフィールドと値のデータ。例えば、ユーザー情報、商品情報などです。
メモリ容量を節約でき、一括操作が容易になります。
リスト（List）
順序付きの要素コレクション。例えば、メッセージキュー、タスクリストなどです。
両端での挿入および削除操作をサポートします。
セット（Set）
順序なしの要素コレクション。例えば、タグリスト、友達リストなどです。
和集合、積集合、差集合などの操作をサポートします。
ソート済みセット（Sorted Set）
順序付きの要素コレクション。例えば、ランキング、投票リストなどです。
スコアに基づいてソートし、範囲クエリをサポートします。
3.3 メモリエンコーディングの最適化
データ構造のメモリエンコーディング最適化設定を適切に制御して使用してください。例えば、ziplistは特殊なデータ構造であり、小さなリスト、ハッシュテーブル、ソート済みセットを連続したメモリブロックに格納することで、メモリ空間を節約できます。
シーン
推奨事項
データ量が小さく、頻繁な走査が必要な場合
ziplistの使用が適しており、メモリ使用効率が高くなります。
データ量が大きく、頻繁な挿入、削除、検索が必要な場合
ziplistの使用は推奨されません。他のデータ構造の使用を検討してください。
説明：
ziplistにはインデックスがないため、検索、挿入、削除操作では線形スキャンが必要となり、データ量が多い場合はパフォーマンスが低下する可能性があります。具体的なデータ量とアクセスパターンに応じて、有効にするかどうかを決定してください。
3.4 複数のStringの代わりにHashを使用する
1つのKeyに複数の属性がある場合は、Stringタイプの代わりにHashタイプの使用を検討できます。Hashはキーと値のペアを格納するデータ構造であり、複数のフィールドと値を格納するために使用できます。HSETコマンドを使用して複数のフィールドと値を1つのハッシュテーブルに格納し、その後HGETコマンドを使用して指定したフィールドの値を取得してください。Stringタイプを使用して複数の属性を格納する場合は、特定の区切り文字を使用して異なる属性値を1つの文字列に連結する必要があり、操作が複雑になり、メモリ空間を無駄にする可能性があります。
反面の例： 複数のStringタイプを使用して同じオブジェクトの属性を格納すると、Keyの数が膨張し、アトミック操作ができなくなります。
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)
正しい例： Hashタイプを使用して同じオブジェクトの複数の属性を1つのKeyに集約し、Keyの数を減らしてアトミック操作をサポートします。
hmset user:1 name tom age 19 favor football

ヘルプとサポート

この記事はお役に立ちましたか？

営業担当者にお問い合わせいただくかチケットを提出してサポートを求めることができます。

フィードバック

tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

KeyとValueの設計原則

一、Keyの設計原則

二、Keyのライフサイクル基準

三、Valueの設計原則

3.1 大規模Keyの拒否

3.2 データ型の適切な選択

3.3 メモリエンコーディングの最適化

3.4 複数のStringの代わりにHashを使用する

Running Environment

ヘルプとサポート

原則	説明
簡潔性	セマンティクスを保証する前提で、Keyの長さを適宜短縮できます。Keyが多い場合、Keyが占有するメモリ領域も無視できません。
命名規則	英文字で始め、命名には大文字と小文字の英字、数字、縦線、アンダースコア、英文ドット（`.`）および英文半角コロン（`:`）のみを使用できます。
意味的分割	異なる業務ロジックの意味は英文半角コロン（`:`）で区切り、同一業務ロジック意味セグメント内の単語間は英文半角ドット（`.`）で区切って、完全な意味を表します。
可読性	Key名は、Keyが表すValueの型で終わるようにして、可読性を高めます。例えば、`user:basic.info:userid:string。`
長さ制限	Key名が大きすぎると一定のメモリ領域を占有します。128バイト以内に制御することをお勧めします。
特殊文字の使用を禁止します。	`\\`、`*`、`?`、`{}`、`[]`、`()`、スペース、単一引用符と二重引用符、エスケープ文字などの使用は禁止です。そうでない場合、Keyを検索できないか、検索に失敗する可能性があります。

例	説明
`cx:cxdb:user:000110011`	簡潔で意味が明確であり、コロンを使用して階層化します。
`user:basic.info:userid:string`	同一意味セグメントはドットで区切り、Value 型で終了します。

例	問題
`cx:cxdb:cxdb_user_info:000110011`	テーブル名にデータベース名「cxdb」が重複して含まれており、冗長であり、Keyの長さが増加します。
`set user 000110011`	Keyにスペースが含まれており、使用が禁止されている特殊文字です。

データ構造タイプ	大Key判定条件	問題説明
String	値が10MBを超えています。	データ値が大きすぎます。
Set	メンバー数が10000個を超えています。	メンバー数が多いです。
List	メンバー数が10000個を超えています。	メンバー数が多いです。
Hash	メンバー数が1000個を超え、かつメンバー全体のValue値サイズが1000MBです。	メンバー全体のサイズが大きすぎます。

基準	説明
Value のサイズを制御してください。	String型は10KB以内に制御します。Hash、List、Set、Zsetの要素数は5000を超えないようにします。
大規模なKeyの直接削除は避けてください。	必須でない限り、delを使用して大規模なKeyを削除しないでください。
段階的な削除	非文字列の大規模なKeyについては、hscan、sscan、zscanを使用して段階的に削除することをお勧めします。
期限切れによる自動削除に注意してください。	大規模なKeyの有効期限切れによる自動削除問題を防止します。例えば、200万件のZsetに1時間の有効期限を設定すると、del操作がトリガーされ、ブロッキングが発生します。

データ構造タイプ	適用シナリオ	説明
文字列（String）	シンプルな文字列データ。例えば、設定情報、カウンターなどです。	バイナリデータを保存する必要がある場合は、バイナリセーフな文字列型を使用できます。
ハッシュテーブル（Hash）	複数のフィールドと値のデータ。例えば、ユーザー情報、商品情報などです。	メモリ容量を節約でき、一括操作が容易になります。
リスト（List）	順序付きの要素コレクション。例えば、メッセージキュー、タスクリストなどです。	両端での挿入および削除操作をサポートします。
セット（Set）	順序なしの要素コレクション。例えば、タグリスト、友達リストなどです。	和集合、積集合、差集合などの操作をサポートします。
ソート済みセット（Sorted Set）	順序付きの要素コレクション。例えば、ランキング、投票リストなどです。	スコアに基づいてソートし、範囲クエリをサポートします。

シーン	推奨事項
データ量が小さく、頻繁な走査が必要な場合	ziplistの使用が適しており、メモリ使用効率が高くなります。
データ量が大きく、頻繁な挿入、削除、検索が必要な場合	ziplistの使用は推奨されません。他のデータ構造の使用を検討してください。