Live data from Hacker News

VoltDB is out, benchmarks against Cassandra

voltdb.com

31–40 of 46 posts

Re: VoltDB is out, benchmarks against Cassandra

#31
post #21
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.)

So if your entire data center loses power... If you have any notice (local UPS, etc), you snapshot to disk. If you have no notice, you lose some number of transactions depending on your data size, snapshot frequency and disk speed. Seconds or minutes, but probably not hours.

Future versions of VoltDB will do more address this single-data-center catastrophe scenario.

Re: VoltDB is out, benchmarks against Cassandra

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

It's consistent, not only eventual consistent, it's k-safe, replicated and it's written to disk consistently at intervals you set. http://community.voltdb.com/node/54 (may require login). It's really pretty neat.

Re: VoltDB is out, benchmarks against Cassandra

#33

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?

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

Re: VoltDB is out, benchmarks against Cassandra

#34
post #7
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.

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.

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

Re: VoltDB is out, benchmarks against Cassandra

#35
post #27
post #21

Earlier quoted context omitted.

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.

Because the data may not have replicated to the other nodes yet. As the parent comment noted, you could synchronously write to all replica nodes, but thats a big performance penalty and not partition tolerant.

Re: VoltDB is out, benchmarks against Cassandra

#36
post #23
post #20

Earlier quoted context omitted.

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 , b…

I don't think it's hand-wavy. I think you're upset about something else related to Cassandra that perhaps you read recently -- not tlack's comment. Suggesting it would make more sense to compare an in-memory data store to another in-memory data store would be a more interesting comparison seems a perfectly valid suggestion.

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

C'mon, man. That doesn't further discussion. That sort of statement serves only to incite anger.

Re: VoltDB is out, benchmarks against Cassandra

#37
post #36
post #23

Earlier quoted context omitted.

>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 , b…

I don't think it's hand-wavy. I think you're upset about something else related to Cassandra that perhaps you read recently -- not tlack's comment. Suggesting it would make more sense to compare an in-memory data store to another in-memory data store would be a more interesting comparison seems a perfectly valid suggestion. "This is so silly. Wait -- hand wavy -- that's right, nothing can be compared to Cassandra but…

> I think you're upset about something else related to Cassandra that perhaps you read recently

Huh? No, I love Cassandra. She's a beaut.

tlack didn't say "it would make more sense to compare an in-memory data store to another in-memory data store". They said "You can't compare memory-only db performance against a disk based db, period.". There's a pretty profound difference between those two statements.

Re: VoltDB is out, benchmarks against Cassandra

#38
post #35
post #27

Earlier quoted context omitted.

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.

Because the data may not have replicated to the other nodes yet. As the parent comment noted, you could synchronously write to all replica nodes, but thats a big performance penalty and not partition tolerant.

They pay the penalty in latency, not in throughput. That's like no performance penalty at all if you work asynchronously. They make sure that the data cannot become inconsistent between nodes by ordering the transactions. The penalty that comes from this is that latency can become high, i.e. the answer time for individual transactions. While maintaining a maximized throughput of millions of transactions a second. It's like an internal 'pumping rhythm' with tightly synched timestamps.

Re: VoltDB is out, benchmarks against Cassandra

#39
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…

Why not compare it to Redis instead? They are both in-memory snapshotting stores, sure Redis does less but it is still a closer solution. But, Redis would probably be faster.

Re: VoltDB is out, benchmarks against Cassandra

#40

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?

MongoDB partitioning support is still under development. Probably more apple to oranges then VoltDB vs. Cassandra.
Post reply on HN