06 Aug BASE

Most relational databases support ACID transactions, that rely on a single data store (often on a single disk or cluster of a handful of disks. Big Data often runs on dozens, hundreds or thousands of physical disk drives, and use BASE transactions to spread out the data and improve resilience. The improvements come when there are a high volume of concurrent transactions, and when one or more physical drives fail.

A transaction standard for database (mostly big data) manipulation that delivers eventual consistency. BASE stands for:

• Basically Available: This constraint states that the system does guarantee the availability of the data as regards CAP Theorem; there will be a response to any request. But, that response could still be ‘failure’ to obtain the requested data or the data may be in an inconsistent or changing state, much like waiting for a check to clear in your bank account.
• Soft state: The state of the system could change over time, so even during times without input there may be changes going on due to ‘eventual consistency,’ thus the state of the system is always ‘soft.’
• Eventual consistency: The system will eventually become consistent once it stops receiving input. The data will propagate to everywhere it should sooner or later, but the system will continue to receive input and is not checking the consistency of every transaction before it moves onto the next one. Werner Vogel’s article “Eventually Consistent – Revisited” covers this topic is much greater detail.

(from Dataversity: http://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/)

Ccompare with ACID transactions common among relational databases.