ACID
The claim to fame for relational databases is they make the ACID promise:
Atomicity - A transaction is all or nothing
Consistency - Only valid data is written to the database
Isolation - Pretend all transactions are happening serially and the data is correct
Durability - What you write is what you get. Data won't disappear.
The "problem" with ACID is that it may be giving you too much at the cost of performance. Fulfilling these promises has a big impact to scalability. It trips you up when you are trying to scale a system across multiple nodes.
Down time is generally unacceptable for cloud applications. So your system needs to be reliable. Reliability requires multiple nodes to handle machine failures. To make scalable systems that can handle lots and lots of reads and writes you need many more nodes.
Once you try to scale ACID across many machines you hit problems with network failures and delays. The algorithms don't work in a distributed environment at any acceptable speed.
BASE
The types of large systems based on CAP aren't ACID. They are BASE (har har):
Basically Available - System seems to work all the time
Soft State - It doesn't have to be consistent all the time
Eventually Consistent - Becomes consistent at some later time
CAP
If you can't have all of the ACID guarantees, it turns out you can have two of the following three characteristics:
Consistency - Your data is correct all the time. What you write is what you read.
Availability - You can read and write your data all the time
Partition Tolerance - If one or more nodes fails, the system still works and becomes consistent when the system comes on-line.
The claim to fame for relational databases is they make the ACID promise:
Atomicity - A transaction is all or nothing
Consistency - Only valid data is written to the database
Isolation - Pretend all transactions are happening serially and the data is correct
Durability - What you write is what you get. Data won't disappear.
The "problem" with ACID is that it may be giving you too much at the cost of performance. Fulfilling these promises has a big impact to scalability. It trips you up when you are trying to scale a system across multiple nodes.
Down time is generally unacceptable for cloud applications. So your system needs to be reliable. Reliability requires multiple nodes to handle machine failures. To make scalable systems that can handle lots and lots of reads and writes you need many more nodes.
Once you try to scale ACID across many machines you hit problems with network failures and delays. The algorithms don't work in a distributed environment at any acceptable speed.
BASE
The types of large systems based on CAP aren't ACID. They are BASE (har har):
Basically Available - System seems to work all the time
Soft State - It doesn't have to be consistent all the time
Eventually Consistent - Becomes consistent at some later time
CAP
If you can't have all of the ACID guarantees, it turns out you can have two of the following three characteristics:
Consistency - Your data is correct all the time. What you write is what you read.
Availability - You can read and write your data all the time
Partition Tolerance - If one or more nodes fails, the system still works and becomes consistent when the system comes on-line.
No comments:
Post a Comment