61–70 of 77 posts
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.
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.
It’s basically back to the multi-threading vs multiprocessing debate that also exists in Python. With multiprocessing, you have more overhead but the client itself is simpler.
It’s kind of a weird in between where you need more scalability then a single redis but no so much that you want to go to a cluster.
Does anyone have any experience with these other Redis clones? I need to write a benchmark on these someday (the outline for the blog post is already written), but have restricted my yak shaving recently: - https://github.com/Tencent/Tendis - https://github.com/Netflix/dynomite On a separate note, was FLASH (as in "flash memory") supposed to be an acronym? I've never seen people treat it as an acronym before.
I recommend keydb in almost every case redis is used.
I forked Redis to create Thredis almost 9 years ago. Some notes on how it was implemented: https://github.com/grisha/thredis/blob/master/README-THREDIS Then I added SQLite to it, more details here: http://thredis.org This was all done mostly for fun, though I did use it in a an actual project for a while.
I can't find in documents but does multi-threading effect consistency somehow? Is there a chance that I wouldn't read what I just wrote? I'm talking about single node, not about replication, cluster etc. If it provides same consistency, is threading like : sock_read(); lock(datastructures); set x=3; unlock(datastructures); sock_write();
Yea that was roughly KeyDB’s original design. There’s some nuance in the locking like ensuring it’s both fair and fast so P99 latency doesn’t get out of control. In the Enterprise codebase we can take snapshots which lets us do reads without the lock but it’s a bit of work to enable for commands so it only applies to KEYS and SCAN at the moment.
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
Earlier quoted context omitted.
Yea that was roughly KeyDB’s original design. There’s some nuance in the locking like ensuring it’s both fair and fast so P99 latency doesn’t get out of control. In the Enterprise codebase we can take snapshots which lets us do reads without the lock but it’s a bit of work to enable for commands so it only applies to KEYS and SCAN at the moment.
can you share more details about it? I thought locks are slow, but despite locks the is latency halved here.
When I first tried making KeyDB I used posix locks. Those were way too slow.
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.
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.
Earlier quoted context omitted.
Does clean room in this case mean you didn't look at the Redis source? Is there some licensing condition where this is required?
No, I don't believe that's what it means in this case. I took the usage to mean that since Rust has memory model which is different enough from C to require a redesign. I looked at many implementations of Redis and read many KV papers. My redesign reason was similar to a "clean room Rust" reason, I desired a memory model that used shared memory that was independent of the protocol (Redis RESP in this case), allowing…