Commercial VoltDB is
Mar 1, 2010
Commercial VoltDB is presently much less aggressive than the original H-Store paper in terms of scheduling transactions to minimize conflicts and idleness. We've started with the ability to run single-partition transactions fast, while running some number of multi-partition transactions concurrently. We've identified a set of workloads where this works and are working to release a usable and reliable product for these workloads. In the current VoltDB, transactions will never rollback because of our scheduling, only because of constraint failures of user aborts.
For the time being, the things you can do to avoid idleness in VoltDB:
1. Make transactions single-partition wherever possible. Note that several single-partition transactions will often be faster than one multi-partition.
2. Prefer fewer "batches" of SQL per transaction. A batch is run for every call to executeSQL().
3. In a multi-parititon read transaction, if you can determine the final batch of SQL statements, be sure to use executeSQL(true) variant of executeSQL().
Of course for any non-trivial optimization, try to measure it's impact on performance to see if it's worth it. VoltDB is so different than other systems that sometimes optimization value is hard to predict off-hand.
After our initial public release, we plan to improve the performance of multi-partition transactions via some techniques described in the paper, but also via some new techniques we've been working on. While VoltDB will always be biased toward single-partition procedures, we expect the percentage of multi-partition transactions you can run without severely impacting performance will continue to rise.
Along with usability features and additional SQL support, subsequent releases of VoltDB will be aimed at broadening the set of workloads VoltDB will excel at.