3 ms·

True, it's rarely just raw performance. KeyDB has other advantages like multi-threading and disk-based persistence (instead of being limited by RAM) that makes

True, it's rarely just raw performance. KeyDB has other advantages like multi-threading and disk-based persistence (instead of being limited by RAM) that makes it better at utilizing your server resources and handling larger scales.

azhng 7y ago
But isn't the point of Redis is to be used as a caching layer instead of persistent layer
- t0mbstone 7y ago
  But what if you could have the speed of RAM-based storage, and still have persistence? Sounds pretty appealing to me, personally.
  - penagwin 7y ago
    You already get this with either Redis or Keydb. The problem is that to avoid the disk being the bottleneck you must write to RAM, then later to the disk (you can't wait for confirmation that it was written) which means that even though a key may successfully be written to the DB, it hasn't been confirmed to persist. Basically redis can't necessarily guarantee data safety - which is perfectly fine for it's normal use case as a caching layer and data you don't necessarily care if you lose (for example rate limiting relies on tracking the number of requests/s within say an hour - if you lose the data you don't really care). User sessions too, worst case people have to log in again, meh whatever.
    - manigandham 7y ago
      The major bottleneck for most applications using Redis is the RAM capacity, not the write performance. Disk persistence can be more than fast enough as proven by dozens of key/value stores out there.
  - lllr_finger 7y ago
    Sounds like an embedded key value store, ie. RocksDB. I've used it with great success in constrained environments and also when pushing cache to the edge for stable, low-latency, high volume APIs.
- nine_k 7y ago
  You can use redis as a write-back cache that serves spikes well and streams the state to disk (or an RDBMS) in a rate-limited manner in the background.
- manigandham 7y ago
  Redis is a data structure server rather than a simple key/value store. It's very useful in lots of scenarios, even if the persistence means it doesn't have ACID semantics. It would be great to remove limitations like RAM-only capacity in exchange for a slight performance hit, and while also gaining better core utilization. We used ScyllaDB (a very fast cassandra clone) in the past for the cpu/disk scalability but always felt Redis offered better APIs. Now it's a real option.
jrochkind1 7y ago
> ...it's rarely just raw performance. KeyDB has other advantages like multi-threading... What are the advantages of "multi-threading" other than for performance?
- manigandham 7y ago
  Taking advantage of all your cores. Redis is awkward at high capacity since most servers scale CPU with RAM and you'll end up with most cores doing nothing. You can manually run multiple instances on the same server but now they're separate databases with operations and sharding overhead. Multithreading IO also reduces the latency hit from disk-persistence and provides more concurrency and throughput, which is a great tradeoff when you don't really need sub-millisecond performance but want the same API across a larger dataset limited by disk instead of RAM space.
  - fwip 7y ago
    That's just performance spelled differently.
    - manigandham 7y ago
      Ok fair. Disk being primary storage is still a ops and scalability benefit.
  - rumanator 7y ago
    > Taking advantage of all your cores. That means nothing at all, if performance is not your concern.
  - jrochkind1 7y ago
    >> What are the advantages of "multi-threading" other than for performance? > Taking advantage of all your cores. Uh, is there any reason you'd want to "take advantage of all your cores" other than performance? The question/proposal/dialog we started from, don't forget, was: 1. Redis is already as performant as I want, it's not even close to being a bottleneck, so I have no need for multi-threading, and this is a _very very common_ case, as redis is performant enough for a lot. 2. There are other advantages of multi-threading than performance. (Ie, other reasons you'd want it despite 1). You seem to just be going around in circles. If 1, why would you care about "taking advantage of all your cores"?

azhng 7y ago

But isn't the point of Redis is to be used as a caching layer instead of persistent layer

t0mbstone 7y ago
But what if you could have the speed of RAM-based storage, and still have persistence? Sounds pretty appealing to me, personally.
- penagwin 7y ago
  You already get this with either Redis or Keydb. The problem is that to avoid the disk being the bottleneck you must write to RAM, then later to the disk (you can't wait for confirmation that it was written) which means that even though a key may successfully be written to the DB, it hasn't been confirmed to persist. Basically redis can't necessarily guarantee data safety - which is perfectly fine for it's normal use case as a caching layer and data you don't necessarily care if you lose (for example rate limiting relies on tracking the number of requests/s within say an hour - if you lose the data you don't really care). User sessions too, worst case people have to log in again, meh whatever.
  - manigandham 7y ago
    The major bottleneck for most applications using Redis is the RAM capacity, not the write performance. Disk persistence can be more than fast enough as proven by dozens of key/value stores out there.
- lllr_finger 7y ago
  Sounds like an embedded key value store, ie. RocksDB. I've used it with great success in constrained environments and also when pushing cache to the edge for stable, low-latency, high volume APIs.
nine_k 7y ago
You can use redis as a write-back cache that serves spikes well and streams the state to disk (or an RDBMS) in a rate-limited manner in the background.
manigandham 7y ago
Redis is a data structure server rather than a simple key/value store. It's very useful in lots of scenarios, even if the persistence means it doesn't have ACID semantics. It would be great to remove limitations like RAM-only capacity in exchange for a slight performance hit, and while also gaining better core utilization. We used ScyllaDB (a very fast cassandra clone) in the past for the cpu/disk scalability but always felt Redis offered better APIs. Now it's a real option.

jrochkind1 7y ago

> ...it's rarely just raw performance. KeyDB has other advantages like multi-threading... What are the advantages of "multi-threading" other than for performance?

manigandham 7y ago
Taking advantage of all your cores. Redis is awkward at high capacity since most servers scale CPU with RAM and you'll end up with most cores doing nothing. You can manually run multiple instances on the same server but now they're separate databases with operations and sharding overhead. Multithreading IO also reduces the latency hit from disk-persistence and provides more concurrency and throughput, which is a great tradeoff when you don't really need sub-millisecond performance but want the same API across a larger dataset limited by disk instead of RAM space.
- fwip 7y ago
  That's just performance spelled differently.
  - manigandham 7y ago
    Ok fair. Disk being primary storage is still a ops and scalability benefit.
- rumanator 7y ago
  > Taking advantage of all your cores. That means nothing at all, if performance is not your concern.
- jrochkind1 7y ago
  >> What are the advantages of "multi-threading" other than for performance? > Taking advantage of all your cores. Uh, is there any reason you'd want to "take advantage of all your cores" other than performance? The question/proposal/dialog we started from, don't forget, was: 1. Redis is already as performant as I want, it's not even close to being a bottleneck, so I have no need for multi-threading, and this is a _very very common_ case, as redis is performant enough for a lot. 2. There are other advantages of multi-threading than performance. (Ie, other reasons you'd want it despite 1). You seem to just be going around in circles. If 1, why would you care about "taking advantage of all your cores"?