5 ms·

"Also, using Redis as a key-value store for its persistence isn't really a great idea." Could you please elaborate on this point? I'm thinking of using Redis p

"Also, using Redis as a key-value store for its persistence isn't really a great idea." Could you please elaborate on this point? I'm thinking of using Redis precisely in that manner and would love know about the drawbacks.

mvitorino 11y ago
Redis is missing the D in ACID, meaning a successfully executed command is not guaranteed to persist to disk since Redis only flushes it's data to disk (if you do have persistence enabled) at configurable intervals. So when you server dies you lose the changes since the last flush. I would not use as a primary storage for data you cannot afford to lose. Have a look at this: http://redis.io/topics/persistence http://redis.io/topics/persistence Edit: you can configure redis to flush on every command that changes data...but you probably wouldn't want to use redis that way :)
- DrJokepu 11y ago
  I'd also add that (unless you have a very good reason not to) it's probably a good idea to always add a TTL (expiration date) to any key you store in Redis to enforce the "not primary storage for data you cannot afford to lose" way of thinking.
- dgreensp 11y ago
  This is acceptable for a wide range of apps. EtherPad, for example (which used MySQL) only flushed every second or two. If the database crashed, then yes, you'd lose the last couple keystrokes, but that was so extremely rare it didn't even register as a factor in the overall UX. Edit: Also, you probably have bigger problems if your database goes down or your cluster falls off the map somehow.
  - mvitorino 11y ago
    Absolutely, but people should still be aware of the compromises and not confuse categories. Very few apps can make do with only a key-value store and if you have to throw a relational db in the mix, why introduce more moving parts unless absolutely necessary? ACID, referential integrity, SQL. Sometimes it feels people are willing to ditch all this for very little gain. Let's face it, how many apps out there can't really run a beefy relational DB with potentially an absurd amount of RAM?
AYBABTME 11y ago
A good rule of thumb is to only use Redis as an ephemeral storage for data that you can reconstruct if you lose it, or that you can otherwise afford to lose.

mvitorino 11y ago

Redis is missing the D in ACID, meaning a successfully executed command is not guaranteed to persist to disk since Redis only flushes it's data to disk (if you do have persistence enabled) at configurable intervals. So when you server dies you lose the changes since the last flush. I would not use as a primary storage for data you cannot afford to lose. Have a look at this: http://redis.io/topics/persistence http://redis.io/topics/persistence Edit: you can configure redis to flush on every command that changes data...but you probably wouldn't want to use redis that way :)

DrJokepu 11y ago
I'd also add that (unless you have a very good reason not to) it's probably a good idea to always add a TTL (expiration date) to any key you store in Redis to enforce the "not primary storage for data you cannot afford to lose" way of thinking.
dgreensp 11y ago
This is acceptable for a wide range of apps. EtherPad, for example (which used MySQL) only flushed every second or two. If the database crashed, then yes, you'd lose the last couple keystrokes, but that was so extremely rare it didn't even register as a factor in the overall UX. Edit: Also, you probably have bigger problems if your database goes down or your cluster falls off the map somehow.
- mvitorino 11y ago
  Absolutely, but people should still be aware of the compromises and not confuse categories. Very few apps can make do with only a key-value store and if you have to throw a relational db in the mix, why introduce more moving parts unless absolutely necessary? ACID, referential integrity, SQL. Sometimes it feels people are willing to ditch all this for very little gain. Let's face it, how many apps out there can't really run a beefy relational DB with potentially an absurd amount of RAM?

AYBABTME 11y ago

A good rule of thumb is to only use Redis as an ephemeral storage for data that you can reconstruct if you lose it, or that you can otherwise afford to lose.