3 ms·

This reminds me of the use of materialized views as both a cache strategy and as an abstraction helper.

• bravesoul2 1y ago
  And they too can slow things down. Like all caches can. Like Redis can. Cache is a leaky abstraction. (Although a materialised view is more like an index than a cache. The view won't expire requiring you to rebuild.)
  • necovek 1y ago
    I believe this same language use is what makes this article confusing: Redis is not a cache, it is a key value store. Caching is usually implemented using key value stores, but it is not an abstraction (leaky or not). In RDBMS contexts, index really is a caching mechanism (a cache) managed by the database system (query planner needs to decide when it's best to use one index or another). But as you note yourself even in these cases where you've got cache management bundled with the database, having too many can slow down (even deadlock) writes so much as the database tries to ensure consistency between these redundant data storage elements.
    • bravesoul2 1y ago
      I thought Redis grew up as a KV cache and persistent storage came later. In some sense though. If it ain't L1 it's storage :)
      • deleted 1y ago
        [deleted]
      • necovek 1y ago
        Maybe Redis started up as an in-memory KV store focused on caching use cases, but it was still a KV store that could be used for caching, or not. Even if you use "cache" in the name (eg. memcached), that's still not a cache, even if it's a KV store designed for caching.