3 ms·

FoundationDB is an open-source transactional KV store where you can write to any replica, and continue writing even if a certain number of replicas are lost. T

FoundationDB is an open-source transactional KV store where you can write to any replica, and continue writing even if a certain number of replicas are lost. The transactions maintain strict serializable semantics, meaning that transactions happening at the same time against different nodes will be consistent. (You can't read bank account A's balance, add to it, and then write it back if someone else committed a change to the bank account balance, even if that happened on another node.) This is honestly a pretty rare property in distributed databases, and even in databases that claim to implement it, it is ridiculously easy to get wrong. (Reading the analyses here are fascinating: https://jepsen.io/ https://jepsen.io/) One of the many things that SQLite brings is the ability to treat arbitrary storage as a relational database that can be queried (and mutated) with SQL. Both of these things are generally rare in open source databases. There are very few multi-master distributed databases that have ACID transactions, and even fewer of them have SQL support. So marrying these two technologies is extremely compelling; you get the power of SQLite's relational data layer with the power of FoundationDB's distributed transactions. This is really high tech stuff for free! A different implementation of similar semantics is rqlite. rqlite uses the Raft consensus protocol to replicate the text of your database writes to each node, which commits it to a local on-disk sqlite database. I haven't actually looked at mvSQLite enough to know how different the approach is, but both should be on everyone's list to take a look at and poke at. (For most "work" you'll be doing, it's probably completely fine to not create a distributed system like these; run in one datacenter, run a monolithic RDBMS, and tell users you're down when a tornado flattens the server racks. Do keep some offsite backups either way, though. Your application code will always have bugs, and these databases will happily replicate an accidental delete to 5 data centers at the speed of light.)

skyde 4y ago
so FoundationDB is user as a file system for storing SQlite files? In this case, the write contention performance would not be much better than using SQLite over SMB.
- ok_dad 4y ago
  You should read up on FDB, I doubt you’ll have issues like that until extreme scale. I guarantee it isn’t just like sharing a file over SMB, lol.
  - skyde 4y ago
    I have zero issue with FDB but some worry about mvSQLite. After reading more about the design it seem to use FDB to store Pages and using FDB transaction to make those update have have Strict serializable isolation. This would work correctly but it seem that mvSQLite also try to do its own MVCC logic instead of simply using FDB transactions. It is well known that implementing Serializable transaction on top of MVCC is not trivial. There was a bug in Postgresql from version 9.1 to version 12.3 making it not truly Serializable. See: https://jepsen.io/analyses/postgresql-12.3 https://jepsen.io/analyses/postgresql-12.3
- losfair 4y ago
  Unlike a regular filesystem, mvsqlite offloads both storage and transaction processing to FoundationDB. Fine-grained optimistic locking is implemented, and massive write concurrency across a cluster is possible.

skyde 4y ago

so FoundationDB is user as a file system for storing SQlite files? In this case, the write contention performance would not be much better than using SQLite over SMB.

ok_dad 4y ago
You should read up on FDB, I doubt you’ll have issues like that until extreme scale. I guarantee it isn’t just like sharing a file over SMB, lol.
- skyde 4y ago
  I have zero issue with FDB but some worry about mvSQLite. After reading more about the design it seem to use FDB to store Pages and using FDB transaction to make those update have have Strict serializable isolation. This would work correctly but it seem that mvSQLite also try to do its own MVCC logic instead of simply using FDB transactions. It is well known that implementing Serializable transaction on top of MVCC is not trivial. There was a bug in Postgresql from version 9.1 to version 12.3 making it not truly Serializable. See: https://jepsen.io/analyses/postgresql-12.3 https://jepsen.io/analyses/postgresql-12.3
losfair 4y ago
Unlike a regular filesystem, mvsqlite offloads both storage and transaction processing to FoundationDB. Fine-grained optimistic locking is implemented, and massive write concurrency across a cluster is possible.