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
- Write a one-off script that reads each
User_*_Profilestring, parses it and doesHSET user:{id}:profile .... - Have the app write to the new keys, or dual-write briefly.
- Delete the old keys once reads are fully switched over. Use
SCANfor this, neverKEYS.
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, Inc.가 권장하는 방식으로 모델이 데이터를 설계하도록 돕습니다. 데이터 타입은 접근 패턴에 맞추고, 키는 짧고 소문자이며 콜론으로 구분합니다(예: user:1001:profile).
동작 방식
- 카운터, 객체, 큐, 중복 없는 집합, 랭킹, 중첩 데이터, 이벤트 로그, 벡터 같은 용도를 결정 표로 Redis 타입에 연결합니다.
- 평평한 객체를 하나의 문자열로 직렬화하는 흔한 안티패턴을 짚고, Hash를 쓰는 방법을 Python(redis-py)과 Java(Jedis)로 보여 줍니다.
- 키 이름 규칙을 제시합니다.
{엔티티}:{id}:{속성}형식, 공백이나 대소문자 혼용 금지, URL을 그대로 키로 쓰지 않기, 멀티 테넌트는 테넌트 접두사 붙이기.
잘 맞는 경우
Redis 데이터 모델 설계, 객체나 세션 캐싱, 카운터와 리더보드 구현, 제각각인 키 이름 정리.
한계
아주 짧은 Skill입니다(참고 파일 2개 포함 약 7 KB). 데이터 타입과 키 이름만 다루며 클러스터, 영속성, 검색은 다루지 않습니다.
낮은 위험: Redis 공식 저장소(MIT 라이선스)의 지침 파일만 들어 있습니다. 스크립트, 네트워크 접속, 파일 쓰기가 없고 계정이나 키도 필요하지 않습니다. 조언만 할 뿐 사용자의 Redis에 연결하지 않습니다. 마이그레이션 관련 제안은 자신의 데이터로 확인한 뒤 실행하세요.