Proposed by Eric Brewer. NoSQL databases can never have all of these 3 properties:
- Consistency (konzistentní)
- Availability (dostupnost)
- Partition tolerance (odolnost proti výpadkům) assuming system is distributed and uses sharding and replication. Read and write operations are on a single aggregate
Consistency
There is a single global order of operations; each operation takes effect at an instantaneous point between its call and completion – as if all ran sequentially on one node.
After each write, all nodes must return this updated value.Weaker consistency is possible.
Availability
Every read or write request successfully received by a non-failing node in the system must result in a response (success or failure), not be silently dropped. I.e., their execution must not be rejected
Each working node must always respond to user request
Partition tolerance
The network is allowed to lose arbitrarily many messages sent from one node to another
Suggest some network error. Nodes can get out of sync and they can lose messages. Connection error can happen, but the system must be ready.
Variations
In distributed system, system can choose between Availability and Consistency. Nodes require communication, so Partition tolerance usually
AP
System is always available and it is able to re-sync after partition. But before they re-sync, nodes can give non-consistent results.
- DynamoDB, Cassandra, CouchDB
CP
System chooses to be temporarily unavailable in order to be consistent.
- Redis, MongoDB, ApacheHBASE
CA
Consistent and available system is possible mainly in traditional databases. Nodes will never suffer from network issues, because nodes are usually not in different networks
- traditional databases (MySQL, PostgreSQL, MSQL, Redshift), neo4j, Vertica
ACID properties are achievable (avalability, consistency, Isolation, Durability)