5 ms·

Friendly reminder that Kyoto Tycoon might be an option. Has real persistence (not just dump everything / reload everything, or cripple performance by turning on

Friendly reminder that Kyoto Tycoon might be an option. Has real persistence (not just dump everything / reload everything, or cripple performance by turning on aof), is multi-threaded, scriptable via lua, amazing performance.

manigandham 7y ago
KT has been out of maintenance for years and doesn't have all the higher-level useful data structures and operations that Redis does. There are lot of options if you just wanted fast key/value with persistence from ScyllaDB, Tarantool, LMDB, RocksDB, etc.
- coleifer 7y ago
  Eh, some of those are embedded, kt is a server like Redis or memcached. Kt was good enough for cloudflare, if that's enough of an endorsement.
  - manigandham 7y ago
    I know, my point is that performance is rarely the need. Usability and useful APIs are more important which Redis excels at. Cloudflare stopped using KT because it wasn't much else other than simple and fast, and was missing a lot of other features.
    - coleifer 7y ago
      This post / the topic was performance
      - derefr 7y ago
        Normally, when choosing components for a software stack, infra engineers are pretty good about choosing the components with the fewest features that fit the semantics that the software's design demands. You wouldn't choose Postgres where sqlite would do; you wouldn't choose Kubernetes where a single machine running Docker would do; etc. Components with simpler semantics are not only lower-maintenance, but usually can be more highly optimized due to having fewer "gotcha" requirements going into building them. Which is to say, if someone is looking for a "faster Redis", it's probably because they originally went with Redis as the "least software they can get away with" for their particular design needs. Any, therefore, any software that has more narrow semantics than Redis itself is not, in fact, a viable "faster Redis", for anyone but those who had no reason to be running Redis in the first place.

manigandham 7y ago

KT has been out of maintenance for years and doesn't have all the higher-level useful data structures and operations that Redis does. There are lot of options if you just wanted fast key/value with persistence from ScyllaDB, Tarantool, LMDB, RocksDB, etc.

coleifer 7y ago
Eh, some of those are embedded, kt is a server like Redis or memcached. Kt was good enough for cloudflare, if that's enough of an endorsement.
- manigandham 7y ago
  I know, my point is that performance is rarely the need. Usability and useful APIs are more important which Redis excels at. Cloudflare stopped using KT because it wasn't much else other than simple and fast, and was missing a lot of other features.
  - coleifer 7y ago
    This post / the topic was performance
    - derefr 7y ago
      Normally, when choosing components for a software stack, infra engineers are pretty good about choosing the components with the fewest features that fit the semantics that the software's design demands. You wouldn't choose Postgres where sqlite would do; you wouldn't choose Kubernetes where a single machine running Docker would do; etc. Components with simpler semantics are not only lower-maintenance, but usually can be more highly optimized due to having fewer "gotcha" requirements going into building them. Which is to say, if someone is looking for a "faster Redis", it's probably because they originally went with Redis as the "least software they can get away with" for their particular design needs. Any, therefore, any software that has more narrow semantics than Redis itself is not, in fact, a viable "faster Redis", for anyone but those who had no reason to be running Redis in the first place.