This chapter describes what new features are introduced in V12.0 and what upgrade tasks may be required of existing customers.
Volt 12 is a major release that includes several key features. First and foremost, the memory management for the database table data has been rewritten and optimized to reduce certain impediments in the previous implementation. Although this change is primarily internal and transparent to you as a customer, it does have two direct benefits in terms of eliminating development and operational roadblocks:
No Large Compaction Events — As tuples are inserted and deleted, small gaps of unused memory are created within the larger allocated blocks. Previously, if the total amount of allocated but unused memory hit a specific high watermark, the database would compact all of the table memory before continuing. As effective as this mechanism was, it could result in unpredictable latency spikes in the ongoing workload.
Now, defragmentation of data storage is performed incrementally on a per table and per partition basis. Since the compaction transactions are much smaller, and also partitioned, they have little or no impact on the ongoing business workload. In addition, you as the database administrator have control over how large those periodic compaction events are and and how often they occur. See the chapter on memory management in the Volt Performance and Customization Guide for more information about the new memory management algorithm.
No Hash Mismatches Due to Row Order — In the past, developers had to be careful not to introduce non-deterministic behavior into their stored procedures by performing unordered queries. The issue was that, when using K-Safety, different copies of a partition could return results in a different order if you did not include the appropriate ORDER BY clause.
A key aspect of the memory management scheme introduced in V12.0 is that all copies of a partition now always return a query's results in one, deterministic order, even if the query itself is not sorted. This means that queries without an appropriate ORDER BY clause will not cause a hash mismatch.
Mind you, including an ORDER BY clause is still recommended so you can depend on the order in which the results are returned. Although VoltDB now returns results in a deterministic order, you do not know what that order will be. Also, although the new deterministic row order helps, there are other practices (such as calling system-specific time functions) that still cause hash mismatches and must be avoided. See the section on stored procedures and determinism in the Using VoltDB manual for a reminder of what to watch out for.
Other new features introduced in V12.0 and recent releases include:
Support for Ubuntu 22.04 and the Rocky OS — Volt Active Data has added Ubuntu 22.04 and Rocky OS as supported platforms for VoltDB.
Support for storing TLS/SSL credentials in Kubernetes secrets — When enabling TLS/SSL in Kubernetes, you can now store your TLS/SSL credentials (including the keystore, truststore, and passwords) in a Kubernetes secret. This avoids having to specify passwords on the Helm command line and simplifies the commands needed to start and update database instances. See the section on configuring TLS/SSL in the Volt Kubernetes Administrator's Guide for details.
Expiration dates for user accounts — You can now specify an expiration date for user accounts in the database configuration file. Once the specified date is past, the associated account can no longer access the database, until the configuration for the user account is updated. The expiration date is optional. See the section on defining users and roles in the Using VoltDB manual for details.
New LAG() windowing function — The LAG() function accesses previous rows from the window results using an offset. See the section on windowing functions in the SELECT reference page for more information.
Dedicated pod for VMC and HTTP API in Kubernetes — By default, Volt in
Kubernetes now creates a separate pod for the Volt Management Center (VMC) and HTTP API. This provides a single service
name for accessing these resources, as well as a single instance for the entire cluster (rather than separate instances
for each host). The new pod is available from the service name {release-name}-voltdb-vmc where
{release-name} is the name of the Helm release for the database cluster.
Documentation