3 ms·

Thank you for submitting this and thank you to the authors. I am curious how this kind of thing can scale. What I'm inspired by this article is the idea of app

Thank you for submitting this and thank you to the authors. I am curious how this kind of thing can scale. What I'm inspired by this article is the idea of applying multiversion semantics to datastores that aren't multiversioned. Sounds like if you have a transactionally sound store of "versions" and a way to query every datastore with a version field, you could implement point in time consistency, because the current version would only change when all datastores are updated. You still have to wait for all datastores to be updated, so that part is similar to 2 phase commit. My understanding is that two phase commit does not scale and is slow because of all the round trips, but we still want linearizability and strong consistency in systems. I tried to implement an asynchronously replicating data protocol but it is eventually consistent, not linearizable (it fails the Jepsen linearizability test) https://github.com/samsquire/eventually-consistent-mesh https://github.com/samsquire/eventually-consistent-mesh I'm a beginner in this area but I have a toy multiversion concurrency control implementation that uses Java threads. (See MVCC.java and TransactionC.java) the key statements of code is in commit() and shouldRestart(). https://github.com/samsquire/multiversion-concurrency-control https://github.com/samsquire/multiversion-concurrency-contro... Dropbox does something 2 phase commit with their cross shard replication which is interesting https://dropbox.tech/infrastructure/cross-shard-transactions-at-10-million-requests-per-second https://dropbox.tech/infrastructure/cross-shard-transactions...

KraftyOne 3y ago
While we haven't tested this, I suspect the main scaling bottleneck in practice is the primary database, as every Epoxy transaction goes through it. If you wanted to run Epoxy at large scale, you'd need a primary that supports very high transaction throughput.
- yawaramin 3y ago
  Would 4M qps be enough? :-) SQLite can achieve this with some help: https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-qps-on-a-single-server/ https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-q... More seriously, I suspect that plain SQLite by itself, running in process in the main service, writing to a ':memory:' database for ultimate speed or perhaps to a local file with WAL mode for slightly more durability, could achieve pretty nice efficiency and work as the main transaction manager database.

KraftyOne 3y ago

While we haven't tested this, I suspect the main scaling bottleneck in practice is the primary database, as every Epoxy transaction goes through it. If you wanted to run Epoxy at large scale, you'd need a primary that supports very high transaction throughput.

yawaramin 3y ago
Would 4M qps be enough? :-) SQLite can achieve this with some help: https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-qps-on-a-single-server/ https://blog.expensify.com/2018/01/08/scaling-sqlite-to-4m-q... More seriously, I suspect that plain SQLite by itself, running in process in the main service, writing to a ':memory:' database for ultimate speed or perhaps to a local file with WAL mode for slightly more durability, could achieve pretty nice efficiency and work as the main transaction manager database.