ACID principles in database world

ACID describes a set of desirable properties for database transactions:atomicity,consistency, isolation,and durability. The exact definitions of these terms can vary. As a general rule, the more strictly a system guarantees ACID properties, the greater the performance compromise.This ACID categorization is a common way for developers to quickly communicate the trade­offs of a particular solution,such as those found in NoSQL systems.

1. Atomicity: transactions either succeed or fail in entirety An atomic transaction can’t be partially executed: either the entire operation completes, or the database is left unchanged. For example, if a transaction is to delete all comments by a particular user, either all comments will be deleted, or none of them will be deleted. There is no way to end up with some comments deleted and some not.Atomicity should apply even in the case of system error or power failure. Atomic is used here with its original meaning of indivisible.
2. Consistency: constraints are always enforced The completion of a successful transaction must maintain all data­integrity constraints defined in the system. Some example constraints are that primary keys must be unique, data conforms to a particular schema, or foreign keys must reference entities that exist.Transactions that would lead to inconsistent state typically result in transaction failures, though minor issues may be resolved automatically;for example,coercing data into the correct shape. This isn’t to be confused with the C of consistency in the CAP theorem, which refers to guaranteeing a single view of the data being presented to all readers of a distributed store.
3. Isolation: concurrent transactions don’t interfere Isolated transactions should produce the same result, whether the same transactions are executed concurrently or sequentially. The level of isolation a system provides directly affects its ability to perform concurrent operations. A naïve isolation scheme is the use of a global lock, whereby the entire database is locked for the duration of a transaction, thus effectively processing all transactions in series. This gives a strong isolation guarantee but it’s also pathologically inefficient: transactions operating on entirely disjointed datasets are needlessly blocked (for example, a user adding a comment ideally doesn’t block another user updating their profile). In practice, systems provide various levels of isolation using more fine­grained and selective locking schemes (for example, by table, row, or field). More­sophisticated systems may even optimistically attempt all transactions concurrently with minimal locking, only to retry transactions by using increasingly coarse­grained locks in cases where conflicts are detected.
4. Durability: transactions are permanent The durability of a transaction is the degree to which its effects are guaranteed to persist, even after restarts, power failures, system errors, or even hardware failures. For example,an application using the SQLite in­memory mode has no transaction durability;all data is lost when the process exits. On the other hand,SQLite persisting to disk will have good transaction durability, because data persists even after the machine is restarted.This may seem like a no­brainer: just write the data to disk—and voila,you have durable transactions.But disk I/O is one of the slowest operations your application can perform and can quickly become a significant bottleneck in your application,even at moderate levels of scale. Some databases offer different durability trade­offs that can be employed to maintain acceptable system performance.

give a visite to my site : ahmed khaled