While FoundationDB allows you to obtain sub-milliseconds transactions’s latency without any knob-tuning, we had to bump a bit memory usage for Redwood under certain usage and workload. The following configuration has been tested on clusters from 7.1 to 7.3. BTree page cache We discovered the issue when we saw a performance decrease on our cluster storing time-series data. Our cluster was reporting some high disk-business, causing outages: 10.0.3.23:4501 ( 65% cpu; 61% machine; 0.

I have been working around FoundationDB for several years now, and the new upcoming version is fixing one of the most evil and painful caveats you can deal with when writing layers: commit_unknown_result. Transactions with unknown results When you start writing code with FDB, you may be under the assertions that given the database’s robustness, you will not experience some strange behavior under certain failure scenarios. Turns out, there is one scenario that is possible to reach, and quickly explained in the official documentation:

I really like using RSS feeds. My Feedly account has more than 190 feeds, all neatly organized by categories. They help me keep up with new ideas and interesting blog posts about engineering. But there’s another source of information I’ve been using for a long time that not many people know about: academic papers. You can discover details about infrastructure that you might not find in regular blog posts. Academic papers, unlike typical blog content, often dive deeper into specific aspects of infrastructure.

Learning distributed systems is tough. You need to go through a lot of academic papers, concepts, code review, before being able to have a global pictures. Thankfully, there is a lot of resources out there that can help you to get started. Here’s a list of resources I used to learn distributed systems. I will keep this blogpost up-to-date with books, conferences, and so on. A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.

As I’m working on my latest contribution around FoundationDB and Rust, I had the chance to dig a bit into how FoundationDB’s bindings are offering helpers to generate keys. Their approach is interesting enough to deserve a blogpost 😎 Row key? When you are using a key/value store, the design of the row key is extremely important, as this will define how well: your scans will be optimized, your puts will be spread, you will avoid hot-spotting a shard/region.

Notes About is a blogpost serie you will find a lot of links, videos, quotes, podcasts to click on about a specific topic. Today we will discover ETCD. Overview of ETCD As stated in the official documentation: etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines. It gracefully handles leader elections during network partitions and can tolerate machine failure, even in the leader node.