Read the H-Store publications[1], which served as the starting point for Volt.
Basically, by staying in memory and eliminating locking, you get awesome performance. However, why should you have to give up SQL, tables, and transactions? Those things make developing apps easy. So why not get "NoSQL-like" performance, but keeping the good parts of "SQL"?
After looking around I'm still not sure what they mean by 'eliminating locking'. Locking isn't just overhead, it's needed for transactions- how are transactions handled if there is no locking? Does the speed come at the cost of dirty reads and writes?
VoltDB achieves concurrency via scheduling, rather than shared access to data structures.
There are concurrency primitives around networking/messaging and transaction scheduling, so there aren't truly ZERO locks in the system as a whole.
The big difference is that VoltDB has zero system-locks (mutexes,etc) around table data and indexes. It also has no logical locks/latches arounds indexes and rows like other systems. This makes executing SQL very fast. Because it doesn't wait on disk or on mutexes, SQL execution is typically bottlenecked on memory bandwidth.
Re:695k TPS with Node.js and VoltDB
by benmmurphy on Tuesday April 17, 2012 @12:47PM
(#3853504)
I think they partition the data then serialize access in the partition. Makes things very fast assuming you only need to modify stuff atomically in one partition.
"Third is NewSQL, which obtains better performance and scale in the only way possible – with a totally new architecture. NewSQL delivers high performance and scalability while preserving the traditional ACID functions needed for OLTP. NewSQL systems like VoltDB deliver better throughput than NoSQL without requiring transactions to be supported in user code. NewSQL systems also preserve the high-level language capabilities of SQL."
How does this work?