"Aerospike does not provide true ACID transactions. Just like Cassandra 2.0, Aerospike only provides compare and set, and misleadingly labels it as ACID."
"Aerospike does not provide true ACID transactions. Just like Cassandra 2.0, Aerospike only provides compare and set, and misleadingly labels it as ACID."
CaS (Compare and Swap, or Compare and Set; they're almost identical, and don't really have a clear distinction) is the process of validating a record's value before performing an update. This helps a lot with Consistency (the C in ACID), but doesn't guarantee the other three (Atomicity, Isolation, and Durability).
Aerospike might have systems in place to address all of ACID, but if they're claiming CaS is ACID then they're just lying.
Look at the Wiki page on ACID ( http://en.wikipedia.org/wiki/ACID ), it's actually pretty good.
Basically, transactions that can span an arbitrary number and set of keys are what makes it possible to build rich data models from simple ones. SQL databases are a perfect example of this - most use a simple transactional data store on the bottom to store complex relational data structures. A single SQL operation may require many key-level updates - but this is OK if you can wrap them all in ACID transactions.Without ACID transactions you can't guarantee data consistency because keys will be getting updated at different times, allowing for a mix of old and new values.
It's a shame to see vendors trying to change the meaning of ACID to fit the limitations of their databases. It means more confusion and bad decisions in a market that needs clarity and honesty for people to make the right decisions for their applications.
As you were describing, there could be many changes performed when doing single record operations as well e.g multiple column updates / secondary index updates.
Does it really need to be multi record transaction to claim ACID ??
* no sane (or performant) way.