14 ms·
A multithreaded fork of Redis that is faster
- cyrux004 7y agoI would like to hear from somebody who is using this in production. We started to use Dynomite recently after hearing good things. Would like to hear comparisons
- bengotow 7y agoSame! I'd also be curious to hear about production scenarios that would really benefit from Redis going 5x faster. It's pretty darn fast to start with!
- penagwin 7y agoAt my job we're currently re-building our website in django, and we make heavy use of redis caching. Our website is definitely not "high traffic" but we get somewhere around 300,000 requests a day, mostly concentrated around business hours (We're a local clothing wholesaler). I haven't tested it under production loads, but just swapping our redis for keydb (THANKS DOCKER!) I saw no improvement in my artificial load tests. I didn't expect to see much real improvement for this use case, but I just thought it was worth mentioning that it isn't necessarily faster for all workloads.
- jdsully 7y agoSorry we didn’t improve your use case. If you are bottlenecked by Redis I would be curious about your workload.
- wolco 7y agoYou would probably need 30,000 million a day but then other parts of your setup would fail. Redis being the bottleneck is an unusual case.
- darkr 7y agoWe currently do nearly a million requests per minute at peak, on a non clustered redis pair for caching and rate limiting (so at least one read/write per request). This design won’t hold up forever, but we’ve got at least a few years headroom before we need to think about anything more complicated
- didip 7y agoI was thinking of the same thing and looks like someone else already experiment with them: https://medium.com/@diego_pacheco/running-multithreaded-redis-using-keydb-and-dynomite-5167d1ba4b63 https://medium.com/@diego_pacheco/running-multithreaded-redi...
- tengbretson 7y agoI've always considered the single-threaded nature of Redis to be one of its greatest features.
- moab 7y agoCan you elaborate on why? As someone who works on parallel/concurrent algorithms and data structures a single-threaded system design seems anathema to most research over the past decade (maybe excluding H-Store, which uses local single-threadedness in an interesting way).
- nicolaslem 7y agoNot parent but the single threaded approach really shines when executing Lua scripts in Redis. Except for some very specific edge cases, the execution of a script is atomic and since no command is ever processed concurrently you can rule out data races. I am sure it would be possible to provide these guaranties while offering concurrent execution but most likely at the expense of a simple design.
- jdsully 7y agoKeyDB provides that guarantee via a lock. However that does mean long running scripts don’t benefit from the multithreading. Ditto for modules. The goal is 100% Redis compatibility so I can’t compromise on atomicity.
- avar 7y agoIt shines right up until the moment someone writes a Lua command that takes more than a trivial amount of time, now your entire server is blocked in a pile-up of connections waiting on some relatively trivial amount of code being executed.
- aflag 7y agoCouldn't you just rollback the change or fix the lua script?
- scott_s 7y agoTwo HN threads from around when the project started: Show HN: KeyDB – A Multithreaded Fork of Redis, https://news.ycombinator.com/item?id=19257987 https://news.ycombinator.com/item?id=19257987 KeyDB: A Multithreaded Redis Fork, https://news.ycombinator.com/item?id=19368955 https://news.ycombinator.com/item?id=19368955
- not_a_cop75 7y agoI guess I can no longer use Redis. I mean what can the use case of normal Redis possibly be?
- kirstenbirgit 7y agoIt works, it's simple, and it's battle tested.
- not_a_cop75 7y agoDoes anyone not read into the sarcasm? This is the same cliche format stating that x is better than y, in such a manner to supposedly shame people still using y.
- gtirloni 7y agoNobody is shaming anyone.
- not_a_cop75 7y agoNo one is shaming ANYONE? Look around. Who is not shaming the oil and coal industry right now?
- quickthrower2 7y agoThere is a guideline on Hacker News (and this would apply to any online conversation): "Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- codegeek 7y agoI upvoted you to get you back up a bit but sarcasm is not an HN thing :) unless you complete it with more details.
- jadbox 7y agoSince this has been around for awhile, why hasn't Redis adopted this strategy into core?
- chadrs 7y agoIt's a decision choice to be single-threaded. Using threads requires locking or sophisticated concurrent data structures which can sometimes outweigh benefits in both code correctness/maintainability and performance.
- manigandham 7y agoRedis is actually exploring multithreading for IO. Here is antirez/Salvatore talking about the performance results in the write path: https://twitter.com/antirez/status/1110973404226772995 https://twitter.com/antirez/status/1110973404226772995
- zymhan 7y agoFrom Antirez's (Redis Maintainer) blog: > Another thing to note is that Redis is not Memcached, but, like memcached, is an in-memory system. To make multithreaded an in-memory system like memcached, with a very simple data model, makes a lot of sense. A multi-threaded on-disk store is mandatory. A multi-threaded complex in-memory system is in the middle where things become ugly: Redis clients are not isolated, and data structures are complex. A thread doing LPUSH need to serve other threads doing LPOP. There is less to gain, and a lot of complexity to add. http://antirez.com/news/126 http://antirez.com/news/126
- mmaunder 7y agoThis should be top comment. I came here to chat about potential downsides introduced by complexity of having multiple threads accessing the internal data structure. Until someone runs this in production where they actually use the performance it delivers over and above vanilla redis, I'll probably hold off. I'd like to know it's stable under very high load with contention. No offense to the creator(s) and I have a ton of gratitude and respect for them pushing the boundaries. But I also know Antirez is a smart dude and Redis has delivered insane performance thus far with few issues.
- erulabs 7y agoAny time these "much faster than Redis" databases come up, the sysadmin in me wonders how many people have had actual performance limitation issues with Redis. I've seen Redis servers handle hundreds of GB of traffic per hour. I've worked at companies where Aerospike and others are proposed as replacements for Redis because "they're faster" - and I point out the 98% idle CPUs on the Redis server, and the near-100%-usage CPUs on the app server fleet and mouth "But... why?" Replacing Redis with "something faster" is a bit like removing the doors on a car because "lighter means faster!". It might look good on a racetrack, but it's about as pragmatic as climbing through a window every morning before setting off for work.
- jdsully 7y agoIf the perf isn’t needed we also have Active Replication, subkey expiries, and S3 integration. Multithreading is how we got our start and the reason most people use us though.
- manigandham 7y agoTrue, it's rarely just raw performance. KeyDB has other advantages like multi-threading and disk-based persistence (instead of being limited by RAM) that makes it better at utilizing your server resources and handling larger scales.
- azhng 7y agoBut isn't the point of Redis is to be used as a caching layer instead of persistent layer
- t0mbstone 7y agoBut what if you could have the speed of RAM-based storage, and still have persistence? Sounds pretty appealing to me, personally.
- penagwin 7y agoYou already get this with either Redis or Keydb. The problem is that to avoid the disk being the bottleneck you must write to RAM, then later to the disk (you can't wait for confirmation that it was written) which means that even though a key may successfully be written to the DB, it hasn't been confirmed to persist. Basically redis can't necessarily guarantee data safety - which is perfectly fine for it's normal use case as a caching layer and data you don't necessarily care if you lose (for example rate limiting relies on tracking the number of requests/s within say an hour - if you lose the data you don't really care). User sessions too, worst case people have to log in again, meh whatever.
- jhgg 7y agoThis is pretty interesting. At work we run a few dozen cache nodes serving several million QPS during peak. We were debating switching some of this workload to memcached from redis - but this may be a viable alternative.
- gok 7y agoOn 32 cores? Doesn't seem like particularly great scaling.
- FlyingAvatar 7y agoIt looks like 8 to me. The 32 core mention was the test apparatus used to generate the requests.
- antirez 7y agoIn contrast running N instances scales linearly. That's why Redis multi threading just attempts to get the low hanging fruit of the write calls. For serious scalability it's better to orchestrate multiple instances in our vision.
- JackFr 7y agoWhile I get the performance improvement with multi-threading, won't you lose ordering of updates? In many use cases that's not a problem, but I imagine for some it's a dealbreaker.
- maxpert 7y agoSo this year on RedisConf Antirez demoed threaded version for Redis (only transport needs to be multi-threaded, core remains single threaded). Numbers were already amazing. I will pick the community version of Redis any day over forks.
- ksec 7y agoSo he changed his mind regarding threads? Will it actually be committed? or are they more or an experiment.
- xfalcox 7y agoIt is live on unstable which should become stable by the end of year: https://github.com/antirez/redis/commits/unstable?after=c65347ab17d61a4118efdc4a3568bf71b088ab63+270 https://github.com/antirez/redis/commits/unstable?after=c653...
- MuffinFlavored 7y ago> only transport needs to be multi-threaded Could he have gone with a non-blocking approach like libuv?
- yazaddaruvala 7y agoRedis is single threaded because it heavily relies on non-blocking IO like libuv. The multithreaded option is also based on non-blocking IO. You can think of it as one Event Loop per CPU core, rather than only one Event Loop per computer.
- gigatexal 7y agoIsn’t that basically what KeyDB does?
- yazaddaruvala 7y agoI’m sure it’s the same. I was mostly outlining the pattern in general, not trying to imply it’s redis specific. A sibling post says that the keydb implementation also lets the multithreaded executor perform parsing. So I guess that is one difference.
- stephenr 7y agoYou went to the effort of forking Redis but didn’t bother to fix the glaring lack of TLS support? What is the fucking point of a replicated KV store if the connections between nodes aren’t encrypted.
- antirez 7y agoWe have it in Redis 6, ETA for RC1 is end of year. However we did it the right way with a socket abstraction layer, one of the reasons it took so long.
- graycat 7y agoQ. Interesting. For my Web site, I wrote a simple key-value store, I use for Web user session state, based on two standard .NET collection classes. My code is single threaded. Sure, multi-threading could be better, but with my code design then I'd have to use multi-threaded versions of the collection classes, IIRC, which ARE in .NET. But, I'd guess that multi-threaded collection classes, due to the logic for locking or other means of concurrency control, would be slower and not faster. So, any thoughts on why, how multi-threaded could be so much faster, e.g., the OP's 5X, not just for the OP here but in general and maybe general enough to apply to my code? By the way, with my code I get a weak version of multi-threaded because the software interface to my key-value store is just via standard TCP/IP sockets moving byte arrays from object instance de/serialization. So, I'm taking advantage of the standard TCP/IP FIFO (first in, first out) queue for the incoming work to be done. I.e., more than one Web server can be sending a key-value request to my key-value server at the same time; TCP/IP handles that muli-threading; and I get a weak version of multi-threading. Broadly I'm wondering if having my actual code and the collection classes multi-threaded have any chance of being faster: Okay, the server has 8 cores so that MIGHT be the key to being faster.
- colinjfw 7y agoOne big thing I like about redis is that it is single threaded.
- coleifer 7y agoFriendly reminder that Kyoto Tycoon might be an option. Has real persistence (not just dump everything / reload everything, or cripple performance by turning on aof), is multi-threaded, scriptable via lua, amazing performance.
- manigandham 7y agoKT has been out of maintenance for years and doesn't have all the higher-level useful data structures and operations that Redis does. There are lot of options if you just wanted fast key/value with persistence from ScyllaDB, Tarantool, LMDB, RocksDB, etc.
- coleifer 7y agoEh, some of those are embedded, kt is a server like Redis or memcached. Kt was good enough for cloudflare, if that's enough of an endorsement.
- manigandham 7y agoI know, my point is that performance is rarely the need. Usability and useful APIs are more important which Redis excels at. Cloudflare stopped using KT because it wasn't much else other than simple and fast, and was missing a lot of other features.
- coleifer 7y agoThis post / the topic was performance
- derefr 7y agoNormally, when choosing components for a software stack, infra engineers are pretty good about choosing the components with the fewest features that fit the semantics that the software's design demands. You wouldn't choose Postgres where sqlite would do; you wouldn't choose Kubernetes where a single machine running Docker would do; etc. Components with simpler semantics are not only lower-maintenance, but usually can be more highly optimized due to having fewer "gotcha" requirements going into building them. Which is to say, if someone is looking for a "faster Redis", it's probably because they originally went with Redis as the "least software they can get away with" for their particular design needs. Any, therefore, any software that has more narrow semantics than Redis itself is not, in fact, a viable "faster Redis", for anyone but those who had no reason to be running Redis in the first place.
- sb8244 7y agoI'm really curious about the latency metric. I'm running elasticache redis and the round trip average of our Redis get commands is around 1ms. We may have 5-10 in a transaction and look for 10-20ms total time. Anecdotal, but it leaves me slightly confused
- croh 7y agoThis looks promising. But I still love Redis. 1. It is one of the most reliable software I used in production. 2. Not everyone wants 'faster than light' software. 3. Simplicity of redis blows my mind. It is very easy to maintain and almost never have a single issue. 4. These days everyone talks about scale but very few projects need FAANG-level scale. Point is there are so many small projects where current redis fits seamlessly. Just making case for Redis.