

VoltDB is out, benchmarks against Cassandra - nprincigalli
http://www.voltdb.com/blog/key-value-benchmarking

======
banjiewen
This reads like marketing-blogspam to me. These two projects solve totally
different problems, and the author acknowledges it, yet he still goes on to
highlight benchmarks where VoltDB is 10-20x faster than Cassandra. Of course
it's going to be! It's an in-memory store!

So why benchmark against Cassandra? It's got a lot of buzz around it, of
course. What a better way to shove your name into the "NoSQL" ring. Blech.

With regard to the numbers themselves, I would refer the author to the CouchDB
boys' discussion of benchmarks (under "Good Benchmarks are Non-Trivial"):
<http://books.couchdb.org/relax/reference/high-performance>

~~~
jefffoster
From their white-paper apparently DBMS systems spend 35% of their time doing
buffer management, 17% doing logging, another 19% doing latching and finally
21% doing locking. This leaves only 7% for "useful work". In comparison,
VoltDB has 95% capacity for useful work.

Reads even more like marketing blogspam!

~~~
cx01
Why do you think it is blogspam? You can also read the H-Store papers if
you're interested in the details.

------
pquerna
in memory vs not, will always have these kinds of results.

most people, most systems, aren't so hot about in memory datastores -- MySQL
had MySQL-Cluster/NDB, and for lots of reasons it had trouble ever taking off.

For certain use cases, and definitely for benchmarking purposes, in memory
datastores will always crush the competitors, but in the end, most people like
reliable data storage.

~~~
jbellis
Most use cases also don't have the entire data set equally active, and it's
silly to pay to keep everything in RAM instead of just the hot parts.

~~~
hdiedrich
That's part of the proposal: real world data requirements will soon completely
fit into RAM available on a rather standard system.

------
seldo
I'm at Gluecon, where Mike Stonebraker (CTO of VoltDB) gave a talk about Volt
this morning. He's very clear that VoltDB is not a NoSQL product; it's a SQL
product, but a next-generation SQL product. He says they've achieved enormous
performance gains by keeping ACID compliance by throwing out tons of older
tech still present in MySQL and Oracle.

~~~
kemiller
What sorts of older things did they throw out? And is there not even eventual
persistence with VoltDB? Is there a recovery log or some such? Otherwise it
seems like serious power event and you're toast.

~~~
beagle3
Well, a quick read of their white paper makes it look like they just copied
the kdb design (<http://cs.nyu.edu/shasha/papers/hpts.pdf> \- which they
actually reference in one of their papers).

But perhaps they did something new as well?

edit: citeseer link was broken; replaced with link to shasha's website.

------
bradfordw
If he wanted something a bit closer to the voltdb model, why not go with mongo
since your writes aren't immediately put to disk? It's more of a measure of
how quickly you're shuttling data over the wire.

When you agree that it's apples to oranges, why continue?

~~~
codavid
My understanding is that mongodb is not durable
([http://ivoras.sharanet.org/blog/tree/2010-02-20.mongodb-
and-...](http://ivoras.sharanet.org/blog/tree/2010-02-20.mongodb-and-
durability.html)) - I am not sure I understand how VoltDB is durable, though
(but then I know nothing about db architecture).

------
aditya
This is cool, eventually we'll have every no-sql use case covered, so there
exists a data store which conforms to your applications usage with respect to
the CAP theorem...

------
riffraff
code and configurations or it didn't happen

------
codahale
I see absolutely zero details about the actual configurations of either
system. No replicability means it's just another opinion paper.

------
zipstudio
I wonder if this DB will be available from any clouds?

