Aerospike Database 5.4: Usability Improvements & Human-Readable XDR Filter Expressions

Aerospike is pleased to announce Aerospike 5.4, which will be available to customers in January of 2021. Much of the work on this release is to prepare for features to be rolled out later in the year. This round of foundational improvements does not expose any external APIs. The visible features are concerned with usability improvements, particularly in an operational context. There are also modest improvements in memory usage.

Fetching Feature Keys via HashiCorp Vault or Environment Variables

Prior to 5.4, Feature Keys were fetched from a file whose location was contained in the ‘feature-key-file’ service context configuration parameter. Deployments can now specify either a file (as before), a HashiCorp Vault path, or an environment variable. This is achieved by enhancing the syntax of ‘feature-key-file’:

• vault:<path>: the prefix indicates that the feature keys will be found at the indicated path in a HashiCorp Vault secret.

• env:<env-var> or env-b64:<env-var>: the prefix indicates the feature keys will be found in the specified environment variable, either in plain text or base64-encoded.

• <path>: no prefix indicates that the feature keys will be found in the file at the indicated path in the local file system the server is running on (i.e. pre-5.4 behavior).

Human-Readable XDR Expressions

Presently the ‘xdr-get-filter’ command displays an XDR Filter Expression as a base64 string. Starting with 5.4, the filter Expression will be shown in a logical language that is human readable (it uses the same syntax as the documentation for Expressions). However, it is for display only: it can’t be used to input an XDR Expression.

If base64 strings are desired as output, the pre-5.4 behavior can be obtained by including the optional parameter ‘b64=true’ in the issued info command.

Minor Features

Aerospike 5.4 includes a number of minor features, the most notable of which are described below. As always, refer to the 5.4 release notes for complete details and restrictions. Some of these features are available only in the Aerospike Enterprise Edition.

• Changed logging level for scans: Scan jobs create ‘info’ log entries when they start and finish. This creates log pollution when there are many small scans (e.g. single partition scans with small ‘sample-max’ values). To mitigate excessive log entries under this scenario, for 5.4 the logging level for these messages has been changed to ‘debug’

  .

• Changed logging level for policy violations in CDT, HLL and bitwise operations: reduces log pollution by lowering the ‘warning’ to ‘detail’ when a policy violation occurs, such as a Map operation with a CREATE_ONLY write flag. This aligns CDT write policy violations with the handling of record policy violations, for example a put() with a record exists action policy of CREATE_ONLY generates a ‘detail’ log entry.

• Reduced memory usage for in-memory namespaces: For in-memory namespaces (configuration parameter ‘data-in-memory true’), memory usage has been reduced by one byte per bin when XDR bin shipping is not enabled. This is reflected in the following table: