@ProgressiveCod2: The acronym ACID in the contex...
@ProgressiveCod2
39 views
Dec 27, 2023
1
The acronym ACID in the context of DB transactions stands for Atomicity, Consistency, Isolation, and Durability.
This post is going to make each term crystal clear.
✅Atomicity (A)
Atomic means something that cannot be broken down.
It’s the same thing that our Physics teachers tried to tell us many years ago. If only we would have listened…
Atomicity describes what happens to a Transaction that’s executing multiple write operations and something goes wrong halfway.
Think of a Transaction as a bridge between two states of data named A and B.
No intermediate states are allowed.
It’s all or nothing.
So, if you can’t complete the entire transaction successfully, you don’t complete any part of it.
The transaction is completely aborted.
Without atomicity, a mid-way error during multiple updates, the entire database state can turn into a mess.
Retrying the transaction would be risky because it can result in duplicate data.
Atomicity saves you from all this trouble.
✅Consistency (C)
Consistency in ACID is all about the context of your application.
In any application or system, there are statements that must be true.
For example, credits and debits in a bank must always be balanced.
A consistent transaction is one where statements are true at the beginning as well as the end of the transaction.
But most of it depends on your application.
A database cannot save you if you write bad data that violates the invariants.
Sure, you can have some checks like foreign keys or constraints but a lot of it depends on the application’s requirements.
So - when you think about it, Consistency is the property of your application.
✅Isolation (I)
Isolation is the trickiest guarantee.
It’s a given that your database will be accessed by multiple clients at the same time.
Databases can handle this quite well if they are reading and writing different parts of the database.
But the plot thickens when different clients try to access the same database records.
This ends up creating concurrency issues.
An example of this issue is two clients simultaneously trying to increment a counter that is stored in a database.
Despite two increment requests, the counter was only incremented by 1 because of race conditions.
The goal of Isolation is that concurrently executing transactions are isolated from each other.
But it’s more of a degree than an absolute value.
There are multiple isolation levels ranging from weak to strong. Some common ones are:
- Read Uncommitted
- Read Committed
- Repeatable Read
- Serializable
✅ Durability (D)
Lastly, the purpose of a database system is to let you store data without any fear of losing it.
Durability is the guarantee that promises this safety.
The guarantee holds even in case of a hardware fault or database crash.
There are two ways databases achieve this:
- Disk storage and write-ahead logs for single-node databases
- Replication for multiple nodes.
Of course there is no perfect durability.
It’s all about risk-reduction techniques.
So - what do you think about ACID guarantees?
Do you prefer them or find them too strict?
This post is going to make each term crystal clear.
✅Atomicity (A)
Atomic means something that cannot be broken down.
It’s the same thing that our Physics teachers tried to tell us many years ago. If only we would have listened…
Atomicity describes what happens to a Transaction that’s executing multiple write operations and something goes wrong halfway.
Think of a Transaction as a bridge between two states of data named A and B.
No intermediate states are allowed.
It’s all or nothing.
So, if you can’t complete the entire transaction successfully, you don’t complete any part of it.
The transaction is completely aborted.
Without atomicity, a mid-way error during multiple updates, the entire database state can turn into a mess.
Retrying the transaction would be risky because it can result in duplicate data.
Atomicity saves you from all this trouble.
✅Consistency (C)
Consistency in ACID is all about the context of your application.
In any application or system, there are statements that must be true.
For example, credits and debits in a bank must always be balanced.
A consistent transaction is one where statements are true at the beginning as well as the end of the transaction.
But most of it depends on your application.
A database cannot save you if you write bad data that violates the invariants.
Sure, you can have some checks like foreign keys or constraints but a lot of it depends on the application’s requirements.
So - when you think about it, Consistency is the property of your application.
✅Isolation (I)
Isolation is the trickiest guarantee.
It’s a given that your database will be accessed by multiple clients at the same time.
Databases can handle this quite well if they are reading and writing different parts of the database.
But the plot thickens when different clients try to access the same database records.
This ends up creating concurrency issues.
An example of this issue is two clients simultaneously trying to increment a counter that is stored in a database.
Despite two increment requests, the counter was only incremented by 1 because of race conditions.
The goal of Isolation is that concurrently executing transactions are isolated from each other.
But it’s more of a degree than an absolute value.
There are multiple isolation levels ranging from weak to strong. Some common ones are:
- Read Uncommitted
- Read Committed
- Repeatable Read
- Serializable
✅ Durability (D)
Lastly, the purpose of a database system is to let you store data without any fear of losing it.
Durability is the guarantee that promises this safety.
The guarantee holds even in case of a hardware fault or database crash.
There are two ways databases achieve this:
- Disk storage and write-ahead logs for single-node databases
- Replication for multiple nodes.
Of course there is no perfect durability.
It’s all about risk-reduction techniques.
So - what do you think about ACID guarantees?
Do you prefer them or find them too strict?