3 ms·

Great article. Demystified a lot about FDB for me. > ”Summary: FDB is probably the best k/v store for regional deployment out there.” Why should someone use

Great article. Demystified a lot about FDB for me. > ”Summary: FDB is probably the best k/v store for regional deployment out there.” Why should someone use Memcache or Redis then? Is it for the data types in Redis?

c0balt 3y ago
Redis has a few features outside of k/v, like a good pub-sub implementation, that make it very useful in addition to a good DX and mature libraries. Memcache on the other habd is just solid and mature. It also has some inertia as being a solid k/v cache. For example: NextCloud supports afaik both Redis and Memcache as caching engines but doesn't have FDB support.
deleted 3y ago
[deleted]
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 ago
  You can configure redis to flush to disk on write operations though you lose on performance.
  - leetrout 3y ago
    That 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 ago
        I was unaware they could make that guarantee. Thanks for the correction.
- unmole 3y ago
  Redis can be configured to persist and fsync every operation.
  - rapsey 3y ago
    Redis 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 ago
      Redis 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 ago
        Redis 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.
dboreham 3y ago
Things like Redis and Memcache are not serious data stores. Don't put any data in them that you really need back out later.
rullopat 3y ago
FDB is more a framework to create your own distributed database creating what they call a "layer". https://apple.github.io/foundationdb/layer-concept.html https://apple.github.io/foundationdb/layer-concept.html
leentee 3y ago
I believe the author means "the best transactional k/v store"

c0balt 3y ago

Redis has a few features outside of k/v, like a good pub-sub implementation, that make it very useful in addition to a good DX and mature libraries. Memcache on the other habd is just solid and mature. It also has some inertia as being a solid k/v cache. For example: NextCloud supports afaik both Redis and Memcache as caching engines but doesn't have FDB support.

deleted 3y ago

[deleted]

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 ago
You can configure redis to flush to disk on write operations though you lose on performance.
- leetrout 3y ago
  That 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 ago
      I was unaware they could make that guarantee. Thanks for the correction.
unmole 3y ago
Redis can be configured to persist and fsync every operation.
- rapsey 3y ago
  Redis 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 ago
    Redis 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 ago
      Redis 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.

dboreham 3y ago

Things like Redis and Memcache are not serious data stores. Don't put any data in them that you really need back out later.

rullopat 3y ago

FDB is more a framework to create your own distributed database creating what they call a "layer". https://apple.github.io/foundationdb/layer-concept.html https://apple.github.io/foundationdb/layer-concept.html

leentee 3y ago

I believe the author means "the best transactional k/v store"