Andrew Brust for ZDNet:

In the software world, many people believe that products reach true maturity and value in their third version. A first release is about bringing an idea to market, and second releases act to stabilize the first. But it’s “v3” that really incorporates refinements that reflect user feedback and market lessons learned. It seems to me that “NewSQL” database player VoltDB is following that pattern with its own 3.0 release.

There’re no such things as a proverbial version 3.0, nor a pattern about the meaning of version 3. Anyways, congrats to the VoltDB guys!

If you want to know what’s in VoltDB 3.0, ignore the linked post and go read Introducing VoltDB 3.0 on VoltDB blog. Short version: more performance, improved SQL support, support for JSON-encoded data and defining indexes for JSON columns.

Original title and link: VoltDB Hits Proverbial Version 3.0 (NoSQL database©myNoSQL)

via: http://www.zdnet.com/voltdb-hits-proverbial-version-3-0-7000010099/

There are two Java clients for VoltDB. One is a standard JDBC driver that executes all queries synchronously. The other is a specialized client library that can run queries either synchronously or asynchronously, along with a number of other features. Synchronous queries perform well enough but their throughput is no match for asynchronous queries. Asynchronous query throughput is approximately four times greater than synchronous queries in a two node VoltDB cluster. For example, an application using asynchronous queries can run over 200K TPS (transactions per second) in a two node server cluster using a single client running on a Macbook Pro; a synchronous client running the same queries will achieve around 56K TPS.

Could anyone explain what leads to such a difference in performance?

Original title and link: Integrating VoltDB With the Spring Framework (NoSQL database©myNoSQL)

via: http://voltdb.com/company/blog/integrating-voltdb-spring-framework

These are the assumptions under which VoltDB was architected:

First, it should be noted that main memory is getting very cheap.  It is straightforward to put 50 Gbytes of memory on a $5,000 server.  Beefy servers these days have 10 times that amount. Moreover, many (but not all) transactional databases don’t require massive storage volumes. An OLTP application with more than a few Tbytes of data is quite rare.  The same can be said for new OLTP “fire hose” applications that require ultra-high write throughput and ACID transactions (e.g., digital advertising, wireless, real-time monitoring) — these systems rarely need to manage more than a few Tbytes of hot state.  Hence, it is plausible to buy enough main memory to store the data for the vast majority of OLTP applications. 

Original title and link: VoltDB Assumptions: Memory vs Disk (NoSQL database©myNoSQL)

via: http://voltdb.com/company/blog/use-main-memory-oltp

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