4 ms·

Redis is a data structure server, BoltDB is a storage engine. They're not really comparable. If you know you need a storage engine, then using BoltDB might make

Redis is a data structure server, BoltDB is a storage engine. They're not really comparable. If you know you need a storage engine, then using BoltDB might make sense. But if you're not sure why you use BoltDB over Redis (aside from performance and having heard of it), then maybe you didn't explore the question enough. You can't just replace BoltDB with Redis and call it a day, at least not if you want to have some sort of availability and more than 1 server in your service. Also, using Redis as a key-value store for its persistence isn't really a great idea.

diogofranco 11y ago
"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.
duaneb 11y ago
If all you need is GET and SET, you're probably good with either. Not all defining tradeoffs are relevant.
- AYBABTME 11y ago
  If you don't need your storage layer to be external to your service (Redis) and can do with only local storage (BoltDB), then you should totally do without the external storage. It's one less piece of code to maintain, monitor, alert and deal with when it breaks.

diogofranco 11y ago

"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.

duaneb 11y ago

If all you need is GET and SET, you're probably good with either. Not all defining tradeoffs are relevant.

AYBABTME 11y ago
If you don't need your storage layer to be external to your service (Redis) and can do with only local storage (BoltDB), then you should totally do without the external storage. It's one less piece of code to maintain, monitor, alert and deal with when it breaks.