Lecture
In computer science, the acronym ACID describes the requirements for a transactional system (for example, a DBMS) that ensure its most reliable and predictable operation. The ACID requirements were largely formulated in the late 1970s by Jim Gray.
Transactions appeared in the 1970s and were introduced as a database tool for solving problems of fault tolerance and data access in a concurrent environment. A set of properties was then formulated that a transaction must have in order to accomplish the tasks assigned to it, and the initial letters of these properties, arranged in the right order, formed the neat acronym ACID.
The period during which these events took place was characterized by the absence of high loads, the Internet, and performance problems that could be solved simply by vertical scaling methods. Later, in the early 2000s, a trend toward NoSQL databases emerged, and the acronym BASE appeared, which was essentially positioned as the opposite of classic ACID (ACID — an acid, BASE — a base). Now the opposite trend toward ACID is emerging. Even the NoSQL database MongoDB has started supporting ACID.
Let's figure out what this acronym means and how much of it is marketing.
ACID represents 4 properties:
A = atomicity
C = consistency
I = isolation
D = durability
Atomicity guarantees that no transaction will ever be committed to the system partially. Either all of its suboperations will be executed, or none of them will. Since in practice it is impossible to execute the entire sequence of operations within a transaction simultaneously and atomically, the concept of a «rollback» is introduced: if a transaction cannot be fully completed, the results of all the actions it has performed so far are undone, and the system returns to its «externally original» state — from the outside, it will look as though the transaction never happened. (Naturally, counters, indexes, and other internal structures may change, but if the DBMS is programmed without errors, this will not affect its external behavior.)
A transaction that reaches its normal completion (EOT — end of transaction) and thereby commits its results preserves the consistency of the database. In other words, every successful transaction, by definition, commits only valid results. This condition is necessary to support the fourth property.
Consistency is a broader concept. For example, in a banking system there may be a requirement that the amount debited from one account equal the amount credited to another. This is a business rule, and it cannot be guaranteed by integrity checks alone — it must be upheld by the programmers writing the transaction code. If some transaction performs the debit but not the credit, the system will be left in an incorrect state and the consistency property will be violated.
Finally, one more remark concerns the fact that consistency is not required during the execution of a transaction. In our example, the debit and the credit will most likely be two separate suboperations, and between their execution within the transaction an inconsistent state of the system will be visible. However, it must be remembered that, given the isolation requirement, this inconsistency will not be visible to any other transactions. And atomicity guarantees that the transaction will either be fully completed or none of the transaction's operations will be executed. Thus this intermediate inconsistency remains hidden.
While a transaction is executing, concurrent transactions must not affect its outcome. Isolation is an expensive requirement, so real databases have modes that do not fully isolate a transaction (isolation levels Repeatable Read and below).
Regardless of problems at lower levels (for example, a power outage or hardware failure), changes made by a successfully completed transaction must remain preserved after the system returns to operation. In other words, if a user has received confirmation from the system that a transaction has been executed, they can be sure that the changes they made will not be undone due to any failure.
Below is an example of the ACID property in a DBMS:
If both transactions are submitted together, there is no guarantee that transaction 1 will execute before transaction 2, or vice versa. Regardless of the order, the result must be as if the transactions were executed sequentially, one after another.
Traditional DBMSs are oriented toward the ACID requirements for a transactional system: atomicity, consistency, isolation, durability, whereas in NoSQL a set of BASE properties may be considered instead of ACID:
The term «BASE» was proposed by Eric Brewer, the author of the CAP theorem, according to which, in distributed computing, only two of three properties can be provided: data consistency, availability, or partition tolerance .
Of course, BASE-based systems cannot be used in every application: for stock exchange and banking systems, the use of transactions is a necessity. At the same time, the ACID properties, however desirable they may be, are practically impossible to guarantee in systems with a multimillion-strong web audience, such as amazon.com . Thus, the designers of NoSQL systems sacrifice data consistency in order to achieve the other two properties from the CAP theorem . Some DBMSs, such as Riak, allow the required availability-consistency characteristics to be configured even for individual requests, by setting the number of nodes required to confirm the success of a transaction.
NoSQL solutions differ not only in their design with scaling in mind. Other characteristic features of NoSQL solutions include :
Comments