It’s been a quarter since we launched our Developer Experience (DX) manifesto. So what’s been happening since? Well, a whole lot of interesting things, all focused on helping you, the developer, build better, more engaging applications – faster. But first, let’s recap what DX means to us:
APIs must be natural Regardless of your language of choice, the APIs that Aerospike present should seem natural and obvious. You should not have to jump through unnatural hoops to make things work in your language of choice.
APIs must be simple Your mission is building awesome applications, not deciphering obscure syntax for doing simple operations. Accordingly, let’s keep things simple for you.
APIs must be current Languages change, and the frameworks around those languages continuously evolve. You don’t want your Database vendor pinning you to outdated frameworks or language versions.
Trust and communication is a two-way street You trust Aerospike to build, maintain and evolve our platform. We must keep you in the loop, not just about the changes themselves, but also about our motive in making them. We must listen to your feedback and act on it.
Spring 2016 Release
As of Spring 2016, we are pleased to announce the availability of the following:
Docker integration
Production-ready Geospatial
Asynchronous programming support with C/C++ client v4.0
Python 3 support
Node.js client v2.0
Indexed List, Map & GeoJSON
Play Framework integration
Spring Data integration
Docker Integration
Containers are seen as a simple way to:
Encapsulate the dependencies for the process you want to run, e.g., the packages required, the frameworks that need to be present, your code, etc.
Provide isolation at runtime, enabling containers each with different dependencies, O/S kernel versions, etc. to coexist on the same physical host.
Application architectures are also evolving, especially with the adoption of microserver-like architectures. Your application is no longer one humongous, static binary or set of packages; it’s starting to look like a series of discrete services that are brought together dynamically at runtime. This is a natural fit for Containers. But how does this fit with services that require persistence or require long running processes?
The integration we have done with Docker enables you to:
Scale the persistence layer, both up and out
Eliminate reconfiguration of the application and database tier as Containers enter and leave the topology
Utilize Containers on your own dedicated infrastructure or public cloud providers
Integrate with Docker Compose, Docker Swarm and Interlock framework
To download all current major versions, please go to Docker Hub. For more information, please see our documentation and blog post.
Geospatial is Now GA with Aerospike Server v3.8
With the Aerospike Server v3.7 release, we announced Geospatial as an experimental feature. In v3.7, Aerospike could store GeoJSON objects and execute various queries, allowing an application to track rapidly changing Geospatial objects or simply ask the question, “what’s near me?”. Internally, we use Google’s S2 Geometry Library and Geohashing to encode and index these points and regions.
Aerospike Server v3.7 added support for the following:
Creating Geospatial Indexes on GeoJSON data
Queries
Points within a Region
Points within a Radius
Regions a Point is in
Results can be filtered with a User Defined Function (UDF)
We are happy to announce that in v3.8, Geospatial is now GA (Generally Available) and ready for production use. For more information, please see the documentation and blog post with an example application.
C Client v4.0 – with Async Support
The Aerospike C/C++ v4.0 client is the latest client to support asynchronous programming. In doing so, it joins the Java and C# clients.
The following are supported in this release:
Libev & libuv event loop support
Extensibility (e.g., the ability to add another eventing system)
Single-record commands (put, get, operate & apply)
Multi-record commands (batch, scan & query)
Going forward, we will extend the client’s functionality to support Lua aggregations. For more information, please see the documentation and blog post with an example application.
The Python client v2.0 introduces support for Python 3. There are many changes in the language that impact the Python client, namely:
Xrange
Print
Exceptions
Strings
Division
We have a blog post that dives into each of these topics; it should help you understand how and when to use the new features, as well as the impact to your existing code.
Node.js Client v2.0
The Node.js Client has undergone some significant refactoring; hence, we bumped the version number to 2.0. To summarize the changes, Node.js v2.0 now features the following:
Asynchronous I/O support (AIO)
Node v0.12 support and above (we’re deprecating v0.10)
Error-first callback semantics
Batch reads
Some of these modifications (for instance, error-first callback semantics) are breaking changes (i.e., not backward compatible), so it’s critical you review them before you upgrade. It’s not something we like to do, but after feedback from the community — a key requirement from the manifesto — we felt that making the changes was important in order to create a more natural interface for Node.js developers.
For more information, please read our documentation and blog post.
Secondary Index on List, Map & Geospatial
It is now possible to create Secondary Indexes on bins which contain Lists & Maps of Scalar and Geospatial data. This allows for query predicates to be evaluated against values within those data structures. For example (in Python):
import aerospike
def print_result((key, metadata, record)):
print(record)
config = { 'hosts': [ ("localhost", 3000), ] }
client = aerospike.client(config).connect()
client.index_list_create("test", "test-set", "nums", aerospike.INDEX_NUMERIC, "nums-idx", {})
# Insert the records
key = ("test", "test-set", '1-2-3')
client.put(key, {'name': "1,2,3", 'nums': [1, 2, 3] } )
key = ("test", "test-set", '5-7-11-11')
client.put(key, {'name': "5,7,11,11", 'nums': [5, 7, 11, 11] } )
# Query for value 11, will return one record
query = client.query("test", "test-set")
query.where(aerospike.predicates.contains("nums", aerospike.INDEX_TYPE_LIST, 11))
query.foreach( print_result )returns the second record inserted, since it has at least one value of 11 in the nums list.
{'name': '5,7,11,11', 'nums': [5, 7, 11, 11]}There are APIs available for the following languages and clients:
C
C#
Java
Go
Python
PHP*
Node.js*
For more information, please see the documentation for Lists, Maps & Geospatial. * PHP and Node.js clients have Map & List index support. Geospatial list indexes will be added shortly.
Play 2.0 Integration
We have released caching and session store plugins for the Play Framework. Thanks to these plugins, you’ll be able to use the Aerospike database quickly and easily within the Play 2.0 Framework from Java or Scala, and with no application code changes. Although Aerospike’s reliability and persistence allow it to be used as the core database for an application, its extremely low and predictable latency, combined with its ability to both read and write rapidly and expire data accurately, make it an excellent choice for both caching and session management.
In this release, we have two plugins:
A cache plugin
A session store plugin
For more information, please see the documentation and blog post.
Spring Data for Aerospike
Spring Data’s mission is to provide a familiar and consistent, Spring-based programming model for data access while still retaining the special traits of the underlying data store (see Spring Data).
Spring Data for Aerospike is an open source community project hosted under the Spring umbrella and sponsored by Aerospike. It provides a data layer to Aerospike that is familiar to Spring developers and works in harmony with the full Spring suite, including Spring Boot and Spring MVC. The Spring Data for Aerospike project provides integration with the Aerospike key-value database. Key functional areas of Spring Data for Aerospike include a POJO-centric model for interacting with an Aerospike Namespace and Set, and the ability to easily write a repository-style data access layer.
Spring Data for Aerospike features the following:
Java-based @Configuration classes or an XML namespace for an AerospikeClient instance to access an Aerospike Cluster
AerospikeTemplate helper class that increases productivity-performing Aerospike operations. This includes integrated object mapping between Records and POJOs
Optimized query engine for handling multi-filter queries in the cluster
Exception translation into Spring’s portable Data Access Exception hierarchy
Feature-rich Object Mapping integrated with Spring’s Conversion Service
Annotation-based mapping metadata, but extensible (to support other metadata formats)
Persistence and mapping lifecycle events
Low-level mapping using the Aerospike Client API
Java-based Query, Criteria, and Update DSLs
Automatic implementation of Repository interfaces, including support for custom finder methods
Querydsl integration to support type-safe queries
Cross-store persistence – support for JPA Entities with fields transparently persisted/retrieved using Aerospike
MapReduce integration
For more information, please see the documentation and blog post.
What’s Next?
Here are a couple of features we are looking to deliver in the first half of this year. This is just a preview and not a commitment!
Sorted Map
We are making great progress to provide manipulation of Sorted Maps on the server side, similar to the List features added in 3.7. The APIs were not quite baked enough to be an experimental feature in the 3.8 server release, but we hope to preview these shortly.
Last Time Updated
We are making some changes to the metadata that is maintained for each record. As a result, one of the benefits is that we will be able to capture the last update time for each record, and expose that back through the client APIs. Since this is system-maintained, it reduces the work your application needs to do to record and maintain this information.
Through the Telescope
The overall goal for DX for the next twelve months is to:
Maintain currency with OSs, Distros, and Client Languages (e.g., PHP 7)
Provide fully asynchronous drivers for every client language
Improve the usability of the APIs & the clarity of the error messages
Provide a standard set of User-Defined Functions (UDFs) for typical functions
Improve documentation & examples
Extend native datatype support (who doesn’t love Datetime and Counters?)
As always, we need your help and input to continue to improve and enhance your DX. Please contribute your feedback, ideas and questions to our user forum, file Github issues or create a pull request for the next great feature you’d like to contribute to the Aerospike user community!
