Basic Tenets of the ACID Model
There are four basic tenets of the ACID model:
The atomicity of transactions ensures that each database transaction is a single unit that adopts an “all or nothing” approach to execution. If any statement in the transaction fails, the entire transaction is rolled back. Relational databases also ensure the consistency of each transaction with the database’s business rules. If any element of an atomic transaction would disrupt the consistency of the database, the entire transaction fails. The database engine enforces isolation between multiple transactions occurring at or near the same time. Each transaction occurs either before or after every other transaction, and the view of the database that a transaction sees at its beginning is only altered by the transaction itself before its conclusion. No transaction should ever see the intermediate product of another transaction. The final ACID principle, durability, ensures that once a transaction is committed to the database, it is permanently preserved through the use of backups and transaction logs. In the event of a failure, these mechanisms may be used to restore committed transactions.
Core Principles of BASE
NoSQL databases, on the other hand, embrace situations where the ACID model is overkill or would, in fact, hinder the operation of the database. Instead, NoSQL relies upon a softer model known, appropriately, as the BASE model. This model accommodates the flexibility offered by NoSQL and similar approaches to the management and curation of unstructured data. BASE consists of three principles:
Basic Availability. The NoSQL database approach focuses on the availability of data even in the presence of multiple failures. It achieves this by using a highly distributed approach to database management. Instead of maintaining a single large data store and focusing on the fault tolerance of that store, NoSQL databases spread data across many storage systems with a high degree of replication. In the unlikely event that a failure disrupts access to a segment of data, this does not necessarily result in a complete database outage.Soft State. BASE databases abandon the consistency requirements of the ACID model pretty much completely. One of the basic concepts behind BASE is that data consistency is the developer’s problem and should not be handled by the database.Eventual Consistency. The only requirement that NoSQL databases have regarding consistency is to require that at some point in the future, data will converge to a consistent state. No guarantees are made, however, about when this will occur. That is a complete departure from the immediate consistency requirement of ACID that prohibits a transaction from executing until the prior transaction has completed and the database has converged to a consistent state.
Relative Use Cases
The BASE model isn’t appropriate for every situation, but it is certainly a flexible alternative to the ACID model for databases that don’t require strict adherence to a relational model. The optimal use cases for databases using ACID depend on highly structured data with predictable inputs and outputs. Thus, human-resource databases, retail databases and electronic medical records benefit from the robust internal consistency checking that ACID offers. However, BASE solutions are better for fuzzy subjects like sentiment analysis. For example, a BASE-structured project could scan a Twitter feed looking for words that imply emotion based on a specific hashtag. The Twitter feed isn’t well-structured or locally instantiated, but the data stream offers the information that’s programmed into queries even if the scope and nature of that data aren’t cleanly bounded.
