In the early 1970s, he founded a sect called RDBMS. And every time that sect is mentioned, the junior generations will surely hear rumors about ACID. Before groping the beauty of ACID in that realm, we cannot forget the famous move called Transaction. So in summary, what is transaction and ACID? Why is it important to know these things? Because in combat sessions (interviews), these things will help me.
1. What is Transaction?
In a nutshell, a transaction is a collection of query statements. For example: A transfers 10,000 VND to B => system to deduct money A => system to add money to B. It is a transaction that we represent by the queries below when manipulating the database.
And the pain starts from here, when this ultimate move goes wrong with the ACID secret, it will make the user lose his way and encounter unpredictable consequences.
2. What is the secret of ACID?
Like its name, although it is short with 4 words but extremely mysterious, let's grope the beauty of each type.
A - Atomicity - Calculate units
The old grandparents have a saying "One horse hurts, the whole ship leaves the grass", this is the clearest proof of unitity. When a set of transaction queries starts to run, requiring all to be successful, a single failed command will stop the entire transaction from being executed. In the money transfer example above, too, the transaction is happening, it's unlucky, the system is out of power, and now what? Person B has not yet received the money and person A has already been deducted.
Running in the middle of not having time to commit, the db crashes once, the data is still intact and the balance is not changed at all.
C - Consistency - Consistency
In short, the data will always be consistent throughout the database query. For example, update to user_id's account = 1 plus amount is 20000:
When the client sends a request to the db to update the account balance of user_id = 1, the transaction is executing, at this moment, there is a request to get the user_id's account information, this time to ensure the data consistency. the resulting balance will remain unchanged.
However, life is not so beautiful, when a system thrives, the number of users increases, creating a problem of database scale. Both NoSQL and SQL face data consistence problems when solving scaling problems. Take for example a horizontal scale system with a master - slaves model (master: write data, slaves: read data). When the master has not finished syncing the data to the slaves, there is a request sent to read the old data.
Life is inherently a trade-off, the decision depends on the different needs and contexts of the system: Strong consistency vs Eventual consistency
- Strong: Data will always be consistent and up-to-date, in return there will be high latency.
- Eventual: The data may not be updated to the latest, but the query speed will be faster.
I - Isolation - Independence
"River water does not harm well water" is the meaning of isolation, simply understood when we have 2 transactions executing at the same time, the query to change the data of transaction A will not affect the data of transaction B. As the example below, I change the number of billings of the user in transaction 2, unfortunately the number of billings of the same user in transaction 1 is also changed => Toang => What to do now?
At this point, I will use Repeatable reads in the strategy Isolation levels) to solve the above case as follows.
As you can see, the data in transaction 1 now will not be affected by the changes from transaction 2 anymore, that is a success. In addition, there are many other moves about Isolation levels that in the following articles I will try to go deeper.
D - Durability - Sustainability
Just like the financial market like stock or crypto, even if tomorrow the floor collapses, the hand must be steady so as not to lose money. The database is the same, even if there is a sudden crash that crashes the system, the data cannot be lost, and the game cannot be reset. I take the following example, when I am working on a transaction that adds a new account to the db, at the same time of committing, I turn off the server, the question is, is my data still intact? Or when I turn off the server, I lose the committed data?
Hooray!!! The new user account after I restart the database is still there => No data loss.
3. Conclusion
The rain stopped, I also stopped writing. So, I have gone through the ACID secret book briefly, but to master it, I need to practice more. My little knowledge would like to share with you, thank you very much for reading. The article certainly has a lot of shortcomings, I hope everyone can contribute and share so that I can learn and improve.