Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

VoltDB is out, benchmarks against Cassandra

voltdb.com

Post reply on HN
Print view View original

21–30 of 46 posts

Re: VoltDB is out, benchmarks against Cassandra

#21

Post by jbellis »

cx01 wrote: post #8
pquerna wrote: 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.

In-memory doesn't imply "unreliable". If you need high-availability you'll want to use replication anyway.

In-memory with periodic snapshots sure implies "not durable," though. (That is, you will lose whatever data has not yet been snapshotted on a power failure or crash.) Replication doesn't fix that, unless you're willing to impose the latency of replication to different datacenters for each update. (I don't think Volt even supports this. Most systems don't.)

Re: VoltDB is out, benchmarks against Cassandra

#22

Post by [deleted] »

cx01 wrote: post #16
jefffoster wrote: post #15

Earlier quoted context omitted.

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.

[deleted]

Re: VoltDB is out, benchmarks against Cassandra

#23

Post by ergo98 »

tlack wrote: post #20
ergo98 wrote: post #19

Earlier quoted context omitted.

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

>You can't compare memory-only db performance against a disk based db, period.

But...you can. What do you mean you can't compare? Clearly you can, however mortified you might be at that prospect.

A reasonable motorcycle can go from 0-60 in about 4 seconds. A reasonable car can do it in about 9 seconds. But you need to carry two passengers so the car is your only option, and such a comparison doesn't matter to you, but to a lot of people it's interesting if ultimately they just want to get from A to B as quickly as possibly. Then again if you want to transport goods maybe you need a truck, or a train.

This is so silly. Wait -- hand wavy -- that's right, nothing can be compared to Cassandra but pure love itself.

Re: VoltDB is out, benchmarks against Cassandra

#24

Post by aquark »

seldo wrote: 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.

Isn't the D in ACID for 'durable'? The blog post implies that this is an in memory store only ... I feel I must be missing something.

Re: VoltDB is out, benchmarks against Cassandra

#25

Post by aquark »

pquerna wrote: 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 anyone suggest problem domains where it is useful to have the ability to do 100K writes per second, but not have durable transactions?

I can see the in memory story for read only queries, or transient data.

Re: VoltDB is out, benchmarks against Cassandra

#26

Post by beagle3 »

kemiller wrote: post #18
seldo wrote: 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.

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.

Re: VoltDB is out, benchmarks against Cassandra

#27

Post by cx01 »

jbellis wrote: post #21
cx01 wrote: post #8

Earlier quoted context omitted.

In-memory doesn't imply "unreliable". If you need high-availability you'll want to use replication anyway.

In-memory with periodic snapshots sure implies "not durable," though. (That is, you will lose whatever data has not yet been snapshotted on a power failure or crash.) Replication doesn't fix that, unless you're willing to impose the latency of replication to different datacenters for each update. (I don't think Volt even supports this. Most systems don't.)

Why? If a single node fails, you still have the data on 2 other nodes. Nothing is lost. Of course, assuming you have a reliable UPS.

Re: VoltDB is out, benchmarks against Cassandra

#28

Post by cx01 »

aquark wrote: post #25
pquerna wrote: 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 anyone suggest problem domains where it is useful to have the ability to do 100K writes per second, but not have durable transactions? I can see the in memory story for read only queries, or transient data.

Transactions ARE durable if you use replication.

Re: VoltDB is out, benchmarks against Cassandra

#29

Post by KERMIT »

aquark wrote: post #24
seldo wrote: 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.

Isn't the D in ACID for 'durable'? The blog post implies that this is an in memory store only ... I feel I must be missing something.

"Durability" in that sense has nothing to do with how the data is stored, or how long it's available for.

It simply means that after a transaction has been reported as having been committed successfully, it won't ever be rolled back.

Re: VoltDB is out, benchmarks against Cassandra

#30

Post by KERMIT »

seldo wrote: 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.

It makes sense why he's saying that. The people responsible for large, important data sets usually have lots of money to spend storing that data. Since they care about their data, they know better than to get involved with NoSQL databases, and actively shun anything that claims to be a NoSQL database. The real money will flow towards those providing real databases.
Post reply on HN