VoltDB Blog » John Hugg

A Peek Inside VoltDB’s VARBINARY Sausage Factory

John Hugg — Wed, 17 Aug 2011 12:36:54 +0000

VoltDB users are pretty passionate, especially when it comes to things they want us to implement. For example, we got a lot of feedback from early users indicating the need for VoltDB to natively support variable length binary objects. Some of those apps were looking to use VoltDB as a K/V store (not as insane as it might sound); some for hybrid K/V workloads; some just needed a general purpose solution for storing custom data structures in VoltDB.

We initially handled VARBINARY use cases by base64-encoding data, then storing it in VARCHAR fields in the database. That workaround satisfied some … Read more

The Sqoop on VoltDB Export and Hadoop Integration

John Hugg — Wed, 22 Jun 2011 12:38:45 +0000

In the last couple of releases of VoltDB, we’ve made steady improvements to our Export feature. Export allows you to build into your VoltDB applications an automatic flow of data from VoltDB to companion datastores (for example, to an analytic database). See this earlier post here. In this post, I’ll describe some of the improvements we’ve made recently, including integration with Hadoop using Apache Sqoop.

Robustness. The 1.3 release of VoltDB made great strides in increasing the robustness of the Export functionality, with a primary focus on building a looser coupling between the consumers of the Export data and

Is VOLTDB Really as Scalable as they Claim?

John Hugg — Tue, 01 Mar 2011 12:40:59 +0000

Baron Schwartz from Percona has published an analysis of VoltDB’s scaling performance on the MySQL Performance Blog. He has worked with our own Tim Callaghan to apply a mathematical model to the Scalability of VoltDB. The conclusion:

VoltDB is very scalable; it should scale to 120 partitions, 39 servers, and 1.6 million complex transactions per second at over 300 CPU cores…

and

…scaling a synchronously replicated, active-active master, fully ACID, always-consistent database to a 40-server cluster is impressive.

A few notes:

As Baron says, these benchmarks were based on our “Voter” example. We ship this example with our distribution … Read more

Why is VoltDB So Fast?

John Hugg — Thu, 13 Jan 2011 12:43:02 +0000

First and foremost, VoltDB is focused on specific workloads. Most existing RDBMSs are designed to be general purpose, one-size-fits-all systems. Recently, there have been a lot of new databases introduced that achieve better performance by specializing in areas like analytics, graphs or streaming data. Few of these specialized systems focus OLTP, and when they do, it’s often more about tuning, rather then a rethink. VoltDB was designed to be the most scalable transaction processing system out there, often making compromises unsuitable for other workloads. For non-OLTP workloads, VoltDB is built to work in concert with other specialized systems. We … Read more

High Availability and Cloudy Problems

John Hugg — Tue, 21 Sep 2010 12:45:46 +0000

VoltDB, like many distributed systems, achieves high availability through redundant processing nodes. VoltDB calls this K-Safety. Essentially, the distributed system can answer any request at at least K+1 servers, so it can tolerate at least K hardware failures. The operator specifies the value of K that they find is the best tradeoff between failure, robustness and cost. Other systems use the terms “replica set” to describe similar functionality.

Let’s talk about EC2-style clouds that provide you with a virtualized server at an hourly cost. Imagine you want to deploy a VoltDB instance of 3 nodes with K = 2, i.e. … Read more

The Lifecycle of a Transaction

John Hugg — Thu, 10 Jun 2010 12:53:40 +0000

When learning about VoltDB for the first time, people often ask how VoltDB executes transactions in a distributed environment. So, here’s how…

Let’s say a developer, Dan, is working on a new website. He’s decided to use VoltDB as part of his data management layer. One of Dan’s users requests a dynamically generated page and the code that generates that page sends a request to Dan’s VoltDB cluster. The excitement begins.

Dan’s code asks the VoltDB client library to execute his procedure named “GetUserProfile” and provides the user’s handle, “dbNerd”, as a parameter. The client library maintains persistent connections to … Read more

Key Value Benchmark FAQ

John Hugg — Tue, 01 Jun 2010 13:00:20 +0000

This is a follow up to a previous post on Benchmarking VoltDB against Cassandra on Key-Value-like workloads.

What’s the point of this benchmark?

Point 1: Demonstrate SQL can be fast. Say what you want about our numbers and benchmark, but the language used to manipulate data was SQL and it clearly wasn’t bottlenecking VoltDB performance. We wanted to show the assumption that dropping SQL is a precondition for performance and scalability is false.

Point 2: VoltDB competes well on simple workloads like the key-value puts and gets, as well as complex workloads like our TPC-C like benchmark.

How … Read more

Key-Value Benchmarking

John Hugg — Tue, 25 May 2010 13:10:07 +0000

Edit on 6/2/10: Check out the follow up Benchmarking FAQ blog post with links to code.

The NoSQL movement was born of the need to scale data management with predicable cost. My subjective summary of the NoSQL credo: provide simpler core functionality, scale horizontally, leverage redundancy, expect and handle failures. These systems became known as NoSQL because SQL and schema was often given up for flexibility and simplicity. The name came about even though SQL was never the primary complaint; scalability was.

VoltDB was born to solve similar problems. Provide horizontal scalability at a cost per transaction that anyone … Read more