> This is not at all a theoretical problem. Deliberately inducing withdrawal races at ATMs is a widely reported type of fraud. Thus, databases need “external consistency”, colloquially known as ACID.<p>In all those fraud cases banks were actually running ACID databases as they always do. Because ACID has nothing to do with "external consistency", unless you can run it in a human brain, which you can't. Interactions with humans can only be eventually consistent. But nobody even bothers to have ACID all the way to the web browser or APIs, so it's only limited to the application, but not beyond that. With all the frauds and double spending problems remaining unsolved.<p>Overall the usual FaunaDB attacks on other systems, especially AP. Strong eventual consistency of AP systems is actually much stronger, than ACID and is much much easier to verify and AP is where the cutting edge of distributed systems research happens. But more importantly, SEC can offer the best theoretically possible performance and latency for multi datancenter deployments. While distributed ACID transactions don't even show viability in multi datacenter deployments at the moment, forcing vendors to degrade into weak consistency models in such setups.
For further reading, Dan Abadi's post at <a href="http://dbmsmusings.blogspot.com/2018/09/newsql-database-systems-are-failing-to.html" rel="nofollow">http://dbmsmusings.blogspot.com/2018/09/newsql-database-syst...</a> addresses the Spanner issues more directly.<p>I don't think there's a great reference for the Percolator transaction architecture specifically, but there is a brief description here: <a href="https://blog.octo.com/en/my-reading-of-percolator-architecture-a-google-search-engine-component/" rel="nofollow">https://blog.octo.com/en/my-reading-of-percolator-architectu...</a><p>One thing I learned recently is that FoundationDB is essentially the Percolator model (timestamp oracle), even though FoundationDB predated the Percolator paper.
I was using IBM DB/2 Parallel Edition in 1995 at Trans Union for a year 2000 project to move off the mainframe. It was running on 60 RS/6000 SP2s. I was hoping the blog post would go further back in time.<p><a href="https://pdfs.semanticscholar.org/9c08/4a56c1c625da116eca474208d9780539ceff.pdf" rel="nofollow">https://pdfs.semanticscholar.org/9c08/4a56c1c625da116eca4742...</a>
It's kinda sad that Tandem and similar work has been forgotten. I've wondered what we could learn from such history and never gotten a clear answer.
TiDB developer here,<p>'This model is equivalent to the multiprocessor RDBMS—which also uses a single physical clock, because it’s a single machine—but the system bus is replaced by the network. In practice, these systems give up multi-region scale out and are confined to a single datacenter.'<p>I don't think so, although Percolaotor has a single point of physical clock, but it is easy to eliminate the SPOF problem by using high-availability algorithms such as Raft or Paxos (Just like the design in TiDB).
On the other hand, the strong consistency across multiple data centers, I think, without hardware devices such as TrueTime, it is difficult to have low latency and strong consistency while allowing writes happen in multiple data centers at the same time. The more realistic situation is that there is a primary data center (where both read and write occur), and multiple data centers guarantee high availability with strong consistency, we can achieve this goal by scheduling Paxos or Raft leader to the primary data center.
Why the hell does everyone make a banking example when they want to talk about transactions? BANKS RUN ON EVENTUAL CONSISTENCY, PERIOD.<p>Another point worth mentioning is that, single transaction coordinator model is undervalued in community. Majority of systems have the following query pattern (sorted descending):<p>1. Single key read --> you don't need to contact coordinator<p>2. Single key write --> you don't need to contact coordinator. OCC with simple version number works here.<p>3. Multi-key asynchronous write (updating second, third keys using a pub/sub infrastructure) --> you don't need to contact coordinator in this case.<p>4. True multi-key transactions that should happen atomically --> need to contact coordinator<p>If a single coordinator can process 20-30K/s transactions of category 4, then total throughput of the system would be around 300K queries per second which is sufficient for many workloads.
Cap theorem states that it is impossible for a distributed data store to simultaneously provide more than two out off Consistency, Availability and Partition tolerance<p><a href="https://en.wikipedia.org/wiki/CAP_theorem" rel="nofollow">https://en.wikipedia.org/wiki/CAP_theorem</a>