Brian Bulkowski, Aerospike Founder and CTO Blog, Technology

Aerospike is pleased to announce the availability of our 4.1 release.

After the major 4.0 release introducing consistency, this release has a backlog of interesting enhancements, beyond a number of minor bug fixes. As always, we continue to push forward reliability and performance, as well as enterprise-oriented features.

LDAP external authentication. Aerospike has a classic user – role – permission access control model, where roles are granted permissions on tables, and the usual trimmings, including exception logging. This feature sits alongside our TLS transport encryption between client and server, within the cluster, and between clusters, and our recent encryption at rest facility (3.15). With external authentication, users can exist either in the local database or in the remote authentication source ( LDAP ), with logins checking both. We call this hybrid authentication, because some users may need lower latency authentication, and some may need the flexibility of external systems.

Several of our valued customers worked with us during Early Access to make sure we had correct configurations for their existing LDAP schemas. We thank them for this support and look forward to further feature requests.

Batch Read optimizations. Based on some recent investigations, we found more and more users are depending on batch reads. This is the primary API pattern for machine learning, fraud detection, social network recommendations, and others. We improved our algorithm regarding threading for batch responses, and achieved a massive parallelism increase on response network transmits, which improves the 99% latency response times, especially in cases where some clients are on congested networks, and some are on fast networks. This is particularly important in public cloud environments.

We strongly recommend this update for any Batch Read workload that is latency sensitive.

Fabric improvements. We have also made a major enhancement in our internal code for intracluster communication. Previously we allocated a transmit buffer per TCP connection. We recognized a major optimization, based on our internal reference counted buffer system, where we could avoid the internal buffer copy. This change also allows the transport layer to rapidly detect cases where an application level retransmit is unnecessary because the initial buffer has not been sent. This also reduces the number of system calls in a variety of cases.

This change benefits every Aerospike deployment, as intracluster communication is on every write and during cluster resynchronization. We are working to characterize the magnitude of the improvement through benchmarking, but write-heavy workload may benefit greatly.

Several other changes bear notice, including the ability to quickly “pause” XDR shipping in the case of a brown-out, and a minor improvement in availability during multi-node outage when running with consistency.

About Author


Brian Bulkowski, Aerospike Founder and CTO

All posts by this author
Brian is a Founder and the CTO of Aerospike. With almost 30 years in Silicon Valley, his motivation for starting Aerospike was the confluence of what he saw as the rapidly advancing flash storage technology with lower costs that weren’t being fully leveraged by database systems as well as the scaling limitations of sharded MySQL systems and the need for a new distributed database. He was able to see these needs as both a Lead Engineer at Novell and Chief Architect at Cable Solutions at Liberate - where he built a high-performance, embedded networking stack and high scale broadcast server infrastructure.