The first goal of any system is to solve the problem.
The second goal is to do it for less money.
In this case money represents all investment, including hardware costs, app-development costs, licensing costs, and importantly, development time spent by engineers.
We target these costs in a couple of ways:
- The highest ratio of performance to hardware among operational databases.
- We leverage common skills and standards like SQL.
- Powerful features like ACID transactions, server-side code and other rich database features make developing applications easier.
- Open source and flexible commercial licenses.
But one of the biggest ways is simple operations. The easier VoltDB is to run in production, the less work your team needs to do. The easier VoltDB applications are to change in production, the less work your team needs to do. Making your job easier saves you money and gets your problem solved faster.
All Nodes are the Same
- There are no leader nodes.
- There are no primary or replica nodes.
- There are no aggregator or leaf nodes.
From an operational standpoint, if you want a seven node cluster and you have seven linux systems with VoltDB installed, you don’t have to think much beyond that.
When a node fails, you don’t have to worry about what’s on disk. You don’t have to replace it with the same special type of node, just replace it with any linux system that has VoltDB installed. It’s a pretty short, one-line command.
Behind the scenes, we do have some specific roles that get assigned to nodes, but the administrator isn’t involved. There’s an internal election process that assigns jobs, and the assignments are updated when nodes fail, when nodes rejoin, and when the cluster size changes.
Keeping with the VoltDB philosophy, we make this our problem so you can worry about your business.
Less Tuning: Knobs are for Furniture
VoltDB has sensible defaults for typical workloads built in.
The VoltDB founders have plenty of experience with traditional relational databases, and plenty of frustration tuning them. Culturally, we want as few knobs as possible. This makes the documentation shorter; it makes your configuration shorter; it makes VoltDB simpler to operate.
When our engineering team comes across a possible tradeoff, and is tempted to add a knob we ask some questions:
- Can we remove this tradeoff by making the product better?
- Can we automatically pick the best value?
- Is the variation in performance for this knob meaningful?
It’s a pretty high bar for us to add a tunable to VoltDB, and even when we do, getting the default value correct is something we take very seriously.
Transactional App Updates
When a user needs to add a table, change some procedure code, or update an application setting, VoltDB considers that a transactional update. The change will happen at the same logical time, all over the cluster.
Not just transactional, but updates will do as much work as possible asynchronously, such that the actual transition from one version of your app to the next happens with minimal impact on latency.
This is just one example of a number of operational events, like live version upgrade or online cluster expansion. In every case, we work to make the operation smooth, simple and clear. If something is going to fail, we want you to clearly understand the problem and we want to leave your cluster in a known-good state.
Auditing & Administration
Everything important or interesting that happens in a VoltDB cluster is logged using the standard and highly configurable log4j logging system.
Use any of the included administrative tools to monitor VoltDB, or connect third-party monitoring agents that you may already be using.