Redis รองรับ data type อะไรบ้าง?

Question

Accepted Answer

Redis รองรับ **โครงสร้างข้อมูล** หลายแบบในฐานะค่า — strings, lists, hashes, sets, sorted sets รวมถึง type เฉพาะทาง (streams, bitmaps, HyperLogLog, geospatial) การเลือก type ที่เหมาะกับแต่ละ use case คือกุญแจสำคัญในการใช้ Redis อย่างมีประสิทธิภาพ

## data type หลัก

```bash
# STRING — the simplest (text, numbers, even binary up to 512MB)
SET key "value"
INCR counter            # atomic increment (strings can be counters)

# LIST — ordered list of strings (a linked list — fast push/pop at ends)
LPUSH mylist "a"        # push left
RPUSH mylist "b"        # push right
LRANGE mylist 0 -1      # get all → useful for queues, recent-items

# HASH — a map of field→value (like an object/record)
HSET user:1 name "Ann" age 30
HGET user:1 name        # => "Ann"  → great for storing objects

# SET — unordered unique strings
SADD tags "redis" "cache"
SISMEMBER tags "redis"  # membership test; SINTER/SUNION for set operations

# SORTED SET (ZSET) — unique members each with a SCORE, kept ordered by score
ZADD leaderboard 100 "Ann" 90 "Bob"
ZRANGE leaderboard 0 -1 WITHSCORES   # ranked → leaderboards, priority queues
```

## type เฉพาะทาง

```text
STREAM      → an append-only log (like a message queue/event log with consumer groups)
BITMAP      → bit operations on strings (compact flags, e.g. daily active users)
HYPERLOGLOG → approximate unique counts using tiny memory (cardinality estimation)
GEOSPATIAL  → store/query locations (geo radius queries)
```

## การเลือก type ที่เหมาะสม

```text
String      → simple values, counters, cached serialized data
List        → queues, stacks, recent-items, activity feeds
Hash        → objects/records (store fields of an entity together)
Set         → unique collections, membership tests, tags, relationships
Sorted Set  → leaderboards, rankings, priority queues, time-ordered data
→ Picking the right structure makes operations efficient and natural.
```

## ทำไมจึงสำคัญ

การเข้าใจ data type ของ Redis เป็นพื้นฐานสำคัญในการใช้ Redis อย่างมีประสิทธิภาพ เพราะพลังของ Redis มาจาก **โครงสร้างข้อมูลที่หลากหลาย** (ไม่ใช่แค่การจัดเก็บแบบ key-value ธรรมดา) ดังนั้นการรู้จักโครงสร้างเหล่านี้และรู้ว่าเมื่อใดควรใช้แต่ละแบบจึงเป็นความรู้เชิงปฏิบัติที่จำเป็น

**type หลัก** แต่ละแบบเหมาะกับความต้องการต่างกัน: **strings** (ค่าธรรมดาและ counter แบบ atomic), **lists** (คอลเลกชันที่มีลำดับสำหรับ queues, stacks และ feed ของรายการล่าสุด), **hashes** (เก็บ object/record ที่มีหลาย field ไว้ด้วยกัน — มีประสิทธิภาพสำหรับ entity), **sets** (คอลเลกชันที่ไม่ซ้ำกันสำหรับการทดสอบสมาชิก tags และความสัมพันธ์ พร้อมการดำเนินการเซต เช่น intersection) และ **sorted sets** (สมาชิกที่จัดอันดับตาม score — เหมาะกับ leaderboards, rankings และ priority queues โดยธรรมชาติ)

การเข้าใจ **type เฉพาะทาง** — streams (log แบบ append-only พร้อม consumer groups สำหรับ message queue และ event sourcing), bitmaps (flag แบบกะทัดรัด), HyperLogLog (การนับค่าที่ไม่ซ้ำแบบประมาณการในหน่วยความจำเล็กมาก) และ geospatial (การ query ตำแหน่ง) — ขยายขอบเขตสิ่งที่ Redis ทำได้อย่างมีประสิทธิภาพ

ที่สำคัญที่สุด **การเลือก type ที่เหมาะสม** สำหรับแต่ละ use case (sorted set สำหรับ leaderboard, hash สำหรับ object, list สำหรับ queue) คือสิ่งที่ทำให้การทำงานของ Redis มีประสิทธิภาพและเป็นธรรมชาติ — การใช้โครงสร้างที่ผิดนำไปสู่โซลูชันที่เทอะทะและช้า

เนื่องจากคุณค่าของ Redis มาจากโครงสร้างข้อมูลและการใช้มันอย่างเหมาะสมคือทักษะหลักในการทำงานกับ Redis และเนื่องจากการเลือกโครงสร้างกำหนดโดยตรงว่าการทำงานจะมีประสิทธิภาพและโค้ดจะสะอาดหรือไม่ การเข้าใจ data type ของ Redis — type หลักและเฉพาะทางและรู้ว่าเมื่อใดควรใช้แต่ละแบบ — จึงเป็นความรู้ที่จำเป็นและถูกนำไปใช้บ่อยสำหรับทุกคนที่ใช้ Redis เป็นพื้นฐานในการใช้ประโยชน์จาก Redis อย่างมีประสิทธิภาพเกินกว่าการจัดเก็บแบบ key-value ธรรมดา