首頁 / Skills / 開發提效 / Redis 資料建模 Redis Core
開發提效

Redis 資料建模 Redis Core

Redis, Inc.MITSkill 語言: 英文
授權已核對不含腳本
演示真實執行紀錄 · claude-sonnet-5-5 · 2026年10月
I'm building a game leaderboard and a user profile cache on Redis. Right now our devs store each user as a JSON string under keys like 'User_1001_Profile' and update the email by fetching, parsing and rewriting the whole string. How should I model this, and what should the keys look like?
Skill: redis-core

Recommendation

Profile cache: use a Hash per user. Leaderboard: use a Sorted Set per board.

User profile: Hash

The JSON string forces fetch, parse, mutate and rewrite for every change. A Hash lets you touch one field at a time:

HSET user:1001:profile name "Ada" email "[email protected]" level 42 country "DE"

HSET  user:1001:profile email "[email protected]"   # update one field, no read needed
HGET  user:1001:profile email                      # read one field
HGETALL user:1001:profile                          # read everything
HINCRBY user:1001:profile level 1                  # atomic numeric update
EXPIRE user:1001:profile 3600                      # TTL, since this is a cache

This is atomic, needs no read-modify-write cycle, and avoids lost updates when two writers race. It also sends far less data over the wire.

Hashes hold flat field/value pairs. If the profile has nested data, such as arrays of items or sub-objects, use the JSON type (JSON.SET user:1001:profile $.address.city '"Berlin"'). Otherwise a Hash is simpler and lighter. You can also keep rarely changed nested parts in a separate key, for example user:1001:settings.

Leaderboard: Sorted Set

ZADD   game:space-invaders:leaderboard 12500 user:1001   # set/update score
ZINCRBY game:space-invaders:leaderboard 300 user:1001     # add points atomically
ZREVRANGE game:space-invaders:leaderboard 0 9 WITHSCORES  # top 10
ZREVRANK  game:space-invaders:leaderboard user:1001       # a player's rank

The member should be the user ID, not the whole profile. To render the board, take the top N IDs and fetch each profile with HMGET or HGETALL, pipelined.

Key naming

Use lowercase, colon-separated keys in the form {entity}:{id}:{attribute}. User_1001_Profile breaks that convention in casing, separators and order.

Purpose Key
Profile user:1001:profile
Settings user:1001:settings
Global leaderboard game:space-invaders:leaderboard
Periodic board game:space-invaders:leaderboard:2026-w43
Session session:abc123

Further tips:

  • Keep keys short, because they live in memory and appear in every command.
  • Pick one convention and apply it everywhere.
  • If you're multi-tenant, prefix with the tenant (tenant:42:user:1001:profile). That makes scans and ACLs easy to scope.
  • Time-bucketed leaderboard keys such as weekly or daily boards can be expired or rotated with EXPIRE.

Migration

  1. Write a one-off script that reads each User_*_Profile string, parses it and does HSET user:{id}:profile ....
  2. Have the app write to the new keys, or dual-write briefly.
  3. Delete the old keys once reads are fully switched over. Use SCAN for this, never KEYS.

I can sketch the migration script or the client code in Python or Java if that would help.

Pure-instruction skill, so the trial gave the model only the Skill and Read tools: no network, no shell, no Redis server. The request mixes a data-model question with a key-renaming question.

它做什麼
讓模型依 Redis 官方的建議設計資料:資料型別要符合存取方式,key 使用簡短、小寫、以冒號分隔的寫法,例如 user:1001:profile。

運作方式

  1. 以一張決策表,把計數器、物件、佇列、不重複集合、排行榜、巢狀資料、事件日誌、向量等情境對應到具體的 Redis 型別。
  2. 指出「把扁平物件序列化成單一字串」這個常見反模式,並提供使用 Hash 的寫法(Python redis-py 與 Java Jedis)。
  3. 提供 key 命名規則:{實體}:{id}:{屬性},不使用空白與大小寫混用,不拿完整 URL 當 key,多租戶加上租戶前綴。

適合
設計 Redis 資料模型、快取物件或工作階段、做計數器與排行榜、整理混亂的 key 命名。

限制
這是很精簡的 Skill(含兩份參考檔約 7 KB),只談資料型別與 key 命名,不涵蓋叢集、持久化與搜尋。

說明與風險

低風險:純指令檔,來自 Redis 官方儲存庫(MIT 授權)。沒有腳本、不連網、不寫入檔案,也不需要帳號或金鑰。它只提供建議,不會連線到你的 Redis。遷移相關的建議請先對照自己的資料再執行。

SKILL.md 原文套件內共 4 個檔案