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

11–20 of 77 posts

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

#11

Post by jdsully »

secondcoming wrote: post #9
klohto wrote: post #2

Any experience with KeyDB in production? Is the Flash support in KeyDB still only in "Pro" version? Cannot find anything in the docs.

Someone on my team looked at it, and for our workload (lots of MGETs per query) it wasn't that much better than redis. We may still go with it though, our GCP Memorystore instance is pretty much at 100% CPU constantly. We have still yet to evaluate Redis6.

Long running commands are still a problem. We have infrastructure in the Enterprise version to alleviate this but so far we’ve enabled it only for KEYS and SCAN. MGET does come up frequently so it’s on our radar.

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

#12

Post by jdsully »

Scarbutt wrote: post #10
jdsully wrote: post #3

Earlier quoted context omitted.

Yea FLASH is only in the Enterprise version. At a rough level the open source is the best cache we can make while pro/enterprise is the best full featured database. It’s not fully there yet but the end goal is you can get caching and persistence in one place.

What persistence options does KeyDB has that Redis doesn't?

The FLASH feature in Enterprise can send all writes to disk before replying +OK, however notably we don’t fsync (AOF is still recommended if you need that). In these deployments it’s not necessary to use RDB or AOF except for replication.

And of course we have all the existing options already in Redis.

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

#13

Post by jdsully »

welder wrote: post #6

There's a post about another Redis-clone on the front page today called SSDB. Seems to be a common occurrence: https://news.ycombinator.com/item?id=19213261

There are a few, some predate us like Threadis. Most only offer a subset of the Redis feature set where we really wanted to be a drop in replacement.

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

#14

Post by ddorian43 »

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.

> You would get the zero-cost multi-threading,

You kinda have to look at how things really work underneath before you can apply buzzwords to a database.

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

#15

Post by solosoyokaze »

"My thought process was simply that there is a big need here and Redis had for some reason decided not to serve it. If they won’t then we will."

I feel like this and the general tone of the article are needlessly antagonistic toward Redis. KeyDB is building their entire business off of it after all.

There may very well be a need for multi-threaded Redis, but Redis as it stands today is an amazing project and there's something to keeping it simple along the lines of the project philosophy.

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

#16

Post by jdsully »

solosoyokaze wrote: post #15

"My thought process was simply that there is a big need here and Redis had for some reason decided not to serve it. If they won’t then we will." I feel like this and the general tone of the article are needlessly antagonistic toward Redis. KeyDB is building their entire business off of it after all. There may very well be a need for multi-threaded Redis, but Redis as it stands today is an amazing project and there's…

I’ve learned to appreciate Salvatore’s stance on simplicity the longer we’ve gone on with KeyDB. But when I first made KeyDB two years ago I was really perplexed at the decisions he made with respect to threading.

It’s not my intention to be antagonistic. I’ve had a lot of projects over the years that went nowhere and a part of me is sad that the one with the most traction is a fork.

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

#17

Post by medium_burrito »

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 to check out Elasticache, which is really good.

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

#18

Post by nemothekid »

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 potential, but the design becomes more complex (you now need something like distributed transactions for "cross-core" Redis transactions and mutli-gets)

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

#19

Post by eloff »

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.

> zero-cost multi-threading

I think you mean zero cost abstractions. Which aren't usually zero cost, but just zero additional cost over doing it yourself.

There's no such thing as zero cost multi threading. Just tradeoffs. Rust actually doesn't help with performance here (it gets in the way often) but it definitely does help with correctness - which is truly hard with multi threaded programs.

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

#20

Post by eloff »

solosoyokaze wrote: post #15

"My thought process was simply that there is a big need here and Redis had for some reason decided not to serve it. If they won’t then we will." I feel like this and the general tone of the article are needlessly antagonistic toward Redis. KeyDB is building their entire business off of it after all. There may very well be a need for multi-threaded Redis, but Redis as it stands today is an amazing project and there's…

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.
Post reply on HN