SQL and NoSQL

Users who eschew traditional relational databases in favor of the newly emerging NoSQL databases might be "throwing the baby out with the bath water," warned a database pioneer before a roomful of NoSQL advocates.

Instead, SQL (Structured Query Language) can be adopted to newer systems with a few technical adjustments, giving it the full flexibility of NoSQL systems, argued Michael Stonebraker, CTO of distributed database software company VoltDB.

Stonebraker, making his argument at the NoSQL Now conference being held this week in San Jose, California, called this approach NewSQL.

While Stonebraker's company itself offers
NewSQL-based database software, his advocacy for this new architecture does carry more weight than the typical vendor pitch. Stonebraker was the chief architect for both the Ingres and Postgres databases, and has contributed to many others. He also co-founded column-oriented database company Vertica, which Hewlett-Packardpurchased in February.

SQL-based relational database systems are indeed as moribund as NoSQL advocates charge, he argued. But this is the fault of the database vendors themselves, not SQL. Calling traditional relational systems "elephants," he noted "Elephants are not slow because they support SQL."

Most of the commercial relational database software packages have been on the market for 30 years or more, Stonebraker charged. They weren't designed for today's automated, data-heavy transactional environments. They've acquired decades worth of questionable new features, often referred to as bloat.

"Oracle doesn't scale," he said. "If you don't need performance it doesn't matter, but if you do need performance [traditional SQL-based systems] don't deliver."

The sluggishness of database systems usually can be attributed to a number of factors, Stonebraker said. Such systems maintain a buffer pool, maintain logs for recovery purposes, as well as manage latching and locking data fields so they aren't overwritten by another operation. In one test held by VoltDB, these behaviors consumed 96 percent of the system's resources.

Many see the emerging popularity of NoSQL databases, such as MongoDB and Cassandra, as an answer to the limitations of traditional database systems.

In another session held at the NoSQL Now conference, consultant Dan McCreary explained some of the shortcomings of regular relational databases that spurred developers to create NoSQL databases.

Relational databases aren't very flexible, he said. The basic architecture was designed during the era of punch cards, and reflects a rigid approach to data modeling. If an organization needs to add another column of data, they must alter the schema, which can be tricky. The modeling process to create relational tables, called entity relationship modeling, also does not always accurately reflect how data exists in the real world.

"There are a lot of things that don't fit into tables well," he said. "It is too restrictive."

Another problem with SQL databases is that they do not scale very well, beyond a single server, McCreary charged. If the data grows beyond the capabilities of a single server, it must be sharded, or split, across multiple servers, which is also a complicated process. Also, executing some operations across multiple servers, such as outer joins, in which data from multiple tables is fused, can be problematic.