4 ms·
Because memcache and redis are in-memory. Writing to fdb will be complete once it is fsync'ed to disk. Memcache is a cache. Fdb is a an ordered kv store.
by rapsey 3y ago
Because memcache and redis are in-memory. Writing to fdb will be complete once it is fsync'ed to disk.
Memcache is a cache. Fdb is a an ordered kv store.
- abhishekjha 3y agoYou can configure redis to flush to disk on write operations though you lose on performance.
- leetrout 3y agoThat is not comparable to writes completing after they are flushed to disk.
- NavinF 3y ago>appendfsync always: fsync every time new commands are appended to the AOF. Very very slow, very safe. Note that the commands are appended to the AOF after a batch of commands from multiple clients or a pipeline are executed, so it means a single write and a single fsync (before sending the replies). https://redis.io/docs/management/persistence/ https://redis.io/docs/management/persistence/ It's very slow, but if you really want to wait for fsync before replying, it can do that.
- leetrout 3y agoI was unaware they could make that guarantee. Thanks for the correction.
- unmole 3y agoRedis can be configured to persist and fsync every operation.
- rapsey 3y agoRedis is not meant as a primary database and should not be used as such. FoundationDB is meant as a reliable source of truth.
- Already__Taken 3y agoRedis began as a caching database, but it has since evolved into a primary database. Many applications built today use Redis as a primary database. https://redis.com/blog/redis-cache-vs-redis-primary-database-in-90-seconds/ https://redis.com/blog/redis-cache-vs-redis-primary-database... Very much seems like an acceptable use now
- vore 3y agoRedis can't have a working set larger than memory. It has no mechanism to page data to disk. If your data set grows too large, you're hosed unless you add more hardware.