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

31–40 of 77 posts

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

#31

Post by tyingq »

slaymaker1907 wrote: post #29
tyingq wrote: post #26

I'm curious about the name. Putting "DB" in the name sort of suggests it might support persistence, more data than fits in memory, write-through, etc. Is that the case? Or is the "DB" some nod that clustering means that "in-memory" doesn't have to be ephemeral? Or in short, where is KeyDB headed, longer term?

I don't think more data than fits in memory is a requirement. An important innovation in databases has been the realization that there are important performance benefits from assuming all data can fit in memory even if you still provide persistence. Even persistence isn't really required. A pure analytics view of another database is still a database by itself, but it doesn't need to actually persist anything. It seem…

I wasn't suggesting they had to, or should happen. Just trying to understand the future plans since the "DB" term is there.

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

#32

Post by ddorian43 »

nemothekid wrote: post #18
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.

It's been a long time since I've looked at KeyDB, but IIRC KeyDB is just Redis plus a spinlock. It's actually still very performant. There are other "toy" reimplementations of Redis in Rust that take the same approach and aren't even as performant as single threaded Redis. The next approach you could take is using something like Glommio and take a thread-per-core design to Redis. I think that approach has a lot of po…

RonDB (NDB Cluster) takes a different approach to threading and claims it's faster than scylladb-style sharding http://mikaelronstrom.blogspot.com/2021/03/designing-thread-...

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

#33

Post by Thaxll »

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.

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

#34

Post by hitekker »

solosoyokaze wrote: post #24
eloff wrote: post #20

Earlier quoted context omitted.

I don't read that as antagonistic. I think you're just being too sensitive, or reading a tone into the test that isn't actually there.

It just doesn't sound very friendly to the open source community. "If they won’t then we will." sounds harsh imho.

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.

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

#35

Post by jdsully »

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

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

#36

Post by solosoyokaze »

hitekker wrote: post #34
solosoyokaze wrote: post #24

Earlier quoted context omitted.

It just doesn't sound very friendly to the open source community. "If they won’t then we will." sounds harsh imho.

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.

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

#37

Post by hilbertseries »

jdsully wrote: post #25
troquerre wrote: post #23

Are you concerned about AWS starting a competitor to keydb cloud/have you considered modifying your license to prevent that from happening? I'd imagine that'd be important in ensuring the long term sustainability of keydb development

They have Elasticache which is always a concern. In terms of open source projects my read is they really don’t want to run their own and are much more comfortable operating open source as a service. They “forked” Elastic Search 2 years ago and basically did nothing with it until it was re-licensed a few months ago. Now that they are investing more into it I’m interested to see how they handle it long term.

This seems somewhat orthogonal to the question asked. They have Kinesis which competes with Kafka, SQS with competes with a variety of message queues, redshift, dynamo db, etc and it’s my understanding that Athena was originally a fork of Presto. So, they could definitely move more heavily into the caching space if they see there’s demand.

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

#39

Post by eloff »

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.

I don't see forking as being aggressive. It's the natural thing to do if you want to take the project in a different direction to its stewards. Often lessons are learned from that process and the learnings integrated back into the main project.

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

#40

Post by jdsully »

hilbertseries wrote: post #37
jdsully wrote: post #25

Earlier quoted context omitted.

They have Elasticache which is always a concern. In terms of open source projects my read is they really don’t want to run their own and are much more comfortable operating open source as a service. They “forked” Elastic Search 2 years ago and basically did nothing with it until it was re-licensed a few months ago. Now that they are investing more into it I’m interested to see how they handle it long term.

This seems somewhat orthogonal to the question asked. They have Kinesis which competes with Kafka, SQS with competes with a variety of message queues, redshift, dynamo db, etc and it’s my understanding that Athena was originally a fork of Presto. So, they could definitely move more heavily into the caching space if they see there’s demand.

Elasticache is already that competitor. They are scary to be sure but they have some weaknesses. The main one is branding: Elasticache is a white label Redis not it’s own thing, to the point where their own docs use the two interchangeably.
Post reply on HN