4 ms·

FoundationDB should have been included in their perf comparison. It’s ACID compliant and a distributed Value/Key store. For SSD based storage, it’s getting 50k

FoundationDB should have been included in their perf comparison. It’s ACID compliant and a distributed Value/Key store. For SSD based storage, it’s getting 50k reads/sec PER core and scales linearly with # of cores you have in your cluster. (They achieved 8MM reads/sec with 384 cores) https://apple.github.io/foundationdb/performance.html https://apple.github.io/foundationdb/performance.html

wutwutwutwut 4y ago
> scales linearly with # of cores you have in your cluster. So if I have 1 machine and increase from 2 to 256 core the throughout will scale linearly without the SSD ever being a bottleneck?
- gigatexal 4y ago
  “Distributed” is the keyword here. You scale cores and storage with machines…
atombender 4y ago
FoundationDB does have impressive performance, but implementing compound operations like INCR, APPEND, etc. would require at least an additional network round trip between the client and the server. For example, INCR would require one read followed by one write of the new value, and of course this will result in very inefficient mutation range conflicts (which must be retried for another couple of round trips) if you have frequent updates of the same keys in multiple concurrent transactions.
- sorenbs 4y ago
  FDB supports atomic operations that you can use to implement at least some of this very easily in a way that avoids the extra round trip and conflicts: https://apple.github.io/foundationdb/developer-guide.html#atomic-operations https://apple.github.io/foundationdb/developer-guide.html#at...
- spullara 4y ago
  FDB also supports some atomic operations that may decrease the number of roundtrips and remove conflicts: https://apple.github.io/foundationdb/api-python.html#api-python-transaction-atomic-operations https://apple.github.io/foundationdb/api-python.html#api-pyt... That said, I still don't think that it is necessarily the perfect match for implementing some of the Redis data structures.
  - atombender 4y ago
    I had completely forgotten about those built-in ones. Right, so some operations can be made fully atomic server-side, but there are still a bunch of ops (append, pubsub, set commands such as SADD, etc.) that would need round trips.
    - spullara 4y ago
      SADD wouldn't need a round trip since it is idempotent. You would just do a blind set which doesn't even require a transaction in FDB. Likewise, most of the other ones can be reframed / designed to not require round trips. I would still not use it as the backend unless I already had FDB in my solution and this was just an additional database type that I needed without ultimate performance as the constraint.
      - atombender 4y ago
        SADD needs to return a value indicating whether the member was added or not, so I don't think you could avoid a round trip, since FDB doesn't have a "set if not exists".
        spullara 4y ago
        Ah, I see. Bummer. Even if it had a set if not exists you would still need a transaction for it.
richieartoul 4y ago
FDB scales really well with reads, but it will bottleneck on writes a lot faster than you think. For write heavy workloads, Redis and Dragonfly would both leave FDB in the dust (and I say this as a big FDB user/enthusiast).
- endisneigh 4y ago
  Isn’t this because FDB persists to disk? What’s the difference compared to Redis persisting to disk?
  - richieartoul 4y ago
    No there is much more to it than that. FoundationDB has a completely different architecture that is optimized for completely different things than Redis is. It’s not just about writing to disk vs. not. Redis is basically a very performant, single-threaded (mostly) single-node in-memory datastructures system with an efficient and readable server protocol strapped to it. FoundationDB is a completely different beast that has like 6+ distinct roles, and is optimized almost exclusively for interactive serializable transactions, range reads, and correctness. They’re just completely different things, I recommend reading the FoundationDB paper to get a sense for its architecture. The amount of “steps” involved in processing an FDB write is much higher than in Redis.

wutwutwutwut 4y ago

> scales linearly with # of cores you have in your cluster. So if I have 1 machine and increase from 2 to 256 core the throughout will scale linearly without the SSD ever being a bottleneck?

gigatexal 4y ago
“Distributed” is the keyword here. You scale cores and storage with machines…

atombender 4y ago

FoundationDB does have impressive performance, but implementing compound operations like INCR, APPEND, etc. would require at least an additional network round trip between the client and the server. For example, INCR would require one read followed by one write of the new value, and of course this will result in very inefficient mutation range conflicts (which must be retried for another couple of round trips) if you have frequent updates of the same keys in multiple concurrent transactions.

sorenbs 4y ago
FDB supports atomic operations that you can use to implement at least some of this very easily in a way that avoids the extra round trip and conflicts: https://apple.github.io/foundationdb/developer-guide.html#atomic-operations https://apple.github.io/foundationdb/developer-guide.html#at...
spullara 4y ago
FDB also supports some atomic operations that may decrease the number of roundtrips and remove conflicts: https://apple.github.io/foundationdb/api-python.html#api-python-transaction-atomic-operations https://apple.github.io/foundationdb/api-python.html#api-pyt... That said, I still don't think that it is necessarily the perfect match for implementing some of the Redis data structures.
- atombender 4y ago
  I had completely forgotten about those built-in ones. Right, so some operations can be made fully atomic server-side, but there are still a bunch of ops (append, pubsub, set commands such as SADD, etc.) that would need round trips.
  - spullara 4y ago
    SADD wouldn't need a round trip since it is idempotent. You would just do a blind set which doesn't even require a transaction in FDB. Likewise, most of the other ones can be reframed / designed to not require round trips. I would still not use it as the backend unless I already had FDB in my solution and this was just an additional database type that I needed without ultimate performance as the constraint.
    - atombender 4y ago
      SADD needs to return a value indicating whether the member was added or not, so I don't think you could avoid a round trip, since FDB doesn't have a "set if not exists".
      - spullara 4y ago
        Ah, I see. Bummer. Even if it had a set if not exists you would still need a transaction for it.

richieartoul 4y ago

FDB scales really well with reads, but it will bottleneck on writes a lot faster than you think. For write heavy workloads, Redis and Dragonfly would both leave FDB in the dust (and I say this as a big FDB user/enthusiast).

endisneigh 4y ago
Isn’t this because FDB persists to disk? What’s the difference compared to Redis persisting to disk?
- richieartoul 4y ago
  No there is much more to it than that. FoundationDB has a completely different architecture that is optimized for completely different things than Redis is. It’s not just about writing to disk vs. not. Redis is basically a very performant, single-threaded (mostly) single-node in-memory datastructures system with an efficient and readable server protocol strapped to it. FoundationDB is a completely different beast that has like 6+ distinct roles, and is optimized almost exclusively for interactive serializable transactions, range reads, and correctness. They’re just completely different things, I recommend reading the FoundationDB paper to get a sense for its architecture. The amount of “steps” involved in processing an FDB write is much higher than in Redis.