4 ms·
this is limited by your creativity and willingness to make tradeoffs. the only really general statement i can think of is that the "larger"/"longer" your trans
by sigstoat 5y ago
this is limited by your creativity and willingness to make tradeoffs.
the only really general statement i can think of is that the "larger"/"longer" your transactions are, the harder a time you'll have getting it to cooperate with FDB. "small"/"fast" transactions will be easier to fit into its model.
(to likely replies: this isn't an absolute, see all the quotes. yes things like redwood will alleviate some of this, but not all.)
- vvern 5y agoIIRC fdb is fully optimistic concurrency control. It doesn't do any locking. If you have workloads which are highly contended, you'll need to do something in the layer above to coordinate. Otherwise, performance will be unbearable. This may be out-dated, please let me know if the story has evolved here.
- sigstoat 5y agoif your transactions are conflicting heavily with each other, yeah, you'll have a bad time. and if everything synchronizes on some small set of keys, you'll have a really bad time. monitoring the transaction conflict rate on your cluster is important.