Details and analysis of the VoltDB argument
Todd Hoff (High Scalability blog) posted a lengthy examination of the case and use cases for VoltDB. That excellent post, in turn, is based on a Mike Stonebraker* webinar for VoltDB, for which the slide deck is happily available. It’s all nicely consistent with what I wrote about VoltDB last month, in connection with its launch.
*Who, in Todd’s apt description, is “the sword wielding Johnny Appleseed of the database world”.
Todd wrote:
What matters to VoltDB is: speed at scale, speed at scale, speed at scale, SQL, and ACID. If that matches your priorities then you’ll probably be happy. Otherwise, as you’ll see, everything is sacrificed for speed at scale and what is sacrificed is often ease of use, generality, and error checking. It’s likely we’ll see ease of use improve over time, but for now it looks like rough going, unless of course, you are a going for speed at scale.
Indeed.
Todd’s list of interesting VoltDB features is also pretty good, namely
- Main-memory storage.
- Run transactions to completion –single threaded –in timestamp order.
- Replicas.
- Tables are partitioned across multiple servers.
- Stored procedures, written in Java, are the unit of transaction.
- A limited subset of SQL ‘99 is supported.
- Design a schema and workflow to use single-sited procedures.
- Challenging operations model.
- No WAN support.
- OLAP is purposefully kept separate.
Comments
Leave a Reply