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

21–30 of 39 posts

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

#21

Post by toddh »

jbooth wrote: post #19
toddh wrote: post #17

Earlier quoted context omitted.

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.

I guarantee he's not related in anyway. Did you read the whole thing? There are quite a few criticisms of it's operational model, limitations of SQL, limitations of using stored procedures only. What did you consider to be excessive sucking?

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

#22

Post by bad_user »

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…

The problem I have with this approach is that I don't know from the start what my needs are.

For example if I'm building a web app in my free time ... I'm starting with Mysql, and an ORM client like Django's, and I'm doing data-modelling that fits these tools.

Then if I would want to switch to MongoDB, if the need arises, I end up throwing away a lot of code / rewriting lots of logic. This means waisted hours and my free time for working on such stuff is very limited.

In lots of scenarios it's easier for me to just do sharding where I need it on top of MySql.

And that's what RDBMSs are good for ... they come with lots of crap you don't need, but that you may eventually which makes them fit most problems, unless you have extreme scalability needs, and even then you've got workarounds to turn to.

How do you know if / where you'll have scalability problems? And how do you know what to choose when you're doing exploratory programming?

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

#23

Post by nuxi »

jasongullickson wrote: post #12
dedward wrote: post #9

Earlier quoted context omitted.

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

I'm not sure that such a device exists.

HP is working on memristors - http://www.hpl.hp.com/news/2008/apr-jun/engineering_memristo.... According to wikipedia they already created such a prototype - http://en.wikipedia.org/wiki/Memristor#Potential_application....

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

#24

Post by mbreese »

bad_user wrote: post #22
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…

The problem I have with this approach is that I don't know from the start what my needs are. For example if I'm building a web app in my free time ... I'm starting with Mysql, and an ORM client like Django's, and I'm doing data-modelling that fits these tools. Then if I would want to switch to MongoDB, if the need arises, I end up throwing away a lot of code / rewriting lots of logic. This means waisted hours and my…

How do you know if / where you'll have scalability problems

You won't.

Just code it for the best model for your data. 95% of the time a RDBMS will work just fine for your data. If you have scaling issues down the road, chances are you'll be working on this full-time and will have the energy to devote to properly thinking about scaling. You aren't Google or Facebook (yet). Until you are, just work with what best fits your data or is fastest to code.

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

#26

Post by jhugg »

barredo wrote: post #5
kwyjibo wrote: post #2

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

So, it would be better if compared with MySQL's "MEMORY" storage engine?

While VoltDB's persistence story is perhaps bleeding edge (active replication with rolling snapshots as a double backup), MySQL MEMORY storage has none.

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

#27

Post by gaius »

barredo wrote: post #5
kwyjibo wrote: post #2

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

So, it would be better if compared with MySQL's "MEMORY" storage engine?

Hell, with SQLite's :memory: database (which can be persisted to disk using the Backup API).

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

#28

Post by jhugg »

rayval wrote: post #18
sgift wrote: post #4

Earlier quoted context omitted.

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.

I like this point. At VoltDB, we like to think we've removed a different set of features than many other scalable solutions, leaving a product that is useful for a set of problems that might not have a great option right now.

That said, VoltDB's architecture was built for in-memory and horizontal scaling from day 1. Based on hstore (http://hstore.cs.brown.edu/), it's not simply a removal of what's in existing systems.

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

#29

Post by alttab »

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…

I'm currently using MongoDB for my application

You might want to make sure you're not losing data. http://www.blue74.com/?p=25

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

#30

Post by jbooth »

toddh wrote: post #21
jbooth wrote: post #19

Earlier quoted context omitted.

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.

I guarantee he's not related in anyway. Did you read the whole thing? There are quite a few criticisms of it's operational model, limitations of SQL, limitations of using stored procedures only. What did you consider to be excessive sucking?

Yeah, it was mostly the first few grafs that came across as excessively googley-eyed. I guess some people would see that as grabbing the reader.
Post reply on HN