> For Modern Hardware fully utilizes underlying core to get higgher throughput and better hardware utilization.
Would be great to disclose details of this one. I'm interested in using what DiceDB achieves higher throughput.
DiceDB
111–120 of 143 posts
Re: DiceDB
#112FYI: Here is the creator and maintainer's profile: https://github.com/arpitbbhayani
Is there a plan to commercialise this product? (Offer commercial support, features, etc.) I could not find anything obvious from the home page.
Re: DiceDB
#113| 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 | UPD Nevermind, I didn't have my eyes open. Sorry for the confusion. Something I still fail to understand is where you can actually spend 20ms while…
I had the same reaction as you. And that's for 4 simultaneous clients, too, for a single client you get 3159 ops/s (from https://dicedb.io/benchmarks/). I'm not too familiar with in-memory databases in general but I would have expected figures in the millions on modern hardware. Makes me feel there's some hidden bottleneck somewhere and the benchmarks are not purely measuring the performance of the software.
Re: DiceDB
#114Re: DiceDB
#115Earlier quoted context omitted.
It was my first thought as well, before reading the landing page.
Yeah, and I'm sure someone clicked it thinking it was a DB for EA's Dice Studios. If you expose something to enough people you'll get some unreasonable takes and interpretations of it. It's important to ignore them.
> If you expose something to enough people you'll get some unreasonable takes and interpretations of it. It's important to ignore them.
Quite literally the main function of dice is to give you random numbers. Looking over the website and readme I could not surmise why they would call it DiceDB except for "it sounds nice", but it's absolutely not unreasonable to look at the name and have a thought "it's probably a joke project about random results".
Re: DiceDB
#116> fully utilizes underlying core to get higgher throughput and better hardware utilization
FYI this is a misspelling of "higher"
Re: DiceDB
#117I feel like this needs a ‘Why DiceDB instead of Redis or Valtio’ section prominently on the homepage.
Did you mean Valkey, or has the js community now managed to shoehorn an entire high-availability database server into a javascript object proxy?
It’s only a matter of time xD but yes, I meant Valkey.
I was typing that out and felt like something was wrong but couldn’t put my finger on what.
Re: DiceDB
#11815655 ops a second with a Hetzner CCX23 machine with 4 vCPU and 16GB RAM is rather slow for an in-memory database I hate to say it. You can't blame that on network latency as for example supermassivedb.com is written in go and achieves magnitudes more, actually x20 and it's persisted.. I must investigate the bottlenecks with Dice.
Re: DiceDB
#119Earlier quoted context omitted.
Haven't looked at the code, but enforcing mutual exclusion between writers but not readers can make sense for a single-writer lock-free algorithm.
> single-writer lock-free algorithm I understand the need for correct lock-free impls: Given OP's description, simply avoiding read mutexes can't be the way to go about it?
I don't use Go.
If I'm reading this correctly, they are recommending a lock in this situation. However, they are saying the implementations has two options, either raise an error reporting the race (if the implementation is told to do so), or, because the value being read is not larger than a machine word, reply to the read with a correct value from a previous write. If true then it cannot reply with corrupted data.
Re: DiceDB
#120Earlier quoted context omitted.
In a similar vein, lots of software is Mac-only, but omits to say this anywehere. You just get to the downloads page and see that there are only mac packages. As if nobody ever uses anything else.
Why should they care about non-users. Offering our even mentioning choice only creates uncertainty and confusion in potential customers.
How hard is it to add two sentences that says only macOS is supported now and in the near future? I’d rather do that than annoy future potential customers who might have a Mac or plan to get one at some point