Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit 95fbe9a

Browse files
PatelNeelMaheshPatelNeelMahesh
committedApr 26, 2025
readis ds
1 parent a80f41c commit 95fbe9a

File tree

2 files changed

+417
-0
lines changed

2 files changed

+417
-0
lines changed
 

‎redis/02.data_structure_in_redis.md

Lines changed: 227 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,227 @@
1+
# Data Structures in Redis
2+
3+
Redis supports **five core data structures**, each designed for specific use-cases and access patterns. These are:
4+
5+
1. **Strings**
6+
2. **Lists**
7+
3. **Sets**
8+
4. **Hashes**
9+
5. **Sorted Sets (ZSets)**
10+
11+
Each structure is optimized for fast in-memory operations and has a dedicated set of commands.
12+
13+
---
14+
15+
## 1. 🔹 **Strings**
16+
The simplest and most commonly used data structure in Redis.
17+
18+
### 📌 Characteristics:
19+
- Value is a sequence of bytes (binary-safe).
20+
- Can be used to store text, integers, or serialized objects.
21+
- Max size of a string value: **512 MB**.
22+
23+
### 📂 Use-cases:
24+
- Caching data (e.g., API responses)
25+
- Storing session tokens or flags
26+
- Rate-limiting counters
27+
- Feature flags
28+
29+
### 🛠️ Key Commands:
30+
31+
| Command | Description |
32+
|--------|-------------|
33+
| `SET key value` | Set a string value |
34+
| `GET key` | Retrieve the string value |
35+
| `INCR key` | Atomically increment an integer value |
36+
| `DECR key` | Atomically decrement an integer |
37+
| `APPEND key value` | Append to existing string |
38+
| `STRLEN key` | Length of string |
39+
40+
### 🔍 Example:
41+
42+
```bash
43+
SET user:1001:name "Yashvi"
44+
GET user:1001:name
45+
INCR visit:count # visit:count = 1
46+
APPEND user:1001:name " Patel"
47+
```
48+
49+
---
50+
51+
## 2. 🔹 **Lists**
52+
An ordered collection of string elements. Think of them like a doubly-linked list.
53+
54+
### 📌 Characteristics:
55+
- Elements are ordered (insertion order preserved).
56+
- Can efficiently add/remove items from **both ends**.
57+
- Ideal for **FIFO** (queue) or **LIFO** (stack) structures.
58+
59+
### 📂 Use-cases:
60+
- Task/job queues
61+
- Activity feeds or timelines
62+
- Message buffering
63+
64+
### 🛠️ Key Commands:
65+
66+
| Command | Description |
67+
|--------|-------------|
68+
| `LPUSH key value` | Insert at head (left) |
69+
| `RPUSH key value` | Insert at tail (right) |
70+
| `LPOP key` | Remove from head |
71+
| `RPOP key` | Remove from tail |
72+
| `LRANGE key start end` | Get a range of elements |
73+
| `LLEN key` | List length |
74+
75+
### 🔍 Example:
76+
77+
```bash
78+
LPUSH queue:emails "email1" "email2"
79+
RPUSH queue:emails "email3"
80+
LRANGE queue:emails 0 -1 # ["email2", "email1", "email3"]
81+
LPOP queue:emails # "email2"
82+
```
83+
84+
---
85+
86+
## 3. 🔹 **Sets**
87+
An **unordered** collection of **unique** string values.
88+
89+
### 📌 Characteristics:
90+
- Duplicate entries are automatically ignored.
91+
- Internally implemented using a hash table.
92+
- Supports set operations like **union**, **intersection**, and **difference**.
93+
94+
### 📂 Use-cases:
95+
- Track unique visitors
96+
- Tagging systems
97+
- Avoiding duplication (e.g., unique voters)
98+
99+
### 🛠️ Key Commands:
100+
101+
| Command | Description |
102+
|--------|-------------|
103+
| `SADD key member [member ...]` | Add one or more elements |
104+
| `SMEMBERS key` | Get all members |
105+
| `SISMEMBER key value` | Check membership |
106+
| `SREM key value` | Remove a member |
107+
| `SUNION key1 key2` | Union of two sets |
108+
| `SINTER key1 key2` | Intersection of sets |
109+
110+
### 🔍 Example:
111+
112+
```bash
113+
SADD course:students "Arjun" "Mahir" "Yashvi"
114+
SISMEMBER course:students "Krishna" # false
115+
SMEMBERS course:students # {"Arjun", "Mahir", "Yashvi"}
116+
```
117+
118+
---
119+
120+
## 4. 🔹 **Hashes**
121+
A collection of **field-value pairs**, similar to a row in a database or an object in a JSON document.
122+
123+
### 📌 Characteristics:
124+
- Best used to store objects (like user profiles, product details).
125+
- Efficient for retrieving or modifying individual fields.
126+
127+
### 📂 Use-cases:
128+
- Representing structured data (users, products)
129+
- Updating subfields without replacing the entire value
130+
131+
### 🛠️ Key Commands:
132+
133+
| Command | Description |
134+
|--------|-------------|
135+
| `HSET key field value` | Set a field |
136+
| `HGET key field` | Get value of a field |
137+
| `HGETALL key` | Get all fields and values |
138+
| `HDEL key field` | Delete a field |
139+
| `HEXISTS key field` | Check if field exists |
140+
| `HINCRBY key field n` | Increment field by value `n` |
141+
142+
### 🔍 Example:
143+
144+
```bash
145+
HSET user:1001 name "Priyesha" age "23" city "Surat"
146+
HGET user:1001 name # "Priyesha"
147+
HGETALL user:1001 # {name: "Priyesha", age: "23", city: "Surat"}
148+
```
149+
150+
---
151+
152+
## 5. 🔹 **Sorted Sets (ZSets)**
153+
Similar to Sets but with a **score** associated with each member that determines ordering.
154+
155+
### 📌 Characteristics:
156+
- Members are unique.
157+
- Score is a floating-point number.
158+
- Automatically keeps elements sorted by score.
159+
160+
### 📂 Use-cases:
161+
- Leaderboards
162+
- Ranking systems
163+
- Time-based event queues (timestamps as scores)
164+
165+
### 🛠️ Key Commands:
166+
167+
| Command | Description |
168+
|--------|-------------|
169+
| `ZADD key score member` | Add a member with score |
170+
| `ZRANGE key start end [WITHSCORES]` | Get members in order |
171+
| `ZREVRANGE key start end` | Reverse order |
172+
| `ZINCRBY key increment member` | Increment score of a member |
173+
| `ZRANK key member` | Get the rank of a member |
174+
175+
### 🔍 Example:
176+
177+
```bash
178+
ZADD leaderboard 1500 "Krishna"
179+
ZADD leaderboard 1600 "Arjun"
180+
ZINCRBY leaderboard 50 "Krishna"
181+
ZRANGE leaderboard 0 -1 WITHSCORES
182+
```
183+
184+
---
185+
186+
## ⚙️ Internal Efficiency and Performance
187+
188+
Redis uses optimized C implementations for each data structure:
189+
190+
| Data Structure | Internal Implementation |
191+
|----------------|--------------------------|
192+
| String | Simple dynamic strings (SDS) |
193+
| List | Quicklist (compressed linked list + array) |
194+
| Set | Hash tables or intsets |
195+
| Hash | Hashtable (dict) or ziplist |
196+
| Sorted Set | Skiplist + hashtable |
197+
198+
Redis automatically chooses compact representations (e.g., ziplist, intset) for memory efficiency on small datasets.
199+
200+
---
201+
202+
## 🧠 When to Use Which Data Structure?
203+
204+
| Use-case | Recommended Structure |
205+
|----------|------------------------|
206+
| Caching a single value | String |
207+
| Representing user profile | Hash |
208+
| Recent activities | List |
209+
| Unique tags or categories | Set |
210+
| Real-time leaderboards | Sorted Set |
211+
212+
---
213+
214+
## 🧾 Summary
215+
216+
| Data Type | Ordered? | Unique Values? | Score/Field Support? | Use-cases |
217+
|-----------|----------|----------------|----------------------|-----------|
218+
| String | ✖️ | ✖️ | ✖️ | Basic storage, counters |
219+
| List | ✅ | ✖️ | ✖️ | Queues, feeds |
220+
| Set | ✖️ | ✅ | ✖️ | Tags, unique items |
221+
| Hash | ✖️ | Field-based | ✅ | Objects, profiles |
222+
| Sorted Set| ✅ | ✅ | ✅ | Rankings, time-series |
223+
224+
---
225+
226+
Redis is not only fast — it’s **versatile**. Each data structure has a rich set of atomic commands allowing powerful, high-performance operations right from the Redis CLI or client library.
227+

‎redis/03.key_value_pair_and_persistence.md

Lines changed: 190 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,190 @@
1+
# Working with Key-Value Pairs and Managing Expiration & Persistence in Redis
2+
3+
Redis is best known as a fast, in-memory **key-value data store** that supports various data types and advanced features like automatic expiration and persistence. At the heart of Redis lies the concept of storing and manipulating data using **keys** and **values**.
4+
5+
This article will explore:
6+
1. **Key-Value Operations in Redis**
7+
2. **Expiration: Automatic Key Management**
8+
3. **Persistence: Saving Data to Disk**
9+
10+
---
11+
12+
## 📦 1. Working with Key-Value Pairs in Redis
13+
14+
Redis keys can be associated with different types of values, such as **strings, hashes, lists, sets**, or **sorted sets**. The key is always a **binary-safe string**, and it acts as the identifier for accessing or modifying the associated value.
15+
16+
### 📌 Key Characteristics:
17+
- **Keys** are case-sensitive and can be up to 512 MB.
18+
- **Values** can be of various data types.
19+
- Every operation is **atomic**.
20+
- You can **overwrite** an existing key by using `SET` again.
21+
22+
### ✅ Basic Key-Value Operations:
23+
24+
| Command | Description |
25+
|--------|-------------|
26+
| `SET key value` | Store a key with a string value |
27+
| `GET key` | Retrieve the value of a key |
28+
| `DEL key` | Delete a key |
29+
| `EXISTS key` | Check if a key exists |
30+
| `TYPE key` | Get the type of value stored |
31+
| `RENAME oldkey newkey` | Rename a key |
32+
| `KEYS pattern` | Find keys matching a pattern |
33+
| `FLUSHALL` / `FLUSHDB` | Delete all keys (global or current DB) |
34+
35+
### 🔍 Example:
36+
37+
```bash
38+
SET user:1001 "Jenil"
39+
GET user:1001 # "Jenil"
40+
EXISTS user:1001 # 1 (true)
41+
DEL user:1001
42+
EXISTS user:1001 # 0 (false)
43+
```
44+
45+
### 🔎 Wildcard Pattern Matching with KEYS:
46+
47+
| Pattern | Matches |
48+
|---------|---------|
49+
| `*` | Any number of characters |
50+
| `?` | Exactly one character |
51+
| `[abc]` | a, b, or c |
52+
| `user:*` | All keys starting with `user:` |
53+
54+
```bash
55+
KEYS user:* # Returns all user-related keys
56+
```
57+
58+
⚠️ **Note:** Avoid `KEYS` in production on large datasets — use `SCAN` for safer iteration.
59+
60+
---
61+
62+
## ⏳ 2. Expiration in Redis
63+
64+
Redis allows you to set **expiration times** on keys, meaning they will be **automatically deleted** after a certain duration.
65+
66+
This is especially useful for:
67+
- Session storage
68+
- Temporary caches
69+
- One-time passwords (OTP)
70+
- API rate limiting
71+
72+
### 🧭 Ways to Set Expiration:
73+
74+
| Method | Description |
75+
|--------|-------------|
76+
| `EXPIRE key seconds` | Set a timeout in seconds |
77+
| `PEXPIRE key milliseconds` | Set timeout in ms |
78+
| `TTL key` | Get time-to-live in seconds |
79+
| `PTTL key` | Time-to-live in ms |
80+
| `SET key value EX seconds` | Set + expiration in one |
81+
| `SET key value PX milliseconds` | Set + ms expiration |
82+
83+
### 🔍 Example:
84+
85+
```bash
86+
SET otp:123456 "793421" EX 300 # OTP expires in 5 min
87+
TTL otp:123456 # Returns time left
88+
EXPIRE session:krishna 1800 # 30 min session
89+
```
90+
91+
### 🔁 Modifying Expiration:
92+
93+
- Use `PERSIST key` to remove a key's expiration:
94+
```bash
95+
PERSIST otp:123456
96+
```
97+
98+
- You can reset TTL by using `EXPIRE` again or re-setting the key.
99+
100+
### 🧠 How Redis Handles Expired Keys:
101+
- Redis does **not immediately delete** expired keys.
102+
- It uses **lazy deletion** (access time check) and **periodic scanning** (10 keys at a time in a loop).
103+
- This strategy avoids performance spikes but keeps memory under control.
104+
105+
---
106+
107+
## 💾 3. Persistence in Redis
108+
109+
Even though Redis is an **in-memory store**, it provides multiple options for **persistence**, so your data can survive server restarts or crashes.
110+
111+
Redis supports two primary forms of persistence:
112+
113+
---
114+
115+
### 🗂 A. **RDB (Redis Database Backup) Snapshots**
116+
117+
Creates **point-in-time snapshots** of your data at specified intervals.
118+
119+
#### 📌 Configuration:
120+
In `redis.conf`, you can define:
121+
```ini
122+
save 900 1 # 1 change in 15 minutes
123+
save 300 10 # 10 changes in 5 minutes
124+
save 60 10000 # 10,000 changes in 1 minute
125+
```
126+
127+
#### 📁 Output File:
128+
- Stored in binary format: `dump.rdb`
129+
- Lightweight, but may lose recent changes on crash.
130+
131+
#### 🧾 Manual Snapshot:
132+
```bash
133+
SAVE # Blocking save
134+
BGSAVE # Non-blocking, recommended
135+
```
136+
137+
---
138+
139+
### 🧾 B. **AOF (Append-Only File)**
140+
141+
Logs every write operation to a file (`appendonly.aof`) in sequential order.
142+
143+
#### 📌 Characteristics:
144+
- More **durable** than RDB (can recover every command).
145+
- Slower than RDB due to logging every write.
146+
- You can configure how often it syncs data to disk:
147+
```ini
148+
appendfsync always # Every command (slowest but safest)
149+
appendfsync everysec # Once per second (balanced)
150+
appendfsync no # OS decides (fastest, least safe)
151+
```
152+
153+
#### 🔄 Rewrite AOF:
154+
Over time, the file grows. Redis can compact it:
155+
```bash
156+
BGREWRITEAOF
157+
```
158+
159+
---
160+
161+
### 🔁 Can You Use Both RDB and AOF?
162+
163+
Yes. Redis allows using **both together** to strike a balance:
164+
- Use RDB for fast recovery on full data dumps.
165+
- Use AOF for durability of recent changes.
166+
167+
In case of a restart, Redis will **prefer AOF** if both exist.
168+
169+
---
170+
171+
## ⚙️ Summary Table
172+
173+
| Feature | RDB | AOF |
174+
|--------|-----|-----|
175+
| Durability | Medium | High |
176+
| File Size | Small | Large |
177+
| Performance | High | Slower |
178+
| Recovery Speed | Fast | Slower |
179+
| Use-case | Backup | Reliability |
180+
181+
---
182+
183+
## 📌 Conclusion
184+
185+
Redis’s key-value model is extremely powerful thanks to:
186+
- **Flexible operations on keys**
187+
- **Optional time-to-live (TTL)** for temporary data
188+
- **Persistence mechanisms** to ensure data safety
189+
190+
Whether you’re building a **cache**, **message queue**, **real-time leaderboard**, or **session store**, understanding how to manage key lifecycles and persistence options is crucial for designing reliable systems with Redis.

0 commit comments

Comments
 (0)
Please sign in to comment.