ACID Properties of the database

Original link: Https://en.wikipedia.org/wiki/ACID

52007011

In Computer science, ACID (atomicity atomicity, consistency consistency, isolation isolation, durability persistence) is a series of properties.

These attributes guarantee the reliability of database things. In the database, a series of operations on the data can logically be regarded as a whole operation, the whole operation is called things.

For example, multiple change operations are involved in the transfer of a bank from one account to another. For example, one thing is to reduce the amount of money in one account while adding funds to another account.

Jim Gray defined These operations for the trusted things system in the late the 1970s, and these technologies were developed later.

In 1983, Andreas Reuter and Theo H?rder invented the acronym ACID to describe these properties of the database thing.
Characteristics of database things:

Atomicity (atomicity)

Atomicity requires that all operations in each thing are either complete or as if none have occurred: if part of the operation fails, the whole thing fails, and the result is that the state in the database remains unchanged. Atomic systems must be guaranteed to be atomic in a variety of situations, including host power outages, host errors, and host crashes. In the external world, a submitted thing looks (through the impact of things on the database) is not divided, a failed thing, the outside world as if nothing has happened.

Consistency (consistency)

Consistency ensures that everything changes the database from a legitimate state to another legal state. All the data written to the database must be legitimate by defining the various rules, including constraints (constraints), cascading (Cascades), triggers (triggers), and their combinations. Consistency does not guarantee the correctness of things (Programs), in other words, the consistency of things is not necessarily what programmers expect (this should be the responsibility of the Application layer code), it can only guarantee that all the data in the database will not violate the defined rules, Regardless of whether the program has an error or even if any errors occur, it will not violate the well-defined rules.

Isolation (Isolation)

Isolation guarantees that the impact of multiple things concurrently on the state of the system and the serialization of the execution of multiple things have the same effect on the state of the system. Isolation is the primary goal of concurrency control. By means of concurrency control, the effects of an unfinished thing are not visible to other things.

Durability (persistent)

Persistence guarantees that once a thing is submitted, its state remains unchanged, even when the host loses power, crashes, and errors. For example, in a relational database, once a set of SQL statements is executed, the result is permanently saved (even when the object is just being submitted to the database system). In order for the host to withstand the risk of power outages, things (or the result of things) must be recorded in persistent storage.

Example

The following example further illustrates the ACID properties. In the following example, the database table has two columns, A and B. Data integrity constraints require that the value of column A and the value of column B must be equal to 100. The following SQL statement creates a table that satisfies the above constraint--a+b=100.

CREATE TABLE acidtest (A INTEGER, B INTEGER, CHECK (A + B = 100));

• 1
• 2

An inverse example of atomicity

In a database system, atomicity is one of the four properties of ACID things. In an atomic thing, a series of database operations either take place or none of them occur. This series of operations cannot be separated from each other, only partial operations are performed. Atomicity requires this sequence of operations to be non-divided, as is the name of atomicity. Atomicity guarantees that the database will not be partially updated. The problem with partial updates is far more serious than all the failures of all operations. Atomicity means not to be divided.

A counter-example of consistency

Consistency is a very generalized term that requires that the data must satisfy all legal rules. As an example of the preceding example, the rule of legality is to require a + b = 100, while A and b must also be integers. For A and B, their legal scope can be inferred. All legal rules must be checked to ensure the consistency of things. Suppose a thing tries to subtract 10 from a and not modify B. Because the consistency check is done after each thing, the database knows A + B = 100 before the thing starts. If a thing succeeds in subtracting 10 from a, the atomicity takes effect. However, the validation checker finds A + B = 90, which is inconsistent with the database constraint rules. The whole thing has to be canceled, and the affected rows are rolled back to the state they were before the thing was executed. If there are other constraints, triggers, and cascading, each independently changed operation must be checked as before before the thing is committed.

Breach of quarantine

To demonstrate isolation, let's say two things change the same piece of data at the same time. In order to maintain isolation, one thing must wait until another thing is complete before it can be executed. Consider the following two things, T1 from a 10 to B. T2 from B 10 to a. You can analyze a total of four actions:
1, T1 minus 10 from A.
2, T1 to B plus 10.
3, T2 minus 10 from B.
4, T2 add 10 to A.
If these operations are performed in the order above, isolation can be achieved, although T2 must wait for T1 to execute first. If the T1 fails halfway through, the database system will eliminate the impact T1 has on the database, T2 still see legitimate data.

Because two things can be interleaved, the actual order in which these operations are performed may be:

• T1 minus 10 from A.
• T2 minus 10 from B.
• T2 adds 10 to A.
• T1 added 10 to B.

Again, what will happen if T1 fails halfway. If T1 in the fourth step: T1 to B added 10 o'clock failed, and at this time T2 has modified A and B, the changed data can not be restored to the state before T1 execution, resulting in the database generated an illegal state. This is known as the "Write-write failure" failure due to two things trying to modify the same data block at the same time. In a typical system, this problem can be solved. By canceling the failed thing T1, the database reverts to the last legitimate state, and then resumes execution of the interrupted thing T2.

Violation of persistence

Suppose that a thing is subtracted from a by 10 plus to B. First, things subtract 10 from A and then add 10 to B. At this point, the program that executes the thing tells the user that the thing has been executed successfully. Then, these changed data is still queued in the disk buffer for writing to disk. If a power outage occurs at this point in the host, all changes in the database will be lost. The user also thought that all the changes had been persisted to disk.

Realize

Dealing with a thing usually requires a series of operations, any failure of one operation will lead to the failure of the whole thing, so there are many reasons why things fail. For example, the system's disk is full, there is no more space, or the thing has run out of CPU time slices assigned to it by the operating system. There are two popular technologies that everyone is familiar with: pre-write logging and shadow paging. In both of these technologies, the lock must be acquired on all information that will be updated. Gets the lock dependent on the isolation level of the thing, it is possible that all the data is simply read and requires a lock to be acquired. In pre-write logging technology, atomicity is guaranteed by copying the original (unchanged) data into the log before changing the database. With logging, you can restore the database to a consistent state before the crash. In the shadow paging technique, the update is applied to a partial copy of the database, and the new copy is activated when the database thing is committed.

Lock

Many databases rely on locks to achieve ACID capability. A lock means that something is marked on the data it needs to access, so that the database management system knows that the data will not allow other things to modify the tagged data until the thing is done (success or failure). Locks must be obtained before the data is processed, and also acquire locks before data that is only read but not modified. Non-trivial things usually require a large number of locks, resulting in significant performance overhead and blocking other things. For example, user A is executing a thing and needs to read a row of data while another user B is modifying the row of data. User B must wait for user A to complete the thing completely. It is usually possible to guarantee full isolation through two phase locks.

ACID Properties of the database