Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
I don't recall any of those details but the test involved injecting a bogus block device that always returns garbage, and noting that this results in garbage records returned from client queries. And I don't think those kinds of issues have been eradicated, browsing through their github issues there are people trying to recover corrupted clusters. https://github.com/apple/foundationdb/issues/2480
I’ve been using FDB for toy projects for a while. It’s truly rock solid. That being said, I wish there were more layers.
Ideally someone could implement the firestore or dynamodb api on top.
https://github.com/losfair/mvsqlite
> That being said, I wish there were more layers as the functionality out of the box is very very limited.
The record layer https://github.com/FoundationDB/fdb-record-layer which allows to store protobuf, and define the primary keys directly in those is truly amazing:
https://github.com/FoundationDB/fdb-record-layer/blob/main/d...
I've been tooling around with "Tuple Database", which claims to be FoundationDB for the frontend (by the original dev of Notion).
https://github.com/ccorcos/tuple-database/
I have found it conceptually similar to Relic or Datascript, but with strong preformance guarantees - something Relic considers a potential issue. It also solves the problem of using reactive queries to trigger things like popups and fullscreen requests, which must be run in the same event loop as user input.
https://github.com/wotbrew/relic
I've been tooling around with "Tuple Database", which claims to be FoundationDB for the frontend (by the original dev of Notion).
https://github.com/ccorcos/tuple-database/
I have found it conceptually similar to Relic or Datascript, but with strong preformance guarantees - something Relic considers a potential issue. It also solves the problem of using reactive queries to trigger things like popups and fullscreen requests, which must be run in the same event loop as user input.
https://github.com/wotbrew/relic
You can do online schema changes with FDB, it all depends on what you do with the FDB primitives.
A great example of how to best utilize FDB is Permazen [1], described well in its white paper [2].
Permazen is a Java library, so it can be utilized from any JVM language e.g. via Truffle you get Python, JavaScript, Ruby, WASM + any bytecode language. It supports any sorted K/V backend so you can build and test locally with a simple disk or in memory impl, or RocksDB, or even a regular SQL database. Then you can point it at FoundationDB later when you're ready for scaling.
Permazen is not a SQL implementation. Instead it's "language integrated" meaning you write queries using the Java collections library and some helpers, in particular, NavigableSet and NavigableMap. In effect you write and hard code your query plans. However, for this you get many of the same features an RDBMS would have and then some more, for example you get indexes, indexes with compound keys, strongly typed and enforced schemas with ONLINE updates, strong type safety during schema changes (which are allowed to be arbitrary), sophisticated transaction support, tight control over caching and transactional "copy out", constraints and the equivalent of foreign key constraints with better validation semantics than what JPA or SQL gives you, you can define any custom data derivation function for new kinds of "index", a CLI for ad-hoc querying, and a GUI for exploration of the data.
Oh yes, it also has a Raft implementation, so if you want multi-cluster FDB with Raft-driven failover you could do that too (iirc, FDB doesn't have this out of the box).
FDB has something a bit like this in its Record layer, but it's nowhere near as powerful or well thought out. Permazen is obscure and not widely used, but it's been deployed to production as part of a large US 911 dispatching system and is maintained.
Incremental schema evolution is possible because Permazen stores schema data in the K/V store, along with a version for each persisted object (row), and upgrades objects on the fly when they're first accessed.
[1] https://permazen.io/
[2] https://cdn.jsdelivr.net/gh/permazen/permazen@master/permaze...
When I was writing a Haskell client library for Hyperdex, another distributed kv store, I found it incredibly helpful to implement a simulator for correctness. This helped me identify which behavior was unspecified (arithmetic overflow: should error) or where my simulator deviated.
https://github.com/AaronFriel/hyhac/blob/master/test/Test/Hy...
Alas, I think Hyperdex development paused a few years later. It's a shame that it stopped then.
100%. I don't have the time to read the paper but online schema changes, with the ability to fail and abort the entire operation if one row is invalid, are basically the same problem as background index building.
If instead of using some generic K/V backend, it made use of specific FDB features, it might be even better. Conflict ranges and snapshot reads have been useful for me for some background index building designs, and atomic ops have their uses.
It is not necessary to store a version on each row. I can't remember why I did things this way, but https://github.com/srh/refound has no versions on persisted objects, has online background index building, and could do schema updates the same way. (That system doesn't have schemas.) When there is an active index build, incoming writes already read about active index build ranges and can participate in index building if it's interfering with their keys, to avoid starving it out if they're hammering the table with writes. So they know based on the ranges which keys have index entries. Adding versions would be sensible for performance reasons, and it would also minimize the occasions that writes have to read sindex build metadata while supporting this starvation mitigation.
> Oh yes, it also has a Raft implementation, so if you want multi-cluster FDB with Raft-driven failover you could do that too (iirc, FDB doesn't have this out of the box).
I don't know what you mean by this. Multiple FDB clusters?
This is what we did for our KV store at S3: https://www.amazon.science/publications/using-lightweight-fo...
Using https://github.com/awslabs/shuttle which works on our real Rust code.