Aerospike ACID clarification

Question

Aerospike database says, that it is

[...] architected with three key objectives:
To create a flexible, scalable platform that would meet the needs of today’s web-scale applications
To provide the robustness and reliability (ie, ACID) expected from traditional databases.
To provide operational efficiency (minimal manual involvement)

And in other place:

Aerospike is optimized to work with the latest in storage and database technology to squeeze as much transaction throughput as possible while still guaranteeing strong consistency (ACID).

First of all I didn't found any definition of transaction in Aerospike. Normally I get it as a sequence of operations on a database. However reading later I don't see that transactions are ACID:

When reading a detailed Aerospike ACID description I found that it only pretends ACID guarantees.

Examples:

• I want to make a sequence of operations (a, b, c) in a transaction. Each operation is an independent DB query. If c fails then I want a and b be rolled back by a DB system. I didn't found this feature in Aerospike.

• Let's consider two concurrent transactions modifying a documents A and B. At the beginning A=0 and B=0:

  • T1 adds 1 to A and B
  • T2 multiply A and B by 2.

  I expect that always we end up with A==B - result will be either:

  • A=1 & B=1 when T2 will firstly locks/take ownership on documents A and B
  • A=2 & B=2 when T2 will firstly locks/take ownership on documents A and B

  What is a guarantee of this result?

1. Can you confirm my results of my examples?

2. Does User Defined Functions helps somehow here?

PS

To be clear - I don't want say that Aerospike is bad. I see a great piece of good work there. I'm just missing a good clarifications when ACID guarantees fails there.

Answer 1

As stated at the bottom of page 2 of the document you referenced: http://www.aerospike.com/docs/architecture/assets/AerospikeACIDSupport.pdf

and in our documentation on the website that you pointed to: http://www.aerospike.com/acid

For read/write operations on a single record, Aerospike makes strict guarantees about the atomicity of these operations:

If you keep reading either source, they address all of the ACID properties of Atomicity, Consistency, Isolation and Durability as applied to a single record.

With NoSQL databases, the term ACID is commonly used to refer to the multiple copies of a record within a single distributed (cluster) server environment, and that all copies of the same record are written in an ACID manner. Multiple copies of a record are kept in the distributed database to provide High Availability, and Failover. Most of our production customers are satisfied with 2 copies because of the robust nature of our database.

Aerospike commits to this within a single clustered instance of the database. If you choose to have multiple clustered instances in different locations/datacenters (for geo-location strategy or disaster recovery), then we commit to ACID compliance for an individual database instance only.

Our XDR (Cross Data Center Replication) will replicate the record to remote instances of Aerospike in other locations for you automatically, so our process sending the records to the other locations will appear as Aerospike client to the remote instance and again, the ACID compliance is for a single record being sent to the remote instance. This happens on the order of seconds to account for network latencies and other factors not within Aerospike’s control. We do NOT support ACID across multiple instances/geographies.

Aerospike does not have a transaction management API at this time, so even using User Defined Functions (UDFs) will not allow you the ability to roll back a series of steps as you described in your example, should one of the steps fail. Aerospike has never made this claim, but as often happens in the technology industry, words are used in multiple contexts, and it is easy to get the situations confused.