redis-core
Core Redis modeling guidance — choose the right data structure (String, Hash, List, Set, Sorted Set, JSON, Stream, Vector Set) and use consistent colon-separated key names. Use when designing a Redis data model, caching objects, deciding between Hash and JSON, building counters,
Install
npx skills add https://github.com/redis/agent-skills/tree/main/skills/redis-core
claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install redis-agent-skills@llmmart
git clone https://github.com/redis/agent-skills.git
The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole redis/agent-skills collection as a plugin from our marketplace. Git is the plain clone.
Skill manifest
Redis Core
Foundational guidance for modeling data in Redis. Covers data-type selection and key-name conventions — the two decisions that most directly drive memory, performance, and maintainability.
When to apply
- Caching objects, sessions, or per-user state.
- Counters, leaderboards, recent-items lists, unique-membership sets.
- Reviewing or refactoring Redis key names.
- Deciding between a Redis Hash and a JSON document for an entity.
1. Choose the right data structure
Pick the type that matches the access pattern, not just the shape of the data.
| Use case | Recommended type | Why |
|---|---|---|
| Simple values, counters | String | Atomic INCR/DECR, SET/GET |
| Object with independently updated fields | Hash | Per-field reads/writes, no whole-object rewrite |
| Queue, recent-N items | List | O(1) push/pop at ends |
| Unique items, membership checks | Set | O(1) SADD/SISMEMBER/SCARD |
| Rankings, score-based ranges | Sorted Set | Score-ordered; ZADD/ZRANGE/ZRANK |
| Nested / hierarchical data | JSON | Path-level updates, nested arrays, RQE indexing |
| Event log, fan-out messaging | Stream | Persistent, consumer groups |
| Vector similarity | Vector Set | Native vector storage with HNSW |
Common anti-pattern: stuffing a flat object into a serialized string. Updating one field means fetch + parse + mutate + rewrite. Use a Hash instead.
See references/choose-data-structure.md for full rationale and Python/Java examples.
2. Use consistent key names
Use colon-separated segments with a stable hierarchy:
{entity}:{id}:{attribute}
user:1001:profile
user:1001:settings
order:2024:items
session:abc123
article:987:likes
game:space-invaders:leaderboard
Rules of thumb:
- Lowercase, colon-separated. No spaces, no mixed casing (
User_1001_Profileis bad). - Keep keys short but readable — keys live in memory and appear in every command.
- Don't use full URLs or long strings as keys. Extract a short identifier, or use a hash digest of the URL.
- Prefix for multi-tenancy (
tenant:42:user:7:cart) so scans and ACLs can target a tenant cleanly. - Be consistent. Pick one convention per service and apply it across all keys.
See references/key-naming.md for cleanup examples and edge cases.
References
Files (agent-skills)
-
references
-
choose-data-structure.md 2.3 KB
# Choose the Right Data Structure Selecting the appropriate Redis data type for your use case is fundamental to performance and memory efficiency. | Use Case | Recommended Type | Why | |----------|------------------|-----| | Simple values, counters | String | Fast, atomic operations | | Object with fields | Hash | Memory efficient, partial updates, field-level expiration | | Queue, recent items | List | O(1) push/pop at ends | | Unique items, membership | Set | O(1) add/remove/check | | Rankings, ranges | Sorted Set | Score-based ordering | | Nested/hierarchical data | JSON | Path queries, nested structures, geospatial indexing with RQE | | Event logs, messaging | Stream | Persistent, consumer groups | | Similarity search | Vector Set | Native vector storage with built-in HNSW indexing | **Incorrect:** Using strings for everything. **Python** (redis-py): ```python # Storing object as JSON string loses atomic field updates redis.set("user:1001", json.dumps({"name": "Alice", "email": "alice@example.com"})) # To update email, must fetch, parse, modify, and rewrite entire object user = json.loads(redis.get("user:1001")) user["email"] = "new@example.com" redis.set("user:1001", json.dumps(user)) ``` **Java** (Jedis): ```java // Bad: Storing as delimited string requires manual parsing jedis.set("bicycle", "Deimos;Ergonom;Enduro bikes;4972"); String bike = jedis.get("bicycle"); String[] fields = bike.split(";"); String model = fields[0]; // Fragile and error-prone ``` **Correct:** Use Hash for objects with fields. **Python** (redis-py): ```python # Hash allows atomic field updates redis.hset("user:1001", mapping={"name": "Alice", "email": "alice@example.com"}) # Update single field without touching others redis.hset("user:1001", "email", "new@example.com") ``` **Java** (Jedis): ```java import java.util.Map; import java.util.HashMap; // Good: Hash models properties naturally Map<String, String> hashFields = new HashMap<>(); hashFields.put("model", "Deimos"); hashFields.put("brand", "Ergonom"); hashFields.put("type", "Enduro bikes"); hashFields.put("price", "4972"); jedis.hset("bicycle", hashFields); // Read individual field String model = jedis.hget("bicycle", "model"); ``` Reference: [Choosing the Right Data Type](https://redis.io/docs/latest/develop/data-types/compare-data-types/) -
key-naming.md 1.5 KB
# Use Consistent Key Naming Conventions Well-structured key names improve code maintainability, debugging, and enable efficient key scanning. **Correct:** Use colons as separators with a consistent hierarchy. ``` # Pattern: service:entity:id:attribute user:1001:profile user:1001:settings order:2024:items cache:api:users:list session:abc123 ``` **Python** (redis-py): ```python # Good: Short, meaningful key redis.set("product:8361", cached_html) page = redis.get("product:8361") ``` **Java** (Jedis): ```java // Good: Short, meaningful key derived from URL jedis.set("product:8361", "<some cached HTML>"); String page = jedis.get("product:8361"); ``` **Incorrect:** Inconsistent naming, spaces, or very long keys. ``` # These cause confusion and waste memory User_1001_Profile my key with spaces com.mycompany.myapp.production.users.profile.data.1001 ``` **Java** (Jedis): ```java // Bad: Using full URL as key wastes memory and slows comparisons jedis.set("http://www.verylongurlkey.com/store/products/product.html?id=8361", "<some cached HTML>"); ``` **Key naming tips:** - Keep keys short but readable—they consume memory - Consider key prefixes for multi-tenant applications - Extract short identifiers from URLs or long strings rather than using the whole thing - For large binary values, consider using a hash digest as the key instead of the value itself - Use consistent separators (colons are conventional) Reference: [Redis Keys](https://redis.io/docs/latest/develop/use/keyspace/)
-
-
SKILL.md 3 KB
--- name: redis-core description: Core Redis modeling guidance — choose the right data structure (String, Hash, List, Set, Sorted Set, JSON, Stream, Vector Set) and use consistent colon-separated key names. Use when designing a Redis data model, caching objects, deciding between Hash and JSON, building counters, leaderboards, membership sets, or session stores, or when reviewing/cleaning up Redis key naming. license: MIT metadata: author: Redis, Inc. version: "0.1.0" --- # Redis Core Foundational guidance for modeling data in Redis. Covers data-type selection and key-name conventions — the two decisions that most directly drive memory, performance, and maintainability. ## When to apply - Caching objects, sessions, or per-user state. - Counters, leaderboards, recent-items lists, unique-membership sets. - Reviewing or refactoring Redis key names. - Deciding between a Redis Hash and a JSON document for an entity. ## 1. Choose the right data structure Pick the type that matches the *access pattern*, not just the shape of the data. | Use case | Recommended type | Why | |---|---|---| | Simple values, counters | String | Atomic `INCR`/`DECR`, `SET`/`GET` | | Object with independently updated fields | Hash | Per-field reads/writes, no whole-object rewrite | | Queue, recent-N items | List | O(1) push/pop at ends | | Unique items, membership checks | Set | O(1) `SADD`/`SISMEMBER`/`SCARD` | | Rankings, score-based ranges | Sorted Set | Score-ordered; `ZADD`/`ZRANGE`/`ZRANK` | | Nested / hierarchical data | JSON | Path-level updates, nested arrays, RQE indexing | | Event log, fan-out messaging | Stream | Persistent, consumer groups | | Vector similarity | Vector Set | Native vector storage with HNSW | **Common anti-pattern:** stuffing a flat object into a serialized string. Updating one field means fetch + parse + mutate + rewrite. Use a Hash instead. See [references/choose-data-structure.md](references/choose-data-structure.md) for full rationale and Python/Java examples. ## 2. Use consistent key names Use `colon-separated` segments with a stable hierarchy: ``` {entity}:{id}:{attribute} user:1001:profile user:1001:settings order:2024:items session:abc123 article:987:likes game:space-invaders:leaderboard ``` Rules of thumb: - **Lowercase, colon-separated.** No spaces, no mixed casing (`User_1001_Profile` is bad). - **Keep keys short but readable** — keys live in memory and appear in every command. - **Don't use full URLs or long strings as keys.** Extract a short identifier, or use a hash digest of the URL. - **Prefix for multi-tenancy** (`tenant:42:user:7:cart`) so scans and ACLs can target a tenant cleanly. - **Be consistent.** Pick one convention per service and apply it across all keys. See [references/key-naming.md](references/key-naming.md) for cleanup examples and edge cases. ## References - [Redis: Choosing the right data type](https://redis.io/docs/latest/develop/data-types/compare-data-types/) - [Redis: Keys](https://redis.io/docs/latest/develop/use/keyspace/)
Comments (0)
Sign in to join the conversation.
Reviews (0)
No reviews yet.
No comments yet.