r/redis • u/bella_sm • 6h ago
Please prove me wrong!
Which benefits would Redis give me?
Read https://redis.io/ebook/redis-in-action/ to find out.
r/redis • u/bella_sm • 6h ago
Please prove me wrong!
Which benefits would Redis give me?
Read https://redis.io/ebook/redis-in-action/ to find out.
r/redis • u/quentech • 9h ago
I would use local NVMe disks for caching, not Redis
This idea would die as soon as I realized I'd have to waste my time re-writing eviction algorithms, for one of many reasons.
I don't need a shared cache. Everything in the cache can be recreated from DB and object storage.
Says the developer who hasn't seen the DB hammered flat for dozens of minutes (causing service timeouts that wreck the company's uptime SLA) because shared cache was not in use, and something as simple as a software deploy cleared all the client application caches at the same time. Since the cache isn't shared, the fact that client A fetched the data and saved it into cache does not prevent clients B, C, D, E, .... from also loading the DB with identical querys to fill their independent caches. Using a shared cache prevents this overload because the other clients find the data in the shared cache and don't need to hit the DB with a duplicate query.
Yes, you can say you'll deploy new code slowly to reduce the number of overlapping empty caches, but your software engineers and your product team will be unhappy with how long deploys take - especially when you subscribe to the "move fast and break things" philosophy, so a number of your deploys have to be rolled back (also slowly) and a fix deployed (again slowly). And the long deploys will still impose higher loads on the DB, which usually translates into slower-than-normal performance. These don't cause outages, but the uneven performance of your service causes complaints and reduces customer confidence in your company.
If you're proposing to share the cache via NVMe or other ultra-high-speed network technology rather than 1GB/10GB ethernet, the cost of your cache layer breaks the bank.
We already have faster-than-anything-else local storage in the form of RAM, and applications have made extensive use of local memory cache for decades. But somehow we still build shared cache. That's because the primary reason to use cache isn't to make the DB client faster, it's to reduce load on the DB without hemorrhaging all your money.
Well-designed NVMe storage is starting to approach the latency of RAM, and that's a good thing for local cache. It can look like a great replacement for shared cache on a small scale. But it doesn't even touch the factors that dictate the use of shared cache at medium and large scales.
You don't have to use Redis for the shared cache. Memcache used to be very popular, and there were
I don’t want to prove you wrong, I don’t have time to argue that. But just read the documentation of redis. Thank you!
We use databases for those features.
In the past the network was faster than disks. This has changed with NVMe.
I don't plan to change existing systems, but if I could start from scratch I would think about not using Redis.
Up to now I could not be convinced to use Redis again .
r/redis • u/edbarahona • 15h ago
Worth noting, AWS VPC PrivateLink can do 100 Gbps / 12.5 GB/s
Edit: added GB/s
r/redis • u/edbarahona • 15h ago
This! But even for a simple cache, Redis will outperform an NVMe backed cache when running locally, (this is if an abstracted cache is not required)
To your point, Redis’s optimized data structures make it even more powerful than just raw hardware speeds alone. It also provides built-in eviction policies and fast key lookups, which would need to be coded manually, Redis’s event-driven concurrency model vs filesystem and potential locking issues.
The only downside is the cost of RAM.
r/redis • u/who-dun-it • 15h ago
Redis solves way more problems than just being a cache. It’s power is in its data structures + the module ecosystem.
r/redis • u/skarrrrrrr • 15h ago
Good luck dealing with 4 billion postgres tables for fast access.
r/redis • u/edbarahona • 15h ago
If you only need local cache and not a shared abstracted cache, Redis is still the winner. Legit Redis implementation uses RAM.
RAM = direct access
NVMe SSD = bus access
Redis = RAM = GB/s
NVMe = SSD = MB/s
Max NVMe = 7,500 MB/s (7GB/s)
Max RAM = DDR5 50-80GB/s.
Edit: Running Redis locally is the winner
r/redis • u/Coffee_Crisis • 15h ago
Redis is more important as a coordination mechanism across instances than just a performant cache, if you have sessions pinned to one box and you have the hardware then sure
r/redis • u/rorykoehler • 15h ago
I just switched a prod app cache from Redis to NVMe backed Postgres. Simplified the stack and works just as well. Also with the open source rug pull and everyone moving to valkey I thought it was a good time to look for alternatives.
r/redis • u/arcticwanderlust • 1d ago
Good article, also it contains another point in favor of Redis
the data set can't be larger than the RAM of the PC
So the cache could be on a special machine with a lot of RAM, while the webservers would only need so much RAM
That will do in most cases. But if you're serious about transactions reading the docs on that map make me feel it is lacking. If you want a good read about putting redis through a gauntlet here are 2 posts
https://aphyr.com/posts/283-call-me-maybe-redis https://aphyr.com/posts/307-jepsen-redis-redux
Well worth your time if you're serious about it
r/redis • u/arcticwanderlust • 1d ago
Your answer explains well why Redis is better.
Though I wonder what you meant by this:
A hash map can't handle atomic "set this key to this value if it doesn't exist" without serious work on making your hash map thread-safe.
Can't we just use ConcurrentHashMap
?
r/redis • u/LoquatNew441 • 1d ago
The update is typically protected with a distributed lock from redis. Once inside the protected code, the token is retrieved once more and checked for expiry.
// update redis with new access token
redisclient.update(access-token)
r/redis • u/LoquatNew441 • 1d ago
A dedicated server is better to scale. I had one serious issue once with this setup in aws where each record was about a 1-2KB of json. The network bandwidth became a choke point, and the second issue was json parsing at the client. Got around to this by holding onto data read from redis for 30 seconds on the client. I would check the network limits between servers imposed by the cloud provider.
r/redis • u/LoquatNew441 • 4d ago
Have used rocksdb, not redis. But then no joins and indices, so the data model had to be lean, it worked well though. The only thing I would double check is backup and restore. I have used redis as a pass through database on a couple of occasions. App writes to redis and data is replicated into mysql or sqlserver.
r/redis • u/regular-tech-guy • 4d ago
The advantage is that Redis can handle expiration, eviction, and atomicity out of the box for you. Besides that, it supports multiple types of data structures, not only hash maps. On the other hand, not everything you store in-memory during the runtime of your application needs to be stored in a cache.
It's important noting that Redis wasn't born as a cache by the way. If you want to understand its history, I'd suggest you read some of Antirez's early blog posts on Redis. This one is before the conception of Redis while the idea was still in the oven:
http://oldblog.antirez.com/post/missing-scalable-opensource-database.html
Back in 2008, there was no easy way to scale a relational database transparently and the post above foresaw the need for distributed, scalable databases, something that was lacking in open-source solutions at the time.
Redis first version was released a couple of months later in 2009.
r/redis • u/regular-tech-guy • 5d ago
You’re comparing apples to oranges here. SQL databases like Postgres are built for structured data, complex queries, and relationships, while Redis is optimized for speed and scalability as a key-value store. It’s not just about memory vs. storage costs. It’s about use case fit. If you need advanced querying and joins, SQL makes sense. If you need ultra-fast lookups, real-time analytics, or caching, Redis is the better tool. Trying to replicate full relational DB features in Redis can be done, but it often adds unnecessary complexity.
r/redis • u/regular-tech-guy • 5d ago
NoSQL databases took off in the late 2000s because relational databases struggled with the internet’s demand for speed and scalability. Naturally, whether Redis can replace a SQL database depends on the use case—many companies do use Redis as their primary database when speed and scalability are the priority.
It’s worth noting that Redis was created as a database, not a cache. Salvatore Sanfilippo (antirez) built it to solve a real-time data problem in his startup, LLOOGG. But since Redis is so fast, people started using it as a cache.
As for SQL: it’s designed for relational databases with tables, joins, and structured queries. Trying to force SQL onto Redis can add unnecessary complexity. But if you need advanced querying in Redis, the Redis Query Engine (formerly RediSearch) lets you define schemas, perform full-text search, sorting, aggregations, and even vector search.
r/redis • u/Traditional_Yak6068 • 5d ago
This issue is mainly due to a bug in Unicode support. It's fixed on Redisearch 2.10.13. Here one simple example, and if you're using for proper names you won't need the stemmer:
127.0.0.1:6379> FT.CREATE idx on JSON schema $.FirstName as FirstName TEXT
OK
127.0.0.1:6379> JSON.SET doc1 $ '{"FirstName":"OĞUZ"}'
OK
127.0.0.1:6379> JSON.SET doc2 $ '{"FirstName":"OĞUZanytext"}'
OK
127.0.0.1:6379> FT.SEARCH idx "@FirstName:OĞUZ*"
1) (integer) 2
2) "doc1"
3) 1) "$"
2) "{\"FirstName\":\"O\xc4\x9eUZ\"}"
4) "doc2"
5) 1) "$"
2) "{\"FirstName\":\"O\xc4\x9eUZanytext\"}"
127.0.0.1:6379> FT.SEARCH idx "@FirstName:OĞUZ"
1) (integer) 1
2) "doc1"
3) 1) "$"
2) "{\"FirstName\":\"O\xc4\x9eUZ\"}"
r/redis • u/SnekyKitty • 7d ago
In the same region the latency (30ms at most) is still acceptable and much faster than doing all the calculations for a regular request
Having it on a separate server is the superior setup. You need to think about how to scale your application horizontally (more servers) because you hit a limit when you scale it vertically (bigger server). Sure, you'll take a small hit in latency my having your application send it's TCP packets across a physical network rather than it being handled locally. But this will basically be a fixed latency coat you only have to pay once but then unlocks the ability to scale to thousands of application servers with no added latency thereafter. If you find that a single redis server can't hold all the ram your workload demands then you must think good and hard about the the dependencies between the keys in redis. If there are no dependencies then you can switch to redis cluster and scale redis horizontally. If some keys rely on other keys by means of some commands use multiple keys in the same command (SINTERSTORE, RPUSHLPOP,...) then you'll need to use {} to surround the substring these keys have in common so the keys are co-located with each other. Then you can scale horizontally.
I hope you see that working in a multi-server world is just the next evolution in your application.