In database systems, ACID (atomicity, consistency, isolation, durability) refers to a standard set of properties that ensure that database transactions are processed reliably.
ACID is especially concerned with how a database recovers from any failure that may occur when processing a transaction.
An ACID-compliant DBMS ensures that the data in the database remains accurate and consistent despite such failures.
is an acronym that stands for atomicity, consistency, insulation, durability. These are explained below.
Atomicity means that you guarantee that the entire transaction is done correctly or none of them does. You don’t get part of it by succeeding and some of it isn’t. If one part of the transaction fails, the entire transaction fails. With atomicity, it is “all or nothing.”
This ensures that all data will be consistent. All data will be valid according to all defined rules, including constraints, waterfalls, and triggers that have been applied to the database.
Ensures that all transactions will be performed in isolation. No transaction will be affected by any other transaction. Therefore, a transaction cannot read data from any other transaction that has not yet been completed.
means that once a transaction is confirmed, it will remain in the system, even if there is a system crash immediately after the transaction. Any changes to the transaction must be stored permanently. If the system tells the user that the transaction was successful, the transaction must have been successful.
When is ACID needed?
ACID properties are designed as transaction-oriented database recovery principles.
Therefore, ACID provides the principles to which database transactions must adhere, to ensure that the data is not corrupted as a result of a failure of some kind.
A transaction is a single logical operation that can consist of one or more steps. For example, transferring money between bank accounts (i.e. debiting one account and crediting the other) is a transaction.
If a transaction like this fails halfway, it could have major consequences. Money could be debited from the first account, but not credited to the other account.
This is where the ACID principles should apply.
According to the ACID definition, a database is consistent if and only if it contains the results of successful transactions. Any ACID-compliant database will ensure that only successful transactions are processed. If an error occurs before a transaction completes, the data will not be changed.
Therefore, ACID-compliant DBMSs give organizations confidence that their database will maintain data integrity, even if some sort of failure occurs while transactions are in the midst of being processed.
A transaction error could occur due to incorrect entry or some other violation of consistency. It could also be due to a timeout or deadlock in the DBMS.
System failure A system error can be caused by an error in the
DBMS code, an operating system error,
or a hardware error. Media
error refers to the condition of not being able to read or write to a storage device (such as the hard disk). This could be caused by the media itself, or it could be due to errors in the operating system.
Media failure is usually quite rare compared to the other two types of failure.
All major relational DBMSs adhere to ACID principles. All include features that ensure data remains consistent during software and hardware lockdowns, as well as any failed transactions.
NoSQL databases are a little different. NoSQL databases are often designed to ensure high availability in a cluster, which usually means that consistency and/or durability are sacrificed to some extent. However, most NoSQL DBMSs can provide atomicity to some extent.
Most NoSQL DBMSs work consistently, meaning data may be out of sync for a while, but will eventually be in sync.
However, some vendors, such as MarkLogic, OrientDB, and Neo4j, offer ACID-compliant NoSQL database management systems.