Live data from Hacker News

VoltDB is out, benchmarks against Cassandra

voltdb.com

11–20 of 46 posts

Re: VoltDB is out, benchmarks against Cassandra

#11

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. W…

"Cassandra writes to disk. VoltDB is an in-memory database. So I gave both systems plenty of RAM to hold the data set and turned Cassandra's consistency settings pretty low." So in memory in both cases. Cassandra has to write a log, but not synchronously.

I think Cassandra always writes to the Commit Log before returning success, it just doesn't update the SStables yet:

> Commit logs receive every write made to a Cassandra node and have the potential to block client operations [1]

I'm no expert so it may be possible to turn this off but I couldn't find reference to it.

[1] http://wiki.apache.org/cassandra/CassandraHardware

Re: VoltDB is out, benchmarks against Cassandra

#12
post #11

Earlier quoted context omitted.

"Cassandra writes to disk. VoltDB is an in-memory database. So I gave both systems plenty of RAM to hold the data set and turned Cassandra's consistency settings pretty low." So in memory in both cases. Cassandra has to write a log, but not synchronously.

I think Cassandra always writes to the Commit Log before returning success, it just doesn't update the SStables yet: > Commit logs receive every write made to a Cassandra node and have the potential to block client operations [1] I'm no expert so it may be possible to turn this off but I couldn't find reference to it. [1] http://wiki.apache.org/cassandra/CassandraHardware

http://wiki.apache.org/cassandra/Durability

"Cassandra's example configuration shows CommitLogSync set to periodic, meaning that we sync the commitlog every CommitLogSyncPeriodInMS ms, so you can potentially lose up to that much data in a crash ... You can also select "batch" mode, where Cassandra will guarantee that it syncs before acknowledging writes, i.e., fully durable mode"

Cassandra has very fine grained control over just about everything to do with consistency and durability. I believe you can pick your desired level of consistency at access time.

Re: VoltDB is out, benchmarks against Cassandra

#13
post #11

Earlier quoted context omitted.

"Cassandra writes to disk. VoltDB is an in-memory database. So I gave both systems plenty of RAM to hold the data set and turned Cassandra's consistency settings pretty low." So in memory in both cases. Cassandra has to write a log, but not synchronously.

I think Cassandra always writes to the Commit Log before returning success, it just doesn't update the SStables yet: > Commit logs receive every write made to a Cassandra node and have the potential to block client operations [1] I'm no expert so it may be possible to turn this off but I couldn't find reference to it. [1] http://wiki.apache.org/cassandra/CassandraHardware

I think Cassandra always writes to the Commit Log before returning success

Sure, but the write is not the significant part (it is likely to be cached in memory); the question is how often the commit log is sync'ed to disk. I'm no Cassandra expert, but I believe the default is to fsync() the commit log periodically, but to allow operations to return successfully before an fsync() has occurred. There's also a mode to require fsync() before returning success for an operation.

http://wiki.apache.org/cassandra/Durability

Re: VoltDB is out, benchmarks against Cassandra

#15

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. W…

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!

Re: VoltDB is out, benchmarks against Cassandra

#16

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. W…

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!

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

Re: VoltDB is out, benchmarks against Cassandra

#17
post #6

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.

can you elaborate more on those reasons? (just asking)

Re: VoltDB is out, benchmarks against Cassandra

#18
post #5

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.

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.

Re: VoltDB is out, benchmarks against Cassandra

#19

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. W…

>These two projects solve totally different problems

No they don't. This is the wavy-hands NoSQL defensive shield that reeks of insincerity. If you show Cassandra or Redis or some other solution replacing a MySQL install, well that's just awesome, but don't dare compare if it doesn't come out the winner.

A lot of people have workloads that could work in VoltDB, a classic RDBMS, or Cassandra, equally. There are workloads that only fit in specific silos, but they are less universal than you imply.

>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.

Okay this is just silly. Cassandra is the big name in the "next gen database" world -- of COURSE any new entrant is going to compare against it.

Re: VoltDB is out, benchmarks against Cassandra

#20
post #19

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. W…

>These two projects solve totally different problems No they don't. This is the wavy-hands NoSQL defensive shield that reeks of insincerity. If you show Cassandra or Redis or some other solution replacing a MySQL install, well that's just awesome, but don't dare compare if it doesn't come out the winner. A lot of people have workloads that could work in VoltDB, a classic RDBMS, or Cassandra, equally. There are worklo…

That's like benchmarking Berkeley DB vs. MySQL. They are on totally different levels of complexity. You can't compare memory-only db performance against a disk based db, period.
Post reply on HN