3 ms·
> 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 co
by zzzcpan 8y ago
> 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.
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.
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.
- freels 8y agoI don't think it's correct to pit ACID against AP systems this way. Consistency is orthogonal. ACID is model for reasoning about transaction guarantees in terms of allowed anomalies at each isolation level. Serializability in ACID implies CP over AP, but weaker levels don't have the same requirement. It still comes down to tradeoffs for a specific use-case of a database system. Not sure what you're getting at when you say ACID transactions don't work in a multi-DC context. FaunaDB aside, there are many production systems (commercial or internal) that provide them that I am aware of.
- espadrine 8y ago> Not sure what you're getting at when you say ACID transactions don't work in a multi-DC context. I expect they are talking about DC as _regions_, not DC as _availability zones_ (in the AWS parlance). Planetary databases hit latency issues on cross-region ACID transactions. Whatever the sharding, a transaction modifying one piece whose leader is in Paris and another in Beijing will have at least the round-trip time between the two. It is already unforgiving at that scale, and will become inadmissible at interplanetary scale, requiring some form of eventual consistency. However, I still expect that we will retain ACID operations for local changes. Humans tolerate latencies that are necessary for planetary ACID transactions. The combination of the size of the Earth and the speed of light is a lucky draw.
- freels 8y agoYes, I meant regions as well. Speed-of-light bounded latency certainly means that serializable ACID transactions are not workable in some situations, but I disagree with OP that this proves them not viable period, at least at planet-scale as you say. We're indeed pretty lucky as far as transactions are concerned...