Aerospike is pleased to announce the availability of our 4.3 release.
The 4.3 release contains two key features: All Flash, and uniform balance.
Aerospike is focused on ease of deployment, and easy deployment means efficiency and lower hardware costs, as well as easy to understand and configure transactional consistency. This release builds on Aerospike 4.0 Strong Consistency, now proven through production use; 4.1, which introduced a number of enterprise security features such as data at rest and LDAP integration, and Aerospike 4.2, which includes a storage format improvement which decreases storage requirements by up to 2x in some cases.
Aerospike’s All Flash feature extends Aerospike’s offerings in Hybrid Memory to support a broader set of cases. These uses surround having a very large number ( 100’s of billions ) of small ( < 1000 byte ) objects , which is common in architectures which store individual behaviors as separate database elements, or the need to segregate data elements for GDPR-style data layouts.
In these cases, Aerospike can now be configured to use storage ( often NVMe Flash drives ) as the index. This can radically reduce cost in these cases, although it also increases latency as storage is used for indexes instead of DRAM in Aerospike’s traditional Hybrid Memory configuration. Aerospike is still very high performance. In testing, we’ve seen 150 byte objects still result in 99% < 2ms latencies on Amazon i3 instances – and much higher performance on more modern hardware.
This feature extends Hybrid Memory to provide Aerospike reliability, consistency, and ease of use to areas where traditional relational systems may seem the first choice. By adding to our deployment options, Aerospike provides tiers of deployment strategies suitable for large-scale systems of record where HBase or HDFS may have been the first choice previously.
Uniform balance is a feature which subtly changes Aerospike’s data distribution mechanism, with large positive impacts for deployments with larger cluster sizes – often reducing the cluster size and reducing the hardware cost of running Aerospike.
Aerospike’s prior implementation used a form of random allocation of partitions to nodes, which would normally result in slight differences between the amount of data. That algorithm was chosen because it minimizes the amount of data motion required when nodes are added and removed from clusters. However, we also found that because of the random distribution, some customers were requiring more nodes than were strictly required.
In the following live customer graph, the 90 node Aerospike cluster responded very positively to Uniform Balance. The following real-world case shows the improved data distribution.
Since one no longer has to plan for the “worst case” node you see on this graph, one can reduce cluster hardware and thereby save money. In several real-world cases, we have found that hardware reductions from 30% to 50% are possible.
As always, in-place upgrades through a “rolling update” from prior versions with no service downtime is still recommended.
