4 ms·

For single-machine key-value needs (and lists, sets, sorted sets, hash tables, and various full-text operations) it’s by far fastest in my experience. But it’s

For single-machine key-value needs (and lists, sets, sorted sets, hash tables, and various full-text operations) it’s by far fastest in my experience. But it’s not going to have the level of transactional guarantees in a clustered setup or full ACID (writes aren’t immediately durable) that some use-cases will require. Treat Redis more like a cache or job queue or pub-sub or event streaming platform or full-text search engine than a primary datastore of mission-critical data.

endisneigh 4y ago
Is Redis really more performant than FDB on a single instance when Redis persists to disk? It wouldn't surprise me that Redis is faster in-memory, tho.
- datalopers 4y ago
  No idea, I haven't benchmarked a 100% durable redis setup (aof, fsync every query) against FDB but that will definitely have a significant hit to write performance. I generally stick to the model of not using Redis for mission-critical durability use cases. I don't really view them as competing technologies in the first place though.
WJW 4y ago
One underappreciated part about Redis is that its singlethreaded in-memory approach makes every thing extremely atomic. There is literally no way for simultaneous operations to conflict if you only ever run one operation at a time. That said, you indeed need to be very careful around durability since the dataset is kept in memory. Most persistence options are a bit meh compared to "real" databases IMO. Redis is a very fast ACI-compliant datastore if you will.
- jjtheblunt 4y ago
  Can you create a conflict across a power failure reboot?
  - WJW 4y ago
    I don't think you can create a conflict as in "corrupt the database", but it is definitely possible to lose data depending on how you have set your FSYNC settings in the redis config. The docs mention that a truncated AOF file (such as might happen during a power failure) will not invalidate it but the last command will be lost. The default is to sync to disk every second, so you could lose up to a second of data that your backend did consider to be written. You can also set it to fsync after every write query, but this will be much slower. https://redis.io/docs/manual/persistence/ https://redis.io/docs/manual/persistence/ has all the details.

endisneigh 4y ago

Is Redis really more performant than FDB on a single instance when Redis persists to disk? It wouldn't surprise me that Redis is faster in-memory, tho.

datalopers 4y ago
No idea, I haven't benchmarked a 100% durable redis setup (aof, fsync every query) against FDB but that will definitely have a significant hit to write performance. I generally stick to the model of not using Redis for mission-critical durability use cases. I don't really view them as competing technologies in the first place though.

WJW 4y ago

One underappreciated part about Redis is that its singlethreaded in-memory approach makes every thing extremely atomic. There is literally no way for simultaneous operations to conflict if you only ever run one operation at a time. That said, you indeed need to be very careful around durability since the dataset is kept in memory. Most persistence options are a bit meh compared to "real" databases IMO. Redis is a very fast ACI-compliant datastore if you will.

jjtheblunt 4y ago
Can you create a conflict across a power failure reboot?
- WJW 4y ago
  I don't think you can create a conflict as in "corrupt the database", but it is definitely possible to lose data depending on how you have set your FSYNC settings in the redis config. The docs mention that a truncated AOF file (such as might happen during a power failure) will not invalidate it but the last command will be lost. The default is to sync to disk every second, so you could lose up to a second of data that your backend did consider to be written. You can also set it to fsync after every write query, but this will be much slower. https://redis.io/docs/manual/persistence/ https://redis.io/docs/manual/persistence/ has all the details.