4 ms·

I’d love to see a good primer on data models and scenarios that are well suited to FDB.

• selljamhere 5y ago
  Their docs might be a good place to start. https://apple.github.io/foundationdb/developer-guide.html#data-model https://apple.github.io/foundationdb/developer-guide.html#da...
• 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 ago
    IIRC 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 ago
      if 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.