FoundationDB organizes data as an ordered key-value store. Is the row range for a table dynamically partitioned? As a table grows, is it automatically split into multiple tablets, Just like bigtable?
Key/Value pairs are split into what we call shards, and yes as the keyspace grows existing shards are split into smaller shards automatically. Splitting is done based on shard size as well as write bandwidth, so a shard that is not growing but is seeing a lot of writes (such as when constantly replacing existing records) may be split to better balance the load across more storage servers. Multiple shards are also merged when they become too small due to record deletion.
One further detail which may differ from other databases you are familiar with is that each FDB storage server holds an almost certainly unique set of shard replicas. Replication is handled at the shard level, not the storage server (host) level. In triple replication mode every shard has 3 shard replicas but it is very unlikely that any two storage servers would hold shard replicas for exactly the same set of shards.
I also want to point out that FoundationDB has no native “table” concept at all (though a layer could present one!). Records are key/value pairs and exist in the user accessible keyspace which is defined as ‘’ to ‘\xFF’ and sharded as described above.
Does it stop write operations when splitting?
No. Reads and writes work normally when data is moving around.
Yeah, no quiescing ftw :), when it really needs to shuffle transaction authorities though, it does reject writes but that’s mostly a recovery kind of scenario (and I was told it’s a lot better since 3.x)