Mastering Redis: Data Types, Memory Optimization, and Persistence Strategies

Redis Core Data Types

Redis offers five commonly used data structures: String , Hash , List , Set , and Sorted Set . Each type is represented internally by a redisObject that stores a type field and an encoding field indicating the concrete storage format.

String : basic key/value, commands include SET, GET, INCR, DECR. When numeric, the encoding may be int for efficient arithmetic.

Hash : stores a map of fields to values, ideal for objects such as user profiles. Commands: HGET, HSET, HGETALL. Small hashes use a compact zipmap encoding; larger ones automatically switch to a full hashmap.

List : a doubly‑linked list supporting LPUSH, RPUSH, LPOP, RPOP, LRANGE. Frequently used for queues, timelines, and feed structures.

Set : an unordered collection with automatic deduplication. Commands include SADD, SPOP, SMEMBERS. Useful when uniqueness is required.

Sorted Set : similar to Set but each member has a score that defines ordering. Commands: ZADD, ZRANGE, ZREM. Ideal for leaderboards or time‑ordered streams.

Memory‑Saving Configuration Parameters

Redis’s flexible encodings allow significant memory savings, but they must be tuned via redis.conf:

Disable virtual memory (VM) by setting vm-enabled no.

Set maxmemory to limit RAM usage and trigger eviction.

Hash compactness: hash-max-zipmap-entries 64 and hash-max-zipmap-value 512. Values below these thresholds use the space‑efficient zipmap format.

List compactness: list-max-ziplist-entries 512 and list-max-ziplist-value 64. Small lists are stored as a contiguous ziplist.

Set compactness for integer sets: set-max-intset-entries 512. Pure integer sets below this size use an intset representation.

Choosing larger thresholds reduces memory consumption but may degrade performance because operations on compact encodings are O(n) instead of O(1). Balance is required based on workload characteristics.

Persistence Mechanisms

Redis supports four persistence options, though only the first two are production‑ready:

Snapshot (RDB) : Periodic fork‑based snapshots. Fast for reads but can lose data between snapshots.

Append‑Only File (AOF) : Logs every write command. Provides better durability but can grow large and slow down restarts.

Virtual Memory (VM) : Experimental swap‑like feature that has been abandoned due to high memory overhead.

Diskstore : B‑tree based prototype, still experimental.

Both snapshot and AOF use buffered I/O, which duplicates data in the OS page cache. When the Redis process’s memory usage exceeds roughly 60 % of the physical RAM, the page cache can cause swapping and instability.

Key Takeaways

Select the data type that best matches the business use‑case and tune the corresponding compact‑storage parameters.

If persistence is not required, disable all persistence mechanisms for maximum performance.

When persistence is needed, choose either snapshot or AOF based on tolerance for data loss and restart time; avoid VM and Diskstore.

Keep Redis’s resident memory below roughly three‑fifths of the host’s total RAM to prevent swapping and crashes.