3 ms·

Thanks you. Since it is a block device, all files are splitted into chunks of 4 kb (or other value if configured) and from the database perspective there is no

Thanks you. Since it is a block device, all files are splitted into chunks of 4 kb (or other value if configured) and from the database perspective there is no difference between large and small files. For deletions, FoundationDB is able to delete a key range in O(log(n)) time, without using tombstones, and it doesn't use compactions (because it uses B-tree instead of LSM-tree) so I don't think there will be any impact on performance. Right now TRIM operations are not supported yet, so instead of getting deleted blocks will be marked as "free" by a filesystem and then reused later.

alexk 8y ago
That's helpful, thanks, clarifies key differences in design of Cassandra vs FoundationDB. Are you using a lot of FDB in prod? What are your impressions so far? What are your next steps with this project?
- nmelkozerov 8y ago
  We don't use FDB in production yet, but Wavefront is using FDB and it seems they're quite happy: https://news.ycombinator.com/item?id=16879632 https://news.ycombinator.com/item?id=16879632 My next step is to implement a locking mechanism to prohibit simultaneous mounts and data corruption, and then I'll work on providing a Container Storage Interface to support easy integration with k8s. I don't think there will be major deviations from the roadmap defined in the readme :)