VoltDB

VoltDB uses a shared-nothing architecture to achieve database parallelism, with both data and processing distributed across all the CPU cores within the servers composing a VoltDB cluster. In other words, the product should scale as the number of cores increases, not just by the number of servers. Horizontal partitioning also enables scalability. SQL access is supported via pre-compiled Java stored procedures. The unit of transaction is the stored procedure, which is Java interspersed with SQL. Further, stored procedures are executed in the partition containing the relevant data, which means that it is possible to eliminate round trip messaging between SQL statements, which is another reason for the performance of VoltDB.

Fig 01 VoltDB exporters

More generally, VoltDB leverages in-memory techniques to improve performance, but also supports spill-to-disk capabilities where memory capacity is insufficient. For data that is merely warm or cold, as opposed to hot, VoltDB provides exporters, as can be seen in Figure 1. As can be seen in this diagram, VoltDB supports ingestion from streaming sources (Apache Kafka, Amazon Kinesis plus various message buses) and export to data lakes and other dedicated analytic environments. From the latter, machine learning models may be imported into VoltDB using PMML (predictive modelling mark-up language), where they are treated as stored procedures. While we applaud the support for PMML as an interoperable standard, it is unfortunately true that many machine learning and AI models are not PMML compatible, so we would like to see VoltDB supporting models built by language (R, Python, Scala and so forth).

While on the subject of machine learning and stored procedures, it is also worth noting that some types of analytics have fairly static requirements compared to machine learning, which is typically dynamic. An example, would be compliance with MiFID II. We comment upon this because one of VoltDB’s customers has embedded the Drools rules engine into VoltDB as a stored procedure precisely as a mechanism to enforce compliance with MiFID II.

Finally, VoltDB supports containers and Kubernetes is used for orchestration. Multi-site active/active deployments are available.

There are multiple ways to support hybrid environments that support both transaction processing and analytics with low latency in both cases. Some of these approaches will be more familiar than others and we would argue that familiarity and the ability to use SQL are major benefits. Conversely, you need a distributed architecture to support environments such as the Internet of Things, where a substantial amount of processing is needed at the edge. VoltDB has the advantage of meeting both of these requirements, with ACID compliance, low latency and – likely – lower cost of ownership.

The Bottom Line

For all intents and purposes VoltDB should be thought of as a (distributed) relational database. Making the move to VoltDB, whether as a replacement for an existing system, or for deployment within a greenfield environment, will be a non-disruptive choice that is worth serious consideration.