3 ms·

Two small comments: 1) memcached has excellent support for checking cache hit ratio. Just telnet to it and execute "stats". Most client libraries have support

Two small comments: 1) memcached has excellent support for checking cache hit ratio. Just telnet to it and execute "stats". Most client libraries have support for the stats command, and there is a Prometheus exporter for memcached that works really well. 2) A problem I've seen with Redis is that it is _stateful_. While, "it's still not really any more complicated to install/maintain than memcached" is true for running it locally, I keep seeing over and over again how engineers i) don't think about backup/restore at all. ii) expect it to behave like a disk-backed database and don't consider it's limited to the amount of memory you have. iii) don't consider that it (usually) is a secondary data store that can be out of sync with primary datastore (distributed commits are hard). iv) don't consider that a proper Redis setup likely needs support for point-in-time recovery and the complexities around that and redundancy/failover. While Redis is easy to setup as a cache and likely doesn't need the above, I keep seeing them organically grow into being used for other use cases where the above things are not in place, yielding very high operational risks sometimes not acknowledged anywhere.

mmahemoff 5y ago
Thanks. On (2) I'm thinking only of Redis as a memory cache, in that case I think it's fairly simple, as with Memcached. Once you start doing persistence, then yes, it becomes a bit more complicated with a lot of other things to worry about, especially that you need RAM >= disk space. While it's another advantage of Redis that persistent caching is possible (and can be bolted on at a later date), taking advantage of it definitely adds some complexity and room for error.
atodorov99 5y ago
2) III - Distributed commits aren't just hard they don't exist. Redis and your primary dB can never hold the same data - at most you can guarantee only for IMMUTABLE data that what is in DB is also in redis. I've seen others and myself included try to sync them when solving some problems. Just because it is so natural to believe it possible to do. Then you find out you are running circles. Honestly for the use cases I've met Redis has only made sense to be used as a cache for performance or message bus. Your primary data store is gonna give you the other guarantees of backups, consistency etc... Unless somebody usew it as their primary store, but everybody chooses their own religion I guess.

mmahemoff 5y ago

Thanks. On (2) I'm thinking only of Redis as a memory cache, in that case I think it's fairly simple, as with Memcached. Once you start doing persistence, then yes, it becomes a bit more complicated with a lot of other things to worry about, especially that you need RAM >= disk space. While it's another advantage of Redis that persistent caching is possible (and can be bolted on at a later date), taking advantage of it definitely adds some complexity and room for error.

atodorov99 5y ago

2) III - Distributed commits aren't just hard they don't exist. Redis and your primary dB can never hold the same data - at most you can guarantee only for IMMUTABLE data that what is in DB is also in redis. I've seen others and myself included try to sync them when solving some problems. Just because it is so natural to believe it possible to do. Then you find out you are running circles. Honestly for the use cases I've met Redis has only made sense to be used as a cache for performance or message bus. Your primary data store is gonna give you the other guarantees of backups, consistency etc... Unless somebody usew it as their primary store, but everybody chooses their own religion I guess.