4 ms·

I don’t think that’s necessarily always true. I was recently looking into using Redis as a regular database. Unfortunately data is still kept in memory even if

• ReflectedImage 3y ago
  Perhaps you are looking for LMDB?
• tayo42 3y ago
  What were you trying to accomplish? Curious about your use if you can share it
• super_scooper 3y ago
  >You’d be surprised what people want! If what you want is persistent k/v, then there are already tons databases that can do that. Redis has a different use case, so what are you trying to say? That you want to misuse tools?
  • lmm 3y ago
    > If what you want is persistent k/v, then there are already tons databases that can do that. Are there? What's a good, mainstream, persistent k/v for cheap single-node instances? PostgreSQL's KV support isn't good enough, Cassandra and MongoDB expect to be set up as a cluster and have all the overhead of that, BikeshedDB is alpha and I won't touch their upstream for obvious reasons, CouchDB is pretty much unmaintained, ....
    • chokolad 3y ago
      How about LMDB ? It’s single writer/multiple reader, very fast and reliable.
      • lmm 3y ago
        This thread is my first time hearing of it, it doesn't seem particularly established/mature (e.g. I can't find cloud services offering managed instances, whereas there are plenty of those for Redis)
        • ddorian43 3y ago
          You didn't read enough what it actually is. Its embedded db like rocksdb.
          • lmm 3y ago
            Then it's hardly a substitute for Redis.
            • ddorian43 3y ago
              You put redis on top of it.
              • lmm 3y ago
                Are you suggesting that there's no need for Redis to integrate persistent-storage support because every user should download some library and patch the Redis source themselves? And that would somehow be better?
                • ddorian43 3y ago
                  I'm suggesting you haven't read enough before replying, just like I did on my first comment. See "Myrocks" as an example of what the first user meant with lmdb. Replace "mysql -> redis" and "rocksdb -> lmdb".
                  • lmm 3y ago
                    I'm looking for a standard, well-known, drop-in product - that's what Redis is, that's why persistent storage support in Redis is interesting. If I have to search up some combination thing then it's already a non-starter.
    • chx 3y ago
      RocksDB?
      • lmm 3y ago
        RocksDB is cool but it seems to be more of a toolkit for building your own K/V store than a standalone product like Redis?
    • FridgeSeal 3y ago
      RocksDB, Badger if you want embedded; which seems to be a more popular mechanism among kv-stores. LMDB. FoundationDB, etcd, consul in single node mode.
      • lmm 3y ago
        I'm not looking for embedded, we're talking about a Redis substitute. etcd/consul feel oriented towards running as a cluster and I'd expect overhead for that. FoundationDB is potentially a good shout, but it's not that established, e.g. it doesn't seem to be available in a managed way in cloud hosting environments.
        • FridgeSeal 3y ago
          KV Stores seem to be in a kind of split place, existing either as embedded, or full cluster mode. There isn’t really a “sqlite” or “postgres” of persistent KV stores. Cloud providers ship their own proprietary KV-stores: Dynamo in AWS, Bigtable in GCP. If you are ok with hosted, Scylla is also an option. I’m always shocked that people use Redis for anything other than an ephemeral cache.
          • lmm 3y ago
            Your second paragraph follows from your first - people use Redis in this space because it's the closest thing there is to an "sqlite" or "postgres" for KV. Which is why I think Redis with persistence actually makes a lot of sense and fills a gap in the market.
• reconditerose 3y ago
  I'll bite. I think with most relational and document databases, my view of the "classical world", you are often storing all of your data in tables or documents in a structured way. Normalizing the data where possible. You're then building indexes on that data to pull it out in a useful operational, optimizing for the most common operations. If a new use case comes up, you add some more tables, add some constraints, and create some new indexes. I think with Redis, you are starting knowing that your use case needs to be fast. You start with the access patterns and fit that into key/value lookups (or search with modules). You're typically denormalizing the data, duplicating it or aggregating it from other places, so that you can serve operational data fast. Otherwise, just use in-memory SQL.