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

151–160 of 164 posts

Re: A multithreaded fork of Redis that is faster

#151

Post by lmm »

ijpoijpoihpiuoh wrote: post #78
lmm wrote: post #77

Earlier quoted context omitted.

Is this really "unlike most databases"? I remember MySQL posting profiling data years ago showing that for looking up by primary-key, 3/4 of the time was spent parsing SQL. (They went on to introduce support for querying with the Memcached protocol to address this)

That's really surprising if true, considering the SQL should only need to be parsed once. SELECT foo FROM Table WHERE key = @mykey; Then you bind the parameter to whatever you're interested in.

Prepared statements are per-connection and a lot of time you want to use connections from a single pool that's used for all you different queries, so you can't really use them.

Re: A multithreaded fork of Redis that is faster

#152

Post by aflag »

thamer wrote: post #92
aflag wrote: post #55

Earlier quoted context omitted.

Couldn't you just rollback the change or fix the lua script?

Or just embrace modern hardware and use threads. This is the experience many people have running Redis in production with 21st-century hardware: https://twitter.com/rbranson/status/540565059337195520

That's a different issue. If they're in that situation without any custom scripts and the latency is cropping up, they should consider using a different tool or changing their codebase.

Re: A multithreaded fork of Redis that is faster

#153

Post by jrochkind1 »

manigandham wrote: post #91
jrochkind1 wrote: post #88

Earlier quoted context omitted.

> ...it's rarely just raw performance. KeyDB has other advantages like multi-threading... What are the advantages of "multi-threading" other than for performance?

Taking advantage of all your cores. Redis is awkward at high capacity since most servers scale CPU with RAM and you'll end up with most cores doing nothing. You can manually run multiple instances on the same server but now they're separate databases with operations and sharding overhead. Multithreading IO also reduces the latency hit from disk-persistence and provides more concurrency and throughput, which is a grea…

>> What are the advantages of "multi-threading" other than for performance?

> Taking advantage of all your cores.

Uh, is there any reason you'd want to "take advantage of all your cores" other than performance?

The question/proposal/dialog we started from, don't forget, was:

1. Redis is already as performant as I want, it's not even close to being a bottleneck, so I have no need for multi-threading, and this is a _very very common_ case, as redis is performant enough for a lot.

2. There are other advantages of multi-threading than performance. (Ie, other reasons you'd want it despite 1).

You seem to just be going around in circles. If 1, why would you care about "taking advantage of all your cores"?

Re: A multithreaded fork of Redis that is faster

#154

Post by ijpoijpoihpiuoh »

lmm wrote: post #151
ijpoijpoihpiuoh wrote: post #78

Earlier quoted context omitted.

That's really surprising if true, considering the SQL should only need to be parsed once. SELECT foo FROM Table WHERE key = @mykey; Then you bind the parameter to whatever you're interested in.

Prepared statements are per-connection and a lot of time you want to use connections from a single pool that's used for all you different queries, so you can't really use them.

Even with that, the SQL would be parsed once per connection? So, the costs should be de minimis, unless the benchmark were short indeed?

Re: A multithreaded fork of Redis that is faster

#155

Post by lmm »

ijpoijpoihpiuoh wrote: post #154
lmm wrote: post #151

Earlier quoted context omitted.

Prepared statements are per-connection and a lot of time you want to use connections from a single pool that's used for all you different queries, so you can't really use them.

Even with that, the SQL would be parsed once per connection? So, the costs should be de minimis, unless the benchmark were short indeed?

> Even with that, the SQL would be parsed once per connection?

In a webserver-like context it's once per query one way or another - the server process is stateless-ish between page loads, so each page load is either a from-scratch connection or a connection taken from a pool, but even if you're pooling you can't use prepared statements in practice (you can't leave a prepared statement on a connection that you return to the pool because you'll eventually exhaust the database server's memory that way, and you'd have to resubmit the prepared statement every time you took a connection out of the pool anyway because there's no way to know whether this connection has run this page already or not).

If you assume a page that's just displaying one database row, which is not the only use case but a common one, then each page load is one query and that query will have to be parsed for each page load, short of doing something like building a global set of all your application's queries and having your connection-pool logic initialise them for each connection.

Re: A multithreaded fork of Redis that is faster

#156

Post by ijpoijpoihpiuoh »

lmm wrote: post #155
ijpoijpoihpiuoh wrote: post #154

Earlier quoted context omitted.

Even with that, the SQL would be parsed once per connection? So, the costs should be de minimis, unless the benchmark were short indeed?

> Even with that, the SQL would be parsed once per connection? In a webserver-like context it's once per query one way or another - the server process is stateless-ish between page loads, so each page load is either a from-scratch connection or a connection taken from a pool, but even if you're pooling you can't use prepared statements in practice (you can't leave a prepared statement on a connection that you return…

In a database product I'm familiar with, the prepared statements are cached according to their content and those cached objects are shared between connections. Only if they fall out of the cache do they have to be re-parsed. I had assumed that's how all databases worked.

I'm somewhat surprised at the mechanism you're describing, but now I read the documentation it does seem to be the case. I wonder if a small piece of middle-ware might be sufficient to replicate the behavior I'm describing on a connection pool, and whether that would be desirable.

Re: A multithreaded fork of Redis that is faster

#157

Post by mperham »

markonen wrote: post #144
mperham wrote: post #101

Earlier quoted context omitted.

As the Sidekiq maintainer, I’ve seen many customers need to shard Redis around 5000-10000 jobs/sec. Sharding is a major operational headache so this could be very useful to heavy job processors if it does prove to scale better. I also find it interesting that the BSD license enables this 3rd party company to fork Redis and build closed source commercial software on top of it. One of the trade offs to consider when li…

I'm not sure if you're referring to KeyDB or something else as "closed source commercial software", but KeyDB is BSD licensed like Redis: https://github.com/JohnSully/KeyDB/blob/unstable/COPYING

They sell closed source extensions to Redis AFAICT.

https://keydb.dev/modules-redis.html

Re: A multithreaded fork of Redis that is faster

#158

Post by zymhan »

pgroves wrote: post #72
zymhan wrote: post #25

Earlier quoted context omitted.

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…

Is there a milestone the multi-threaded implementation could achieve that would make it a candidate to merge into core Redis?

I mean the first requirement would be a reason for needing multithreading in the first place. If you can then demonstrate that this implementation solves the initial problem, while not adversely affecting existing performance and stability, then it would probably be a candidate to merge into upstream.

Re: A multithreaded fork of Redis that is faster

#159

Post by manigandham »

jrochkind1 wrote: post #153
manigandham wrote: post #91

Earlier quoted context omitted.

Taking advantage of all your cores. Redis is awkward at high capacity since most servers scale CPU with RAM and you'll end up with most cores doing nothing. You can manually run multiple instances on the same server but now they're separate databases with operations and sharding overhead. Multithreading IO also reduces the latency hit from disk-persistence and provides more concurrency and throughput, which is a grea…

>> What are the advantages of "multi-threading" other than for performance? > Taking advantage of all your cores. Uh, is there any reason you'd want to "take advantage of all your cores" other than performance? The question/proposal/dialog we started from, don't forget, was: 1. Redis is already as performant as I want, it's not even close to being a bottleneck, so I have no need for multi-threading, and this is a _ve…

Sure, I concede multithreading is for performance. Still, the second point of having Redis structures available over a dataset that isn't limited by RAM is a big advantage.

Re: A multithreaded fork of Redis that is faster

#160

Post by finnh »

antirez wrote: post #70
stephenr wrote: post #64

Earlier quoted context omitted.

Is there any relevant documentation/discussion available?

Yes, the implementation is in this PR: https://github.com/antirez/redis/pull/6236

Kudos to you for a calm response to an angry question.
Post reply on HN