ACID: All content tagged as ACID in NoSQL databases and polyglot persistence
The problem with relational databases is that they conflate the notions of data and views
Alex: @nathanmarz That’s reason for confusion between C in ACID and C in CAP: C in ACID means consistent view of data which can be done w/ quorums
Sergio: @strlen That’s a common misconception: ACID C just means your write operations do not break data constraints. It’s not about the view.
Alex: @sbtourist It also refers to not allowing reads of intermediate states i.e., serializability. W/o a quorum, an EC system could allow such.
Alex: @sbtourist On the other hand, an async system where node B is behind node A is still C in the ACID sense without being C in the CAP sense.
Sergio: @strlen Nope, that’s the isolation level (ACID I). Again, ACID C has a precise meaning and it’s about constraints.
Alex: @sbtourist Yeah, I think you are right: serializability would be “I”, with consensus (strongest form of CAP “C”) being about “A” (atomicity)
Sergio: @strlen That said, I strongly agree with you about ACID C being different than CAP C.
Alex: @sbtourist Yes. Both “consistent” and “atomic” mean diff things in DBs than they do elsewhere in systems (e.g., way that “ln -s” is atomic)
There have been many discussions about the loose definitions of the terms in the CAP theorem. Daniel Abadi exposed an interesting perspective on the subject proposing instead PACELC:
To me, CAP should really be PACELC – if there is a partition (P) how does the system tradeoff between availability and consistency (A and C); else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)?
I’ve already told you about ☞ Chris Gioran’s series on Neo4j internals. Now, he is working on providing support for pluggable JTA compliant transaction managers in Neo4j and details about the current status can be found in his ☞ last post. Anyways, before that he started with a deep dive into the Neo4j transactions and that resulted in 4 (quite long) articles:
- ☞ Write Ahead Log and Deadlock Detection
In this post I will write a bit about two different components that can be explained somewhat in isolation and upon which higher level components are build. The first is the Write Ahead Log (WAL) and the other is an implementation of a Wait-For graph that is used to detect deadlocks in Neo before they happen.
- ☞ XaResources, Transactions and TransactionManagers
This time we will look into a higher level than last time, discussing the Transaction class and its implementations, Commands and TransactionManagers, touching a bit first on the subject of XAResources.
- ☞ Xa roundup and consistency
This post covers Data sources and XA connections, management of XaResources, and putting all these together.
- ☞ A complete run and a conclusion
Here I will try to follow a path from the initialization of the db engine and through the begin() of a transaction and creation of a Node to the commit and shutdown.
As I’ve estimated in my first mention of this series on Neo4j internals, Chris ends up giving up writing and starting to hack Neo4j:
Truth been told, I have reached a point where I no longer want to write about Neo but instead I want to start hacking it
The network falacies:
- The network is reliable
- Latency is zero
- Bandwith is infinite
- The network is secure
- Topology doesn’t change
- There is one administrator
- Transport cost is zero
- The network is homogenous
- CA without P: Databases providing distributed transactions can only do it while their network is up
- CP without A: While there is a partition, transactions to an ACID db may be blocked until the partition heals
- AP without C: Caching provides client-server partition resilience by replicating data, even if the partition prevents verifying if a replica is fresh
Another interesting post on this topic, is ☞ The CAP Theorem Distilled by Sid Anand (@r39132). Under the assumption that “any system needs to support ‘P’” (nb I am not sure why the article is limiting the analysis to this case only), the article compares ‘A’ vs ‘C’ in CAP:
If you choose ‘C’, your system might implement 2-phase commit (a.k.a 2PC) . […]
On the other hand, if you opt for an AP system, you are opening the door to potential data inconsistencies. […] AP systems can get quite complicated (relative to CP systems)