John Hugg lists the 3 concepts that make VoltDB fast:
- Exploit repeatable workloads: VoltDB exclusively uses a stored procedure interface.
- Partition data to horizontally scale: VoltDB devides data among a set of machines (or nodes) in a cluster to achieve parallelization of work and near linear scale-out.
- Build a SQL executor that’s specialized for the problem you’re trying to solve.: If stored procedures take microseconds, why interleave their execution with a complex system of row and table locks and thread synchronization? It’s much faster and simpler just to execute work serially.
Let’s take a quick look at these.
Using stored procedures — instead of allowing free form queries — would allow the system:
- to completely skip query parsing, creating and optimizing execution plans at runtime
- by analyzing (at deploy time) the set of stored procedures, it might also be possible to generate the appropriate indexes
The benefits of horizontally partitioned data are well understood: parallelization and also easier and cost effective hardware usage.
Single threaded execution can also help by removing the need for locking and reducing data access contention.
While these 3 solutions are making a lot of sense and can definitely make a system faster, there’s one major aspect of VoltDB that’s missing from the above list and which I think is critical to explaining its speed: VoltDB is an in-memory storage solution.
Here are a couple of examples of other NoSQL databases that benefit from being in memory (or as close as possible to it). MongoDB, while being a lot more liberal with the queries it accepts, can deliver very fast results by keeping as much data in memory as possible — remember what happened when it had to hit the disk more often? — and using appropriate indexes where needed. Redis and Memcached can deliver amazingly fast results because they keep all data in-memory. And Redis is single threaded while Memcached is not.
Original title and link: VoltDB: 3 Concepts that Makes it Fast (NoSQL databases © myNoSQL)