Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

How you would suggest to demonstrate visually that there are no trade-offs?

The tradeoff the way I see it - one needs to implement 200 Redis commands from scratch. Besides, I think DF has a marginally higher 50th percentile latency. Say, if Redis has 0.3ms for 50th percentile, DF can have 0.4ms because it uses message passing for inter-thread communication. 99th percentiles are better in DF for the same throughput because DF uses more cpu power which reduces variance under load.

Re-durability - what durability is offerred by Redis? AOF ? We will provide similar durability guarantees with better performance than AOF. We already provide snapshotting that can be 30-50 faster than of Redis.



There is usually a tradeoff between latency and throughput, although I'm not so sure this would be true for your innovation, since you've eliminated a whole chunk of fixed overhead from the system (syscall batching). However, batching in general often implies added latency

If I recall ScyllaDB has some excellent examples of demonstrating this particular tradeoff visually. A simple option would be a scatter plot where X = latency, Y = load or similar, with points coloured according to the system under test. Probably there is a better option, but this would likely be enough to sell me at least


Well in that case, I hope to have an good answer for you. Right below the benchmark graph I deliberately put a table that shows 99th percentile lantencies at *peak* throughput as reported by memtier_benchmark. 99th latency percentile of Dragonfly at its peak throughput. I put it here as well

  op r6g c6gn c7g
  set 0.8ms 1ms 1ms
  get 0.9ms 0.9ms 0.8ms
  setex 0.9ms 1.1ms 1.3ms


There are also things that are unmitigated improvements.


Does Dragonfly have a timeseries extension? Or does it support extensions?


It does not. If you refer to Redis Modules we are not planning to support those - we can just implement same features within DF.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: