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 …
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.
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.
"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).
"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.
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.
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.
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.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
