A multithreaded fork of Redis that is faster • Hacker News Board

Re: A multithreaded fork of Redis that is faster

#91

Post by manigandham » Mon, Oct 07, 2019, 9:57 PM UTC

jrochkind1 wrote: post #88

manigandham wrote: post #23

Earlier quoted context omitted.

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

> ...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 great tradeoff when you don't really need sub-millisecond performance but want the same API across a larger dataset limited by disk instead of RAM space.

Re: A multithreaded fork of Redis that is faster

#92

Post by thamer » Mon, Oct 07, 2019, 10:03 PM UTC

aflag wrote: post #55

avar wrote: post #32

Earlier quoted context omitted.

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

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

Re: A multithreaded fork of Redis that is faster

#93

Post by nitwit005 » Mon, Oct 07, 2019, 10:04 PM UTC

sciurus wrote: post #40

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.

Going from a single processes holding all your data to having your data sharded across multiple processes can be more than a little effort. Also, it might now have any benefit for you. Imagine a certain key is particularly hot. Having one multithreaded redis process handling access to it might speed things up. Running multiple sharded redis processes won't, since only one of them will have that key.

Most redis users are running multiple instances regardless. That some of them happen to be on the same machine is largely a detail.

It would make a little difference if there was a single hot key, but that's a bit unusual. Typically there's some subset of keys that are hot, and you can get them to hash across instances. People also tend to cache those values on the clients, as banging on redis constantly is a waste.

Re: A multithreaded fork of Redis that is faster

#94

Post by lllr_finger » Mon, Oct 07, 2019, 10:04 PM UTC

t0mbstone wrote: post #36

azhng wrote: post #35

Earlier quoted context omitted.

But isn't the point of Redis is to be used as a caching layer instead of persistent layer

But what if you could have the speed of RAM-based storage, and still have persistence? Sounds pretty appealing to me, personally.

Sounds like an embedded key value store, ie. RocksDB. I've used it with great success in constrained environments and also when pushing cache to the edge for stable, low-latency, high volume APIs.

Re: A multithreaded fork of Redis that is faster

#95

Post by jgalt212 » Mon, Oct 07, 2019, 10:05 PM UTC

IanCal wrote: post #76

ignoramous wrote: post #47

Earlier quoted context omitted.

> 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

Absolutely astounding to me, petabytes an hour? That's in the region of a meg to several megs per user per hour looking at their monthly active user figures.

It's mostly telemetry data. /s or not /s not sure.

Re: A multithreaded fork of Redis that is faster

#96

Post by lllr_finger » Mon, Oct 07, 2019, 10:08 PM UTC

twic wrote: post #15

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

This reminds me of LMAX, who found the fastest way to build their stock exchange was to make the core logic single-threaded, surrounded by multithreaded I/O: https://www.martinfowler.com/articles/lmax.html I believe other (grown-up/legacy!) exchanges work the same way. I wonder how much of the direction of concurrency research is driven by the fact that there is much more publishable work to be done in managing concu…

Disruptor benefits from lock free access using a ring buffer. You can get amazing results with a single thread but that aspect isn't central to the pattern.

Re: A multithreaded fork of Redis that is faster

#97

Post by dmix » Mon, Oct 07, 2019, 10:15 PM UTC

IanCal wrote: post #76

ignoramous wrote: post #47

Earlier quoted context omitted.

> 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

Absolutely astounding to me, petabytes an hour? That's in the region of a meg to several megs per user per hour looking at their monthly active user figures.

Does that include Instagram and WhatsApp? Or just FB branded stuff like Messenger and the network app...

Re: A multithreaded fork of Redis that is faster

#98

Post by coleifer » Mon, Oct 07, 2019, 10:23 PM UTC

manigandham wrote: post #87

coleifer wrote: post #81

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

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

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

Re: A multithreaded fork of Redis that is faster

#99

Post by manigandham » Mon, Oct 07, 2019, 10:27 PM UTC

coleifer wrote: post #98

manigandham wrote: post #87

Earlier quoted context omitted.

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

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

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

Re: A multithreaded fork of Redis that is faster

#100

Post by tomjakubowski » Mon, Oct 07, 2019, 10:43 PM UTC

braindeath wrote: post #89

tomjakubowski wrote: post #46

Earlier quoted context omitted.

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

That doesn’t mean multiple long running processes will share memory though unless they actually create a shared mapping, which I think the gp is referring to. In addition to tremendous memory waste this also kills cache performance.

I'd presume the persistence / I/O process would be pretty short lived: its job is to save a snapshot to disk so there's not much reason to let it live long.