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

KeyDB CEO Interview: Getting into YC with a Fork of Redis

console.dev

Post reply on HN
Print view View original

41–50 of 77 posts

Re: KeyDB CEO Interview: Getting into YC with a Fork of Redis

#41

Post by mayank »

jdsully wrote: post #35
Thaxll wrote: post #33

It's multithreaded but what about Redis running on a single core in a cluster? Like running 8 Redis on a single 8 cores CPU. I don't really understand the reason to run Redis on multiple core since you can run multiple Redis on a single CPU with clustering which will have better perforamce than running KeYDB with the same number of cores.

Take the scenario where you have an 9 node redis cluster. With KeyDB you could shrink that down to 3 nodes with 3 threads while getting the same throughput. This reduces the maintenance burden while also reducing latency. There's overhead to connecting to a different cluster server each time you access a seperate shard. Even better you might be able to avoid having a cluster at all. For many that’s the biggest win wi…

> There's overhead to connecting to a different cluster server each time you access a seperate shard.

While I agree with your point, this concern is easily addressed with connection pools.

Re: KeyDB CEO Interview: Getting into YC with a Fork of Redis

#43

Post by stingraycharles »

medium_burrito wrote: post #17

The real problem is the Redis Cluster protocol, which pushes all the smarts onto the client. This means each client implementation behaves differently and fails differently. I would encourage Redis users to use Envoy Proxy as the Redis client (ie use vanilla client, and use Envoy as the cluster client). You get all the HA and usefulness of Redis Cluster, but way less of the headache. Also, strongly encourage people t…

But the Envoy proxy only supports a subset of the commands. For example, it doesn’t support LPOPRPUSH, precisely because the keys could be stored in multiple nodes, and they don’t support that part of the clustering protocols.

Re: KeyDB CEO Interview: Getting into YC with a Fork of Redis

#44

Post by chadd »

We (me and some folks at my old consultancy) wrote an Erlang version of Redis (https://github.com/cbd/edis) for some of the same reasons - multithreading changes some of the scaling semantics in interesting ways. It was mostly for fun but ended up in some real projects as a simple REDIS protocol implementation front-end where the backend could be replaced with whatever the implementor wants.

Re: KeyDB CEO Interview: Getting into YC with a Fork of Redis

#45

Post by injinj »

atonse wrote: post #8

This is totally going to be a Hacker News Bingo type of question. But has anyone tried to do a clean room implementation of Redis using Rust, but speaks the same wire protocol? You would get the zero-cost multi-threading, memory safety, etc, and it would be a drop in replacement.

I've done a C clean room version and I will say that the networking part is as important as the multi-threading the data structures: https://github.com/raitechnology/raids/.

If you go to the landing page of the above, scroll down to the bottom, there is a TCP bypass solution graphed, using Solarflare Open Onload and it is capable of running several times as fast as the Linux Kernel TCP. I didn't test Redis with Open Onload, but I'm pretty sure you'll get a similar results since TCP is a major performance bottleneck in Redis as well.

Re: KeyDB CEO Interview: Getting into YC with a Fork of Redis

#46

Post by hitekker »

solosoyokaze wrote: post #36
hitekker wrote: post #34

Earlier quoted context omitted.

You should read about the concept of "forking": https://en.wikipedia.org/wiki/Fork_(software_development)#Fo... It's fundamental to the health and growth of the open source community.

I am aware. Community management is different from what is legally possible. Were a project owner start to act in a self-interested or malicious manner, then I think proudly and aggressively forking a project is a great idea. That's not Redis. Like I said, it may be a good idea to have a multi-threaded Redis, but Redis users tend to love Redis. I would probably lean into that goodwill instead of against it.

Forking is not violence you perpetuate against people you dislike.

It's a freedom; a person can disagree and go their own way instead of being hounded by zealots demanding compliance in the guise of friendliness.

Re: KeyDB CEO Interview: Getting into YC with a Fork of Redis

#47

Post by solosoyokaze »

hitekker wrote: post #46
solosoyokaze wrote: post #36

Earlier quoted context omitted.

I am aware. Community management is different from what is legally possible. Were a project owner start to act in a self-interested or malicious manner, then I think proudly and aggressively forking a project is a great idea. That's not Redis. Like I said, it may be a good idea to have a multi-threaded Redis, but Redis users tend to love Redis. I would probably lean into that goodwill instead of against it.

Forking is not violence you perpetuate against people you dislike. It's a freedom; a person can disagree and go their own way instead of being hounded by zealots demanding compliance in the guise of friendliness.

I'm simply offering the advice that the tone seems unfriendly and is likely to be taken as such by Redis users (aka potential customers).

> a person can disagree and go their own way instead of being hounded by zealots demanding compliance in the guise of friendliness

This is exactly the kind of aggressive and nebulously political tone that would not help a project gain adoption. Why be hostile?

Re: KeyDB CEO Interview: Getting into YC with a Fork of Redis

#48

Post by hitekker »

solosoyokaze wrote: post #47
hitekker wrote: post #46

Earlier quoted context omitted.

Forking is not violence you perpetuate against people you dislike. It's a freedom; a person can disagree and go their own way instead of being hounded by zealots demanding compliance in the guise of friendliness.

I'm simply offering the advice that the tone seems unfriendly and is likely to be taken as such by Redis users (aka potential customers). > a person can disagree and go their own way instead of being hounded by zealots demanding compliance in the guise of friendliness This is exactly the kind of aggressive and nebulously political tone that would not help a project gain adoption. Why be hostile?

I was going to ask about where you see hostility. But judging by your comment history, it looks like you're just trolling and starting flame wars :\

Re: KeyDB CEO Interview: Getting into YC with a Fork of Redis

#50

Post by anitil »

injinj wrote: post #45
atonse wrote: post #8

This is totally going to be a Hacker News Bingo type of question. But has anyone tried to do a clean room implementation of Redis using Rust, but speaks the same wire protocol? You would get the zero-cost multi-threading, memory safety, etc, and it would be a drop in replacement.

I've done a C clean room version and I will say that the networking part is as important as the multi-threading the data structures: https://github.com/raitechnology/raids/ . If you go to the landing page of the above, scroll down to the bottom, there is a TCP bypass solution graphed, using Solarflare Open Onload and it is capable of running several times as fast as the Linux Kernel TCP. I didn't test Redis with Open…

Does clean room in this case mean you didn't look at the Redis source? Is there some licensing condition where this is required?
Post reply on HN