VoltDB is a memory-only, partition based system. Each partition has a
set of replicas that execute in lock step. Two replicas are required
for durability, three for availability, more are possible. Each replica
executes as a single thread without locking or thread synchronization.
The idea is that all resources are sitting in memory, so it fastest to
run one thread straight out, get the job done, and let the next task get
scheduled. Multi-core machines (what other kind are there?) can run
processes from different partitions, so the cores are wasted. The
mantra is that all machine cycles are spent doing useful work as opposed
to locking and thread synchronization.

VoltDB supports only store procedures (their own, of course); ad hoc SQL
is not allowed. A transaction is a stored procedure invocation. Their
compiler breaks stored procedures into task, each of which executes on a
specific partition.

Concurrency is managed by a single, cluster-wide transaction schedule
that understands the semantics of all declared stored procedures and
knows, therefor, the potential interactions. Transactions / procedures
/ tasks that execute in a single partition run sequentially -- very fast
and efficient.

The fly in the ointment is when a stored procedure can be executed in a
single partition. Examples are any retrievals to partitioned tables
that don't include the partition key (a simple count, for instance) or a
cross partition join. The scheduler has to run a cross partition
procedure simultaneously on all partitions it references. Since most
cross partition procedures can reference any or all partitions, only one
of these can be scheduled in the cluster at any given time. This
reduces the performance of the entire cluster to the speed of a single core.

They also do some questionable stuff like turning off the undo log if
their compiler decides that a stored procedure can't fail. TPCC
contains a small number of transactions that insert intentional
duplicate values into a unique index to test rollback. VoltDB fudges
these by re-writing the transaction to check for the duplicate values
before executing any updates, obviating the need to roll back.

Stonebreaker, et all, argue that database threads spend 40% of their
time doing locking and thread synchronization. In VoltDB, 67% of all
cycles are wasted in replicas executing in lock step in case the primary
fails. Bah, I say, bah.


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376