Aerospike has announced version 8.0 of its distributed multi-modal database, bringing support for distributed ACID transactions. This enables large-scale online transaction processing (OLTP) applications like banking, e-commerce, inventory management, health care, order processing, and more, says the company.
As Aerospike director of product, Ronen Botzer explains, large-scale applications all require some horizontal scaling to support the concurrent load and reduce latency, which inevitably brings the CAP Theorem into play.
The CAP theorem states that when a network partitions due to some failure, a distributed system may be either consistent or available. In contrast, both of these properties can be guaranteed in the absence of partitions. For distributed database systems, the theorem led to RDBMS usually choosing consistency via ACID, with NoSQL databases favoring availability following the BASE paradigm.
Belonging to the NoSQL camp, Aerospike was born as an AP (available and partition-tolerant) datastore. Later, it introduced support for ACID with its fourth release by allowing developers to select whether a namespace runs in a high-availability AP mode or a high-performance CP mode. CP mode in Aerospike is known as strong consistency (SC) and provides sequential consistency and linearizable reads, guaranteeing consistency for single objects.
While Aerospike pre-8.0 has been great at satisfying the requirements of internet applications [...] limiting SC mode to single-record and batched commands left something to be desired. The denormalization approach works well in a system where objects are independent of each other [...] but in many applications, objects actually do have relationships between them.
As Botzer explained, the existence of relationships between objects makes transactions necessary, and many developers had to build their own transaction mechanism on top of a distributed database. This is why Aerospike built native distributed transaction capabilities into Database 8, which meant providing strict serializability for multi-record updates without hampering performance.
Aerospike distributed transactions have a cost, which includes four extra writes and one extra read, so it is important to understand the performance implications they have. Tests based on Luis Rocha’s Chinook database showed results in line with those extra operations, meaning that smaller transactions are affected most while overhead is amortized in larger ones. All in all, says Botzer,
Transactions perform well when used judiciously together with single-record read and write workloads.
ACID transactions display properties designed to ensure the reliability and consistency of database transactions, i.e., atomicity, consistency, isolation, and durability. They guarantee that database operations are executed correctly. If there is any failure, the database can recover to its previous state without losing any data or impacting the consistency of the data. BASE systems opt instead for being Basically Available, Soft-stated, and Eventually consistent, thus giving up on consistency.