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

VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

highscalability.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

#11

Post by mattmcknight »

epochwolf wrote: post #8

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

For many of my use cases, the distributed transaction control is the key feature of any database product. The reason there are so many products out there with simple transaction models is that it is not that hard to write one.

It is really hard to do the distributed transaction thing [1] in a horizontally scalable fashion.

[1] http://download.oracle.com/docs/cd/A97630_01/server.920/a965...

Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

#12

Post by jasongullickson »

dedward wrote: post #9
jasongullickson wrote: post #3

Earlier quoted context omitted.

I think this could be a worthwhile comparison if tested on a platform where the in-memory store is as safe as traditional hard-disk storage, say a machine with some form of static (non-volatile) RAM for main memory. Thus the question would be, does the performance advantage of VoltDB's approach outweigh the penalty of static RAM performance?

What would that static ram device be, and how would you scale it out?

I'm not sure that such a device exists.

Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

#13

Post by JoachimSchipper »

sgift wrote: post #4
kwyjibo wrote: post #2

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

Even if it is fair I only get two points from this article (and their product page): * A system which holds all data in memory is faster than a system which uses memory and disks. True, but not really news. * If you leave out features your implementation can be faster (e.g. they only support transactions which span a single stored procedure). Again .. no news here. Something else I've missed?

Not really, but do note that it is spectacularly faster.

Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

#14

Post by domnit »

dedward wrote: post #9
jasongullickson wrote: post #3

Earlier quoted context omitted.

I think this could be a worthwhile comparison if tested on a platform where the in-memory store is as safe as traditional hard-disk storage, say a machine with some form of static (non-volatile) RAM for main memory. Thus the question would be, does the performance advantage of VoltDB's approach outweigh the penalty of static RAM performance?

What would that static ram device be, and how would you scale it out?

Phase-change memory.

Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

#15

Post by Retric »

epochwolf wrote: post #8

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

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.

Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

#18

Post by rayval »

sgift wrote: post #4
kwyjibo wrote: post #2

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

Even if it is fair I only get two points from this article (and their product page): * A system which holds all data in memory is faster than a system which uses memory and disks. True, but not really news. * If you leave out features your implementation can be faster (e.g. they only support transactions which span a single stored procedure). Again .. no news here. Something else I've missed?

* A system that is designed for mostly disk will run faster when run in memory, but won't be as fast as one designed from the outset for in-memory operation.

* Leaving out features is harder than adding features, because you have to judiciously decide which ones to leave out. A large bushel o' features can have many different subsets, and only some of these subsets are worthwhile.

Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

#19

Post by jbooth »

toddh wrote: post #17
ericflo wrote: post #16

Ridiculously sensationalist

In what way?

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.

Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle

#20

Post by jbooth »

epochwolf wrote: post #8

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

Well, the one-thread-per-region thing is an interesting way of sidestepping locks. So I'll give them that.

But it's basically memcached with an SQL parser and some hand wavey stuff about how since it's replicated, the data never needs to make it to disk. That one doesn't sit well with me for some reason, even if it's theoretically true.

Post reply on HN