
VoltDB. Speed = 100x  MySQL & 13x  Cassandra & 45x  Oracle - chuhnk
http://highscalability.com/blog/2010/6/28/voltdb-decapitates-six-sql-urban-myths-and-delivers-internet.html
======
epochwolf
\- VoltDB stores all its data in RAM

\- Run transactions to completion –single threaded –in timestamp order [will
use multiple cores, with each having a single thread]

\- Only data changed within a single invocation of a stored procedure is in a
transaction, transactions can't span multiple rounds of communication with a
client.

\- You are also discouraged from doing SUM operations because it would take a
long time and block other transactions.

I don't see how this is different than a NoSQL database. You cut a number of
features (some critical to certain applications) from a relational database
and get a bastardized version of a major database. It's a NoSQL database that
uses a subset of the SQL standard and an enforced schema!

I find these discussions extremely annoying. I'm currently using MongoDB for
my application because:

1\. I don't need join support

2\. I prefer my current schema to be denormalized.

3\. Documents store better than rows for my data.

I could have used a relational database just fine. My data will fit with a
little nudging.

The point is, you use the technology that best fits your problem. My current
problem fits well into MongoDB but it could be solved less nicely with a
different database.

All VoltDB is is another option if you have corners you can cut from the
normal relational database model.

~~~
Retric
FYI: Relational databases don't require transactions of any kind. SQL92 does
require transactions; however it's not required to support multiple rounds of
communication with the client.

Suggesting there is no difference between a Key Value store and an SQL
database capable of ad hock queries, Transactions, and Joins is ridiculous.

~~~
epochwolf
> Suggesting there is no difference between a Key Value store and an SQL
> database capable of ad hock queries, Transactions, and Joins is ridiculous.

My intent was to make the claim that VoltDB is a feature subset of a
relational database and is overhyped in the same lines that many NoSQL servers
are. It's just a different subset of features than the key/value store
servers.

My point boils down to _VoltDB is merely another option if you have corners
you can cut from the normal relational database model._

I probably could have been more clear in stating that. Bringing mongodb into
the discussion muddied things.

~~~
Retric
I get where you are coming from, however if your application is already using
SQL then the transition to a more limited but faster database is a lot simpler
than going to NoSQL.

Also one of the simple hacks to increase speed is to have a smaller working
set database on a separate system to handle more recent items. Because it's
under a much higher load the "live" database tends to have really simple usage
pattern also due to its smaller size it tends to fit into RAM. And, the “Live”
DB tends to have different optimizations (EX: Fewer indexes because you have
more writes). Based on this a "striped down" but still SQL database seems like
a perfect fit.

PS: It's a lot like Memcached, something that can speed up your application
with minimal development time is worth a lot.

------
kwyjibo
Voltdb = memory only database, thus unfair comparision...

~~~
barredo
So, it would be better if compared with MySQL's "MEMORY" storage engine?

~~~
gaius
Hell, with SQLite's :memory: database (which can be persisted to disk using
the Backup API).

------
richcollins
_Changing the database schema or reconfiguring the cluster hardware requires
first saving and shutting down the database_

This is where it fails when compared to many NoSQL solutions.

~~~
jhugg
This isn't a permanent problem. Working on it...

------
jmulho
The article links to a presentation by one of the authors of VoltDB. On slide
17 he makes the crucial point that overhead (latching, locking, recovery, and
buffer pool) makes up 88% of the work that a typical RDBMS must do. Useful
work (doing your SQL) accounts for only 12%. Attempting to gain speed by
optimizing the useful work (sorting, joining, indexes) is thus pointless.
Doing the database in memory (getting rid of buffer pool) is a good way to
gain speed, but it can only hope to be two times faster (because the other 3
types of overhead remain). The only way to get really fast is to address all
four types of overhead, which is what VoltDB attempts to do. Point taken.
However, the author needs to work his pie chart skills. The 12% useful work on
slide 17 is displayed as a tiny sliver (more like 3%) of the pie. This hinted
to me that the whole presentation is a bit of an exaggeration.

~~~
jhugg
The pie chart is based on this paper: [http://cs-
www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08...](http://cs-
www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.pdf). The pie chart numbers
have been updated to reflect the right charts in the paper, but the graphic
hasn't. We'll try to get that fixed for future presentations.

The point is very real. Stavros, Dan, Sam and Mike took the Shore RDBMS and
stuck it on top of memory. Then they removed parts of it and measured the
performance difference. Logging, buffer management, and concurrency management
make up about 93% of the instructions run and 88% of the cycles for TPC-C "new
order". There was no single area that dominated this overhead, so removing one
piece doesn't make enough of a difference. Results on Oracle, SQL Severer and
DB2 might be different, but it's hard to imagine they'd be dramatically
different.

Because VoltDB was built without these sources of overhead, it's usually quite
a bit faster than systems that take legacy RDBMSs and back them with memory.

VoltDB has limitations (especially in 1.0), but if your workload fits, it will
go as fast as you need it to.

------
silentbicycle
At a glance: This sounds like kbd+ (<http://kx.com/Products/kdb+.php>), but
open source, and with Java as a query language instead of K/Q.

Edit: Thanks for the clarification.

~~~
aweisberg
kbd+ is a column store (analytic database) and does not partition
horizontally. The two things they have in common is that they are both in
memory (and kdb+ not necessarily) and support SQL as a query language (kdb+
only supports SQL like stuff). kbd+ does not emphasize stored procedures as a
means of bringing multiple queries and arbitrary logic to the data. Nor does
it need to since it doesn't partition.

------
ericflo
Ridiculously sensationalist

~~~
toddh
In what way?

~~~
jbooth
The whole way the thing's written. I hope the blog author is the voltDB guy's
uncle or publicist or something because otherwise that is one heck of a man
crush to hype this up that much.

Not taking anything away from voltDB - haven't seen it, will try to see it,
and encourage people to pursue stuff like that in general. But the article
read like football announcers talking about Brett Favre.

~~~
toddh
I guarantee he's not related in anyway. Did you read the whole thing? There
are quite a few criticisms of it's operational model, limitations of SQL,
limitations of using stored procedures only. What did you consider to be
excessive sucking?

~~~
jbooth
Yeah, it was mostly the first few grafs that came across as excessively
googley-eyed. I guess some people would see that as grabbing the reader.

~~~
toddh
Definitely. If you don't grab you may as well not write. And it wasn't
googley-eyed as much as it was laying out what they claim to see how it held
up later.

