4 ms·

Just read this on VoltDB's site: "Third is NewSQL, which obtains better performance and scale in the only way possible – with a totally new architecture. NewS

by tferris 15y ago

Just read this on VoltDB's site: "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?

MichaelGG 15y ago
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"? 1: http://hstore.cs.brown.edu/publications/ http://hstore.cs.brown.edu/publications/
- MSM 15y ago
  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?
  - benmmurphy 15y ago
    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.
  - jhugg 15y ago
    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.

by tferris 15y ago

MichaelGG 15y ago

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"? 1: http://hstore.cs.brown.edu/publications/ http://hstore.cs.brown.edu/publications/

MSM 15y ago
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?
- benmmurphy 15y ago
  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.
- jhugg 15y ago
  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.