Dan Weinreb comments on Michael Stonebraker’s Urban Myths about SQL (PDF) :

Dr. Michael Stonebraker recently posted a presentation entitled “Urban Myths about NoSQL”. Its primary point is to defend SQL, i.e. relational, database systems against the claims of the new “NoSQL” data stores. Dr. Stonebraker is one of the original inventors of relational database technology, and has been one of the most eminent database researchers and practitioners for decades.

In fact, Michael Stonebraker bashes everything that is not his current product—this GigaOm interview is the latest example.

For now, I’m filing this away until VoltDB is sold.

Original title and link: Comments on Urban Myths About NoSQL (NoSQL database©myNoSQL)

via: http://danweinreb.org/blog/657

Percona guys^[1] have run, analyzed, and concluded about VoltDB scalability:

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

Considering the definition: “A system whose performance improves after adding hardware, proportionally to the capacity added, is said to be a scalable system.”, the conclusion should be slightly updated:

VoltDB can scale up to 120 partitions on 39 servers with 300 CPU cores and 1.6 million TPS.

Bottom line:

• if you can fit your data into 40 servers’ memory
• you need ACID and SQL
• you are OK precompiled Java based stored procedures
• you don’t need multi data center deployments

now you can estimate how far you can go with VoltDB.

Original title and link: How Scalable is VoltDB? (NoSQL databases © myNoSQL)

via: http://www.mysqlperformanceblog.com/2011/02/28/is-voltdb-really-as-scalable-as-they-claim/

Drizzle aims to be different from MySQL, stripping out “unnecessary” features loved by enterprise and OEMs in the name of greater speed and simplicity and for reduced management overhead.

Drizzle has no stored procedures, triggers, or views […]

Aiming to provide a database for the cloud with support for massive concurrency optimized for increased performance, Drizzle team started by removing “non-essential” code and features. Michael Stonebraker’s VoltDB is focusing on a different set of optimizations for achieving performance — removing logging, locking, latching, buffer management^[1].

Anyway, it is not about who’s approach is better, but which scenarios are covered by using a simplified MySQL compatible database or by an in-memory with predefined queries database.

Original title and link: MySQL Fork Drizzle Released (NoSQL databases © myNoSQL)

via: http://www.channelregister.co.uk/2011/03/16/drizzle_released/

John Hugg lists the 3 concepts that make VoltDB fast:

1. Exploit repeatable workloads: VoltDB exclusively uses a stored procedure interface.
2. 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.
3. 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:

1. to completely skip query parsing, creating and optimizing execution plans at runtime
2. 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)

via: https://voltdb.com/blog/why-voltdb-so-fast

VoltDB 1.2 released earlier this month:

New data availability features. Version 1.2 introduces two important data availability enhancements. The first is network partition tolerance, which allows VoltDB to automatically detect, isolate and manage network failures. This is a critical feature for distributed database infrastructures including those deployed into public clouds such as Amazon’s EC2. The second availability feature, node rejoin, allows VoltDB database nodes that have been taken offline (e.g., for maintenance or repair) to “rejoin” the cluster while the database is live. Node rejoin dynamically resynchronizes all node data.

I’d love to read more about about the mechanisms used for automatically detecting, isolating and managing network failures. (If I remember correctly) The topic of reliably determining partitions in a distributed system is a central part of Seth Gilbert and Nancy Lynch paper on CAP theorem. It would also be interesting to understand how VoltDB deals with its strong consistency promise in these situations.

And some management tools (nb: by the announcement text I cannot tell if they are available only in the Enterprise version):

New consoles for provisioning, management and monitoring. New in the Enterprise Edition of version 1.2, the VoltDB Enterprise Manager (VEM) provides database and systems administrators with browser-based tools for managing production VoltDB databases. VEM offers a flexible suite of consoles for performing many common administrative and diagnostic activities.

Original title and link: VoltDB Release: Version 1.2 Featuring Data Availability Enhancements (NoSQL databases © myNoSQL)

via: https://voltdb.com/content/voltdb-releases-version-12-high-performance-oltp-database

How many times do you need to run PK lookups per second? […] These are “SQL” overhead. It’s obvious that performance drops were caused by mostly SQL layer, not by “InnoDB(storage)” layer. MySQL has to do a lot of things like below while memcached/NoSQL do not neeed to do.

• Parsing SQL statements
• Opening, locking tables
• Making SQL execution plans
• Unlocking, closing tables

MySQL also has to do lots of concurrency controls.

The story has been out for a couple of weeks already, so I’ll not get into the details. But I felt like adding a couple of comments to the subject:

• existing RDBMS storage engines are most of the time very well thought and long time tested
• some NoSQL databases have realized that and allow plugging in such storage engines in their systems:
  • Project Voldemort supports Berkley DB (and MySQL, but not sure it goes around the SQL engine)
  • [Riak comes with Innostore], an InnoDB-based storage
• many of the findings in this article sound very close to the rationale behind VoltDB, including the pre-compiled, cluster deployed stored procedures

Original title and link: Using MySQL as NoSQL: A Story for exceeding 750k qps (NoSQL databases © myNoSQL)

via: http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-for.html