I mean, the thing is that postgre is storing this data to disk, and reading and writing to disk. In other words a Persistent Datastore. Meaning data will survive a reboot of the service. Redis is a pure memory storage, it reads and writes nothing to disk. In other words it's a Volatile Datadstore. Meaning data will not survive a reboot of the service.
They serve two entirely different purposes. Redis is purely a cache server. So it stands to reason that of course it's going to be insanely fast at what it does.
But hey, want something even faster? Check out KeyDB. It's a fork of redis and I believe drop in compatible. But it uses Multithreading to do the work, where Redis stubbornly stays single thread.
The default Snapshotting is hardly ideal for what one would call "persistent". One shouldn't be storing mission critical data in a cache server in hopes it'll survive. Data in stores like Redis and especially memcached should be considered and are volatile at all times. All Redis does differently from Memcached is ocassionally (and conditionally) dump whats in it into a single file for backup. Really, if you need your key to survive and don't care about performance as much, stick to your regular database solution, it will absolutely be safer there.
> Redis is a pure memory storage, it reads and writes nothing to disk. In other words it's a Volatile Datadstore. Meaning data will not survive a reboot of the service
and you propose as to................ what? AOF? The thing that on the same page you linked too describes it as buggy and unreliable? Because that's the only other option for Redis here. Persistance is simply not Redis' strength, plain and simple.
It's a cache server. Treat it like one and everyone will be happy. Stop trying to use it like Mongo.
I don't know why you're saying on the page it says buggy and unreliable >>> it does not say that. In fact, it is say the opposite saying it's "more durable" than snapshotting. I also, disagree with your persistence is simply not Redis's strength. What kind of app are you building? A financial records banking application? No? I didn't think so. Most data is ephemeral transient type data. I.e. A setting click on one part of the app to the next. State type storage. Once the user leaves or is no longer of use in the service bye bye. It's data that's no important but the need for speed is paramount for a good user experience. Then, in this use case, Redis is very persistent with the above listed options of RDB or AOF. If you're trying to run a financial records application with need for accurate data stores then yes Redis wouldn't be persistent enough for that in a qualifying sense.
You said yourself the redis is not properly configured. It takes a decent amount of work to properly configure redis to be durable. Otherwise it is not.
You know, I simply can't think of a scenario where I'd even want Redis to be "durable". It's a great server to spin up and immediately start storing serialized values into. Building into the application layer the reliance on refreshing that key when expired or missing.
For everything else I would care about if lost to a restart, I'd store in a normal database that properly respects ACID transactions.
Can someone spoon feed me some scenarios where having _redis_ persistence is actually a desireable thing? what's the point of sacrificing the speed (what it's good at) for AOF mode, especially if it's unreliable enough for Redis' docs to make note of anyways?
Yeah, it's rare if you use Redis generally as a caching pattern.
The one case would be if the Redis is flushed (corrupt restart, or FLUSHALL command) and it causes a stampeding herd on the backend that the cache is supposed to protect. For example, a lot of web apps use something like Redis to store use session cookie values (e.g. https://docs.djangoproject.com/en/2.2/ref/settings/#std:setting-SESSION_ENGINE in Django) and losing the cache would sign everyone out which would suck. But even there, there are choices, such as the `cached_db` option in Django which *writes* to both, but then mostly *reads* from the cache.
I'm not saying whether or not you want to use Redis durably, just that if you're comparing Postgres vs Redis and not properly configuring Redis to be durable, it's not a very valid comparison. Likewise, I can't think of a situation where I'd prefer Postgres acting as an in-memory cache vs Redis.
Again, they do not make note of any concerning bug with actual usage of AOF but rather a specific command not seen anywhere in production or reported usage?
This simply isn't true. Redid can flush memory to disk and boot with that disk image. We use Redis and psql for persistent data stores without much issue. Writing to disk is an async process and typically doesn't disrupt performance unless it's a very large data set.
Comment
I mean, the thing is that postgre is storing this data to disk, and reading and writing to disk. In other words a Persistent Datastore. Meaning data will survive a reboot of the service.
Redis is a pure memory storage, it reads and writes nothing to disk. In other words it's a Volatile Datadstore. Meaning data will not survive a reboot of the service.
They serve two entirely different purposes. Redis is purely a cache server. So it stands to reason that of course it's going to be insanely fast at what it does.
But hey, want something even faster? Check out KeyDB. It's a fork of redis and I believe drop in compatible. But it uses Multithreading to do the work, where Redis stubbornly stays single thread.
Replies
Redis is persistent. Perhaps you were thinking of Memcached.
The default Snapshotting is hardly ideal for what one would call "persistent". One shouldn't be storing mission critical data in a cache server in hopes it'll survive. Data in stores like Redis and especially memcached should be considered and are volatile at all times. All Redis does differently from Memcached is ocassionally (and conditionally) dump whats in it into a single file for backup. Really, if you need your key to survive and don't care about performance as much, stick to your regular database solution, it will absolutely be safer there.
> Redis is a pure memory storage, it reads and writes nothing to disk. In other words it's a Volatile Datadstore. Meaning data will not survive a reboot of the service
This is straightforwardly wrong. See https://redis.io/topics/persistence.
> The default Snapshotting is hardly ideal for what one would call "persistent".
So... don't use the default snapshotting.
> So... don't use the default snapshotting.
and you propose as to................ what? AOF? The thing that on the same page you linked too describes it as buggy and unreliable? Because that's the only other option for Redis here. Persistance is simply not Redis' strength, plain and simple.
It's a cache server. Treat it like one and everyone will be happy. Stop trying to use it like Mongo.
I don't know why you're saying on the page it says buggy and unreliable >>> it does not say that. In fact, it is say the opposite saying it's "more durable" than snapshotting. I also, disagree with your persistence is simply not Redis's strength. What kind of app are you building? A financial records banking application? No? I didn't think so. Most data is ephemeral transient type data. I.e. A setting click on one part of the app to the next. State type storage. Once the user leaves or is no longer of use in the service bye bye. It's data that's no important but the need for speed is paramount for a good user experience. Then, in this use case, Redis is very persistent with the above listed options of RDB or AOF. If you're trying to run a financial records application with need for accurate data stores then yes Redis wouldn't be persistent enough for that in a qualifying sense.
You said yourself the redis is not properly configured. It takes a decent amount of work to properly configure redis to be durable. Otherwise it is not.
You know, I simply can't think of a scenario where I'd even want Redis to be "durable". It's a great server to spin up and immediately start storing serialized values into. Building into the application layer the reliance on refreshing that key when expired or missing.
For everything else I would care about if lost to a restart, I'd store in a normal database that properly respects ACID transactions.
Can someone spoon feed me some scenarios where having _redis_ persistence is actually a desireable thing? what's the point of sacrificing the speed (what it's good at) for AOF mode, especially if it's unreliable enough for Redis' docs to make note of anyways?
Yeah, it's rare if you use Redis generally as a caching pattern.
The one case would be if the Redis is flushed (corrupt restart, or FLUSHALL command) and it causes a stampeding herd on the backend that the cache is supposed to protect.
For example, a lot of web apps use something like Redis to store use session cookie values (e.g. https://docs.djangoproject.com/en/2.2/ref/settings/#std:setting-SESSION_ENGINE in Django) and losing the cache would sign everyone out which would suck. But even there, there are choices, such as the `cached_db` option in Django which *writes* to both, but then mostly *reads* from the cache.
I'm not saying whether or not you want to use Redis durably, just that if you're comparing Postgres vs Redis and not properly configuring Redis to be durable, it's not a very valid comparison. Likewise, I can't think of a situation where I'd prefer Postgres acting as an in-memory cache vs Redis.
Again, they do not make note of any concerning bug with actual usage of AOF but rather a specific command not seen anywhere in production or reported usage?
This simply isn't true. Redid can flush memory to disk and boot with that disk image. We use Redis and psql for persistent data stores without much issue. Writing to disk is an async process and typically doesn't disrupt performance unless it's a very large data set.
Kyle Harrison, the lax bro from John Hopkins?
lol, sadly no. Wouldn't that be hilarious though? We've exchanged tweets though! Super chill guy