{"dataset":{"id":"00000000-0000-0000-0000-000000000018","slug":"redis-best-practices","name":"Redis best practices","description":"Source-linked guidance on Redis fundamentals: core data types, key expiration, RDB and AOF persistence, maxmemory eviction policies, and pipelining. Scoped to Redis Open Source as documented at redis.io; not a client-library or Redis Cloud operations corpus.","visibility":"public","version":1,"documentCount":5,"publisher":"Koskamo editorial","license":"Original summaries; linked sources retain their own terms.","reviewedAt":"2026-10-04T00:00:00.000Z","readOnly":true,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},"total":5,"documents":[{"title":"Pipelining for round-trip efficiency","sourceUrl":"https://redis.io/docs/latest/develop/using-commands/pipelining/","text":"Redis pipelining improves performance by issuing multiple commands without waiting for the response to each one, supported by most Redis clients. Redis uses a TCP Request/Response protocol, so every command normally costs a round-trip time (RTT): with a 250-millisecond RTT, even a server able to process 100k requests per second tops out at four requests per second without pipelining. Pipelining sends many commands and reads the replies in a single step — three pipelined PING commands over netcat pay the RTT cost once, not three times. The gain is not just RTT: socket I/O syscalls and the user-land to kernel-land context switch dominate per-command cost, and pipelining reads many commands with a single read() and delivers replies with a single write(), so queries per second rise almost linearly with longer pipelines before reaching about 10 times the baseline. Because the server must queue the replies in memory while a pipeline streams in, send large workloads in batches — for instance 10k commands at a time, reading the replies between batches — keeping speed nearly the same while bounding the memory used for queued replies. Scope: Redis. Reviewed October 4, 2026.","id":"redis-best-practices:Pipelining for round-trip efficiency","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"maxmemory limits and eviction policies","sourceUrl":"https://redis.io/docs/latest/develop/reference/eviction/","text":"The maxmemory configuration directive sets the memory limit for cache data — maxmemory 100mb in redis.conf, or CONFIG SET maxmemory 100mb at runtime — and zero means no limit, the default on 64-bit systems, while 32-bit systems use an implicit 3GB limit. When a new command would push usage past the limit, Redis evicts keys under the maxmemory-policy directive until memory use drops back below it. The noeviction policy returns an error on commands that cache new data while reads still work, and with replication this applies only to the primary. The allkeys-lru, allkeys-lrm, allkeys-lfu, and allkeys-random policies evict across all keys, while volatile-lru, volatile-lrm, volatile-lfu, volatile-random, and volatile-ttl evict only keys with an expiration — volatile-ttl picking the shortest remaining TTL — and the volatile policies behave like noeviction when no keys have an expiration. Rule of thumb: use allkeys-lru when a subset of elements is accessed far more often than the rest (a common Pareto case, and a good default), allkeys-lrm for read-heavy workloads, and allkeys-random when access is roughly uniform; the INFO command's runtime information helps check or improve the choice. Scope: Redis. Reviewed October 4, 2026.","id":"redis-best-practices:maxmemory limits and eviction policies","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Persistence with RDB and AOF","sourceUrl":"https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/","text":"Redis persistence writes data to durable storage with two options: RDB takes point-in-time snapshots of the dataset at intervals, while AOF logs every write operation in the same format as the Redis protocol itself, replaying it at startup to reconstruct the dataset. Persistence can be disabled completely — sometimes used when caching — or RDB and AOF can be combined in one instance. RDB is a compact single file, perfect for backups and disaster recovery, but it is not good at minimizing data loss: snapshots are usually created every five minutes or more, so an unexpected stop can cost the latest minutes of data, and the fork() needed to persist can pause client serving for some milliseconds with big datasets. AOF is more durable, with fsync policies of no fsync, every second, or every query; the default every-second policy keeps write performance great while losing at most one second of writes. The append-only log has no seeks or corruption problems on power outage, redis-check-aof can fix a half-written trailing command, and Redis rewrites the AOF safely in the background when it gets too big. Scope: Redis. Reviewed October 4, 2026.","id":"redis-best-practices:Persistence with RDB and AOF","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Key expiration and TTLs","sourceUrl":"https://redis.io/docs/latest/commands/expire/","text":"Set a timeout on a key and it is automatically deleted after the timeout expires; a key with an associated timeout is said to be volatile. The timeout is cleared only by commands that delete or overwrite the key's contents — DEL, SET, GETSET, and all the *STORE commands — while operations that alter the value without replacing it, such as INCR, LPUSH, or HSET, leave it untouched. PERSIST clears a timeout. Redis expires keys passively when a client accesses a timed-out key, and actively by testing a random sample of keys with an expiration. On expiration the master synthesizes a DEL operation to the AOF file and replicas, which never expire keys independently. EXPIRE key seconds accepts NX, XX, GT, and LT modifiers: NX sets an expiry only when none exists, XX only when one does, and GT or LT only when the new expiry is greater or less than the current one, treating a non-volatile key as infinite. EXPIRE returns 1 when the timeout is set, 0 otherwise; SET on an existing key clears its expiry, resetting TTL to -1. Scope: Redis. Reviewed October 4, 2026.","id":"redis-best-practices:Key expiration and TTLs","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"},{"title":"Core data types","sourceUrl":"https://redis.io/docs/latest/develop/data-types/","text":"Redis is a data structure server whose native types cover problems from caching to queuing to event processing. Strings are the most basic type, representing a sequence of bytes. Bitfields efficiently encode multiple counters in a string value, with atomic get, set, and increment operations and different overflow policies; bitmaps perform bitwise operations on strings. Arrays are sparse, index-addressable sequences of strings, and geospatial indexes find locations within a given geographic radius or bounding box. Hashes are record types modeled as collections of field-value pairs, resembling Python dictionaries, Java HashMaps, and Ruby hashes. JSON provides structured, hierarchical arrays and key-value objects matching the JSON text format, while lists, sets, sorted sets, streams, time series, and vector sets round out the general types. Probabilistic types — Bloom filter, Count-min sketch, Cuckoo filter, HyperLogLog, t-digest, and Top-K — compute statistics approximately but efficiently; HyperLogLog estimates the cardinality of large sets. The Compare data types page advises which general-purpose type fits common tasks. Scope: Redis. Reviewed October 4, 2026.","id":"redis-best-practices:Core data types","version":1,"createdAt":"2026-10-04T00:00:00.000Z","updatedAt":"2026-10-04T00:00:00.000Z"}]}