I have a auto-reconfiguring distributed transaction layer atop sqlite that uses a paxos-style distributed consensus algorithm to elect a master. It works great and powers all of Expensify. Contrary to popular belief, sqlite is *freaking amazing* for this, and is blazing fast -- including for multi-threaded concurrent reads.
However, a limitation of our replication layer is that it serialises all commits, to ensure that all nodes commit all transactions in the same order -- a brute force way to ensure they all stay in sync. But this means we only have a single CPU committing transactions on each server (though all are available for reads). This works a lot better than you'd expect, and has scaled to millions of users without trouble. But it won't scale forever, so we're working on adding concurrent writes as well as reads Luckily sqlite actually has the ability to do page-level locking, and thus support concurrent writes just fine. But the replication layer itself is still serialized, sending transactions to slaves in the exact order they should be committed. My plan to overcome this is to detect groups of non-conflicting write queries, and flag them in such a fashion that slaves can commit them in parallel in any order. But -- and here's my question -- I'd love to learn more about how other systems have solved this same problem, especially other acid relational databases. Thanks! David
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
