Aerospike storage backend for Janusgraph
Aerospike based implementation of Janusgraph storage backend. When to use: If you need horizontally scalable graph DB backed by Aerospike.
Emulate transactions via WAL
The main difference with other traditional backends (Canssandra, Berkeley) is that Aerospike does not support transactions.
On each commit Jansugraph writes batch of updates that should be applied to storage backend all together.
In other case graph may become inconsistent.
So we need to emulate transactional behaviour and not surprisingly made it via Write Ahead Log. Prior to applying updates we save all batch as one record in Aerospike separate namespace and remove this record after all updates being applied. This allows WriteAheadLogCompleter that runs on each node in separate thread to finish (with configured delay) all needed updates in case of some node had died in the middle of the batch.
Collects all locks that transaction needs and acquire them just in commit phase. Allows us to run all lock acquisitions in parallel. This approach caused Aerospike storage backend to be classified as optimisticLocking In terms of Janusgraph DB.
Janusgraph keeps vertex and all adjacent edges in one record.
That makes it sensitive to max record value size in key-value storage.
Aerospike record size is limited by 1Mb by default and can be increased up to 8Mb in namespace configuration. It makes sens to configure WAL namespace to use maximum value (8Mb).
This benchmark was run using standard 'cassandra:3.11' docker image and custom aerospike image that doesn't keep any data in memory. https://github.com/kptfh/aerospike-server.docker
To run benchmarks and test on your local machine you just need to have docker installed.