back to article In-memory database Redis wants to dabble in disk

Redis, the go-to in-memory database used as a cache and system broker, is looking to include disk as part of a tiered storage architecture to reduce costs and broaden the system's appeal. Speaking to The Register, CEO Rowan Trollope said he hoped the move would help customers lower costs and simplify their architecture. Redis …

  1. andy 103
    Boffin

    to make Redis "more like your classic database,"

    No no no! Don't do this.

    One of the great things about Redis is that it doesn't have the overhead of SQL databases.

    I use Redis alongside MySQL to build web applications. Redis is brilliant when you need to store temporary or arbitrary data, serverside, without the overhead of something like MySQL. For us we create Redis keys for users in our applications and then write serialized data into that key. Getting data in and out of that structure is trivial not to mention fast. It's generally always data that doesn't need to be persisted although I believe you can also write to disk if necessary anyhow. I don't want to write an SQL-style query to either read or write data like that. I definitely don't want or need transactions or any of the "safety" features afforded by MySQL for the type of data I'm describing.

    Redis is good in its current form and has many, many different use cases. There isn't a right or wrong way to use it except for the fact it's absolutely not a replacement for something like MySQL. Different tools for different jobs.

    1. Dizzy Dwarf

      Re: to make Redis "more like your classic database,"

      Sounds like you don't actually need a database at all.

      1. katrinab Silver badge
        Meh

        Re: to make Redis "more like your classic database,"

        Well if you definition of "database" is the likes of Postgres and MariaDB, then yes.

        But a key-value store is a type of database, and sometimes, not always, it is the right choice.

        1. OhForF' Silver badge

          Re: to make Redis "more like your classic database,"

          A hash table is a simple form of a key-value store but i wouldn't call it a type of database.

          There are probably good reasons why Andy 103 is using Redis and MySQL but he hasn't given us those reasons in his post.

          From what he told us he doesn't need any part of the ACID (Atomicity, Consistency, Isolation, Durability) standard set of database features so why he's using a database is a valid question.

          1. bombastic bob Silver badge
            Devil

            Re: to make Redis "more like your classic database,"

            "A hash table is a simple form of a key-value store but i wouldn't call it a type of database."

            That is my preference, and I normally just pound out the code directly when it's needed (rather than shoe-horning in some 3rd party dependency).

            A [scaled] CRC makes for a nice hash method. COPYPASTA a 20 line function and that part's done. Then you just need a simple structure array to store it in. A few more minutes and you've got a class or handful of simple management utility functions. Done. Serial lookup or hashed index (as needed).

          2. andy 103

            Re: to make Redis "more like your classic database,"

            "There are probably good reasons why Andy 103 is using Redis and MySQL but he hasn't given us those reasons in his post.

            From what he told us he doesn't need any part of the ACID (Atomicity, Consistency, Isolation, Durability) standard set of database features so why he's using a database is a valid question."

            I said in the OP that we use Redis alongside MySQL. For very different things.

            We use Redis for storing serialized key/value data which is generally only needed on a temporary basis. If we're persisting data or need to query it more broadly we use MySQL, and of course we need the ACID properties that come with that.

            They aren't used interchangeably and that was very much the point of my original comment. Redis is good when you don't need the overhead of something like MySQL. The point being that because it lacks some "database-like features" that actually makes it good at least for certain use-cases.

  2. Ken Moorhouse Silver badge

    So long as the database is not shared with remote users.

    Remembering Netware issues when caching was set to "on" on their Client interface software when network database applications were in use.

  3. DevOpsTimothyC

    Client or Server issues

    Oh please no.

    My 2 major gripes with redis is that it ignores many of the memory settings (At the global level) in terms of pool sizes. I've had redis crash more times than I care to count because set a max memory side without how objects should expire. Including a case where they used persistent stores which caused a reboot loop where it would attempt to restore a dB that was too big to fit into RAM and be OOM killed over and over.

    The other is where clients handle shared. The whole cluster mode on/off

    That's before we even start getting into is this a cache / temporary store to speedup the application, or is it a permanent data store that is critical for the app to be able to start and run.

  4. bombastic bob Silver badge
    Devil

    simple adaptation

    One possibility, just use a swapfile-backed memory map for your in-memory storage, one that is persistent (if necessary). On Linux, the 'mmap()' C lib function would do nicely. Then you'd just need some kind of utility to fix things or otherwise manage some settings and there ya have it.

  5. Steve Channell

    Not quiet as daft as it sounds

    Redis uses as time-to-live (TTL) mechanism to avoid cache-eviction problem of not knowing whether there is still a weak reference to the cached-object held by a remote server - in essence it pushes the problem to the application client. That's fine for session information, but in other cases it means either :

    1) combine cache write with an async database write.

    2) set a long TTL, hopefully with a cache-delete when no longer required.

    The solution is the same as one used by Kafka: write older TTL objects to a SSD key-store (RocksDB/Speedb) rather than just loose them or crash - describing it persistence rather than as a fix.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like