Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A multithreaded fork of Redis that is faster

docs.keydb.dev

Post reply on HN
Print view View original

41–50 of 164 posts

Re: A multithreaded fork of Redis that is faster

#41

Post by segmondy »

erulabs wrote: post #20

Any 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%-us…

Facebook just published a blog about moving petabytes per hour. I read it, I find the design interesting. I don't need it. But if I do, it's good to know that it's possible, that someone has solved, to have a reference and to possibly use their tool if it's free. So relax, I for one welcome whatever folks are working on out there. If it's true, we can learn from it and apply it in order domains too.

Re: A multithreaded fork of Redis that is faster

#42

Post by BubRoss »

nitwit005 wrote: post #22
moab wrote: post #6

Earlier quoted context omitted.

Can 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).

You can run multiple instances of redis on the same machine, which gets you parallelism from multiple processes instead of multiple threads. There's some extra deployment effort in doing so, but it's not generally a big issue. It also isn't exactly single threaded. It calls fork when it wants to persist data to disk, which is functionally similar to starting up a thread to do disk IO.

Doesn't that end up duplicating lots of data and work since the processes are independent? They don't share data do they?

Re: A multithreaded fork of Redis that is faster

#43

Post by darkr »

penagwin wrote: post #9
bengotow wrote: post #3

Earlier quoted context omitted.

Same! 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!

At 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 t…

We 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

Re: A multithreaded fork of Redis that is faster

#44

Post by mmaunder »

zymhan wrote: post #25
jadbox wrote: post #16

Since this has been around for awhile, why hasn't Redis adopted this strategy into core?

From 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 da…

This 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.

Re: A multithreaded fork of Redis that is faster

#45

Post by xfalcox »

erulabs wrote: post #20

Any 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%-us…

For some apps, where you can easily scale app servers horizontally and be stuck in a single redis (because redis cluster mode is not well supported by drivers, or because it can't access some atomic LUA operations) you can get redis to be your number 1 bottleneck. Specially because you can throw more cores at the PostgreSQL so Redis quickly becomes the only thing that doesn't scale.

Re: A multithreaded fork of Redis that is faster

#46

Post by tomjakubowski »

BubRoss wrote: post #42
nitwit005 wrote: post #22

Earlier quoted context omitted.

You can run multiple instances of redis on the same machine, which gets you parallelism from multiple processes instead of multiple threads. There's some extra deployment effort in doing so, but it's not generally a big issue. It also isn't exactly single threaded. It calls fork when it wants to persist data to disk, which is functionally similar to starting up a thread to do disk IO.

Doesn't that end up duplicating lots of data and work since the processes are independent? They don't share data do they?

fork() on Linux (and many other OSes) shares pages between the parent/child processes in a copy-on-write scheme

Re: A multithreaded fork of Redis that is faster

#47

Post by ignoramous »

segmondy wrote: post #41
erulabs wrote: post #20

Any 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%-us…

Facebook just published a blog about moving petabytes per hour. I read it, I find the design interesting. I don't need it. But if I do, it's good to know that it's possible, that someone has solved, to have a reference and to possibly use their tool if it's free. So relax, I for one welcome whatever folks are working on out there. If it's true, we can learn from it and apply it in order domains too.

> Facebook just published a blog about moving petabytes per hour.

For the curious: https://engineering.fb.com/data-infrastructure/scribe/

Edit: HN thread: https://news.ycombinator.com/item?id=21181982

Re: A multithreaded fork of Redis that is faster

#50

Post by JackFr »

atonse wrote: post #8
tengbretson wrote: post #4

I've always considered the single-threaded nature of Redis to be one of its greatest features.

Is it because of the consistency guarantees you can get from single threaded operation? Because it seems like this guarantees that. It mostly parallelizes the command parsing and networking side. The actual core hash table is guarded by a global lock, so you could still get all those single-threaded guarantees.

Won't it potentially allow out of order updates? Or am I missing something.
Post reply on HN