Isolation is a property of a database where simultaneous operations on the same data never see each other’s in-progress work.
If you watched my atomicity video, which you should before watching this one, you saw that operations can be grouped into atomic groups called transactions. For example, if we have a database with bank accounts, and Alice is transferring $10 to Bob, we first need to remove $10 from Alice’s account and add $10 to Bob’s account.
Let’s say that while this is happening, we also want to ask the system for the total amount of cash in the system, assuming that Alice and Bob are the only users. We should expect the answer to always be $200, since money shouldn’t be created or destroyed. If we are simultaneously performing a transfer AND querying the system for a sum, there are three scenarios for how the relative timing of these two operations might work out: querying before the transfer begins, querying after the transfer ends, and querying in the middle of the transfer. If we query the total amount of cash before the transfer begins, we get $200. If we query the total amount of cash after the transfer ends, we get $200 as well. However, if we query the total amount of cash in the middle of the transfer, there is a critical moment in between the first and second operations where the system is not in a valid state, because $10 is missing. Atomicity guarantees that if there’s an error, partially completed operations will be rewound, so it’s not possible for the $10 to be permanently gone. But, there is still this temporary invalid state where the $10 hasn’t yet been added to Bob’s account. In a database without isolation guarantees, it’s possible for the query to see the system in this temporary invalid state, and thus get a result of $190, which is wrong.
Let’s look at what happens in a database with isolation guarantees. When the transfer transaction removes money from Alice’s account, the change is only visible inside the same transaction, and hidden from other transactions. Thus, the database is able to conceal the fact that a transaction is in progress, and let the other operation query Alice and Bob’s accounts as if the transfer had not yet started. When the transfer transaction finishes, its effects become visible all at once. That means there’s never a moment where a simultaneous query could see invalid information, and therefore the transactions are isolated from each other!
Some databases allow you to customize the level of isolation. On one side, there is full isolation between transactions. On the other, there is no isolation. In between, there are degrees of isolation that isolate some, but not all kinds of operations. The reason for this is because there is a tradeoff between performance and isolation quality. The more work the database has to do to shield simultaneous operations from each other, the slower it is able to process queries. On the other hand, if the level of isolation is set to none, the database doesn’t need to do this hiding work, and can process queries much faster, at the risk of transactions seeing each other’s in-progress work and doing something wrong. Which level is right depends on you, the application developer, based on what you’re using the database for.
00:00 Intro
00:09 Review Of Transactions
00:28 Error Case Without Isolation
01:47 Happy Case With Isolation
02:21 Customizing The Amount Of Isolation
31 май 2024
