A multithreaded fork of Redis that is faster

#1

Post by ericblenkarn » Mon, Oct 07, 2019, 4:17 PM UTC

A multithreaded fork of Redis that is faster
docs.keydb.dev

Re: A multithreaded fork of Redis that is faster

#2

Post by cyrux004 » Mon, Oct 07, 2019, 4:54 PM UTC

I 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

Re: A multithreaded fork of Redis that is faster

#3

Post by bengotow » Mon, Oct 07, 2019, 5:00 PM UTC

cyrux004 wrote: post #2

I 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

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!

Re: A multithreaded fork of Redis that is faster

#4

Post by tengbretson » Mon, Oct 07, 2019, 5:05 PM UTC

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

Re: A multithreaded fork of Redis that is faster

#5

Post by scott_s » Mon, Oct 07, 2019, 5:05 PM UTC

Two HN threads from around when the project started:

Show HN: KeyDB – A Multithreaded Fork of Redis, https://news.ycombinator.com/item?id=19257987

KeyDB: A Multithreaded Redis Fork, https://news.ycombinator.com/item?id=19368955

Re: A multithreaded fork of Redis that is faster

#6

Post by moab » Mon, Oct 07, 2019, 5:12 PM UTC

tengbretson wrote: post #4

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

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

Re: A multithreaded fork of Redis that is faster

#7

Post by femto113 » Mon, Oct 07, 2019, 5:14 PM UTC

tengbretson wrote: post #4

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

Only one thread can access the data at any given time, so it seems like most of the things you'd expect to be guaranteed by a single thread still are. I found this comment particularly interesting

   Unlike most databases the core data structure is the
   fastest part of the system. Most of the query time
   comes from parsing the REPL protocol and copying data
   to/from the network.

I wonder if anyone in the Redis ecosphere has explored a binary client server protocol, something that could be parsed/compiled on the client and then executed without parsing on the server, if the above is really true seems like that might offer even more perf gain than multithreading on the server.

Re: A multithreaded fork of Redis that is faster

#8

Post by atonse » Mon, Oct 07, 2019, 5:25 PM UTC

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.

Re: A multithreaded fork of Redis that is faster

#9

Post by penagwin » Mon, Oct 07, 2019, 5:29 PM UTC

bengotow wrote: post #3

cyrux004 wrote: post #2

I 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

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

Re: A multithreaded fork of Redis that is faster

#10

Post by nicolaslem » Mon, Oct 07, 2019, 5:30 PM UTC

moab wrote: post #6

tengbretson wrote: post #4

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

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

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