[flagged]
DiceDB
31–40 of 143 posts
Re: DiceDB
#32This seems orders of magnitude slower than Nubmq which was posted yesterday: https://news.ycombinator.com/item?id=43371097
Re: DiceDB
#33Is there a single sentence anywhere that describes what it actually is?
Arpit here. DiceDB is an in-memory database that is also reactive. So, instead of polling the database for changes, the database pushes the resultset if you subscribe to it. We have a similar set of commands as Redis, but are not Redis-compliant.
Would "key-value" not have a place in the description?
This application may be very capable, but I agree with the person saying that its use-case isn't clear on the home page, you have to go deeper into the docs. "Smarter than a database" also seems kind of debatable.
Re: DiceDB
#34Earlier quoted context omitted.
This is a lot clearer than any information I found anywhere else. There wasn't any room on your website, README, or docs for this summary?
It is right there on the landing page. But, let me highlight it a bit.
IMO, replace "More than a Cache.
Smarter than a Database." with an actual description.
The saying is cute but does not really convey information the reader is after. And that spot is where you want people to immediately understand what it is.
Re: DiceDB
#35[flagged]
I am not sure if this is satire or not...
Re: DiceDB
#36 | Metric | DiceDB | Redis |
| -------------------- | -------- | -------- |
| Throughput (ops/sec) | 15655 | 12267 |
| GET p50 (ms) | 0.227327 | 0.270335 |
| GET p90 (ms) | 0.337919 | 0.329727 |
| SET p50 (ms) | 0.230399 | 0.272383 |
| SET p90 (ms) | 0.339967 | 0.331775 |
Something I still fail to understand is where you can actually spend 20ms while answering a GET request in a RAM keyvalue storage (unless you implement it in Java).
I never gained much experience with existing opensource implementations, but when I was building proprietary solutions at my previous workplace, the in-memory response time was measured in tens-hundreds of microseconds. The lower bound of latency is mostly defined by syscalls so using io_uring should in theory result in even better timings, even though I never got to try it in production.
If you read from nvme AND also do the erasure-recovery across 6 nodes (lrc-12-2-2) then yes, you got into tens of milliseconds. But seeing these numbers for a single node RAM DB just doesn't make sense and I'm surprised everyone treats them as normal.
Does anyone has experience with low-latency high-throughput opensource keyvalue storages? Any specific implementation to recommend?
Re: DiceDB
#37Earlier quoted context omitted.
This is a lot clearer than any information I found anywhere else. There wasn't any room on your website, README, or docs for this summary?
It is right there on the landing page. But, let me highlight it a bit.
When I ctrl+F the landing page for key and value, I find nothing. Reading it in full, I also come up empty handed. Which part of the landing page implies it's a key value store?
Re: DiceDB
#38Any reason to use this over Valkey, which is now faster than Redis and community driven? Genuinely interested.
Re: DiceDB
#39Earlier quoted context omitted.
Arpit here. DiceDB is an in-memory database that is also reactive. So, instead of polling the database for changes, the database pushes the resultset if you subscribe to it. We have a similar set of commands as Redis, but are not Redis-compliant.
So like RethinkDB? https://rethinkdb.com/
Not a month goes by where I don’t remember it at least once and realize that I still miss it.
This seems more like Redis though
Re: DiceDB
#40Earlier quoted context omitted.
It is right there on the landing page. But, let me highlight it a bit.
When I ctrl+F the landing page for key and value, I find nothing. Reading it in full, I also come up empty handed. Which part of the landing page implies it's a key value store?
They did not say anything about key/value in their message.