10 ms·

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

63 points by chuhnk 16y ago

kwyjibo 16y ago
Voltdb = memory only database, thus unfair comparision...
- Retric 16y ago
  RAM is cheap and 32+GB is a lot of data so for a wide range of real world workloads can fit the database in memory. (You can get a server with 96GB on a PowerEdge R710 for less than $6,066$ today if it's 20x faster than a traditional database you will save money.) The problem is MySQL etc doesn’t are not designed for this so while they become a lot faster they are still relatively slow. Also, RAM is only getting larger so once you make the transition to a RAM based DB you are unlikely to need to transition back. PS: I suspect most real world workloads revolve around small datasets that connect to big blobs of data. Think Users/Projects linking to Pictures, Documents, and Video etc. You don't edit documents in your database but you do want to track version information, users, permissions timestamps, approval etc. It's often a good idea to mix a Key Value style data store with a front end SQL database.
- jasongullickson 16y ago
  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?
  - dedward 16y ago
    What would that static ram device be, and how would you scale it out?
    - jasongullickson 16y ago
      I'm not sure that such a device exists.
      - nuxi 16y ago
        HP is working on memristors - http://www.hpl.hp.com/news/2008/apr-jun/engineering_memristor.html?jumpid=reg_R1002_USEN 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_applications http://en.wikipedia.org/wiki/Memristor#Potential_application....
        jasongullickson 16y ago
        I should have been more specific. I'm familiar with all sorts of non-volatile memory (flash, etc.) but I'm not aware of any modern computer that uses it as main memory (that is, directly addressable RAM as opposed to connected via a storage bus). I think the last thing I used that would qualify as such was the Apple Newton.
    - domnit 16y ago
      Phase-change memory.
- sgift 16y ago
  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?
  - JoachimSchipper 16y ago
    Not really, but do note that it is spectacularly faster.
  - rayval 16y ago
    * 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.
    - jhugg 16y ago
      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/ http://hstore.cs.brown.edu/), it's not simply a removal of what's in existing systems.
- barredo 16y ago
  So, it would be better if compared with MySQL's "MEMORY" storage engine?
  - jhugg 16y ago
    While VoltDB's persistence story is perhaps bleeding edge (active replication with rolling snapshots as a double backup), MySQL MEMORY storage has none.
  - gaius 16y ago
    Hell, with SQLite's :memory: database (which can be persisted to disk using the Backup API).
- drallison 16y ago
  RAM is the new disk. See http://www.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf http://www.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf does a nice job of looking at the practicality. See also the April 14, 2010 video at http://ee380.stanford.edu http://ee380.stanford.edu. The Stanford RAMCloud project page, http://fiz.stanford.edu:8081/display/ramcloud/Home http://fiz.stanford.edu:8081/display/ramcloud/Home, tracks recent activity in the area.
epochwolf 16y ago
- 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 block other transactions. I don't see how this is different than a NoSQL database. You cut a number of features (some critical to certain applications) from a relational database and get a bastardized version of a major database. It's a NoSQL database that uses a subset of the SQL standard and an enforced schema! I find these discussions extremely annoying. I'm currently using MongoDB for my application because: 1. I don't need join support 2. I prefer my current schema to be denormalized. 3. Documents store better than rows for my data. I could have used a relational database just fine. My data will fit with a little nudging. The point is, you use the technology that best fits your problem. My current problem fits well into MongoDB but it could be solved less nicely with a different database. All VoltDB is is another option if you have corners you can cut from the normal relational database model.
- mattmcknight 16y ago
  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/a96521/ds_txns.htm http://download.oracle.com/docs/cd/A97630_01/server.920/a965...
- Retric 16y ago
  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.
  - 16y ago
richcollins 16y ago
Changing the database schema or reconfiguring the cluster hardware requires first saving and shutting down the database This is where it fails when compared to many NoSQL solutions.
- jhugg 16y ago
  This isn't a permanent problem. Working on it...
ericflo 16y ago
Ridiculously sensationalist
- toddh 16y ago
  In what way?
  - jbooth 16y ago
    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.
    - toddh 16y ago
      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?
      - jbooth 16y ago
        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.
        toddh 16y ago
        Definitely. If you don't grab you may as well not write. And it wasn't googley-eyed as much as it was laying out what they claim to see how it held up later.
silentbicycle 16y ago
At a glance: This sounds like kbd+ (http://kx.com/Products/kdb+.php http://kx.com/Products/kdb+.php), but open source, and with Java as a query language instead of K/Q. Edit: Thanks for the clarification.
- aweisberg 16y ago
  kbd+ is a column store (analytic database) and does not partition horizontally. The two things they have in common is that they are both in memory (and kdb+ not necessarily) and support SQL as a query language (kdb+ only supports SQL like stuff). kbd+ does not emphasize stored procedures as a means of bringing multiple queries and arbitrary logic to the data. Nor does it need to since it doesn't partition.
jmulho 16y ago
The article links to a presentation by one of the authors of VoltDB. On slide 17 he makes the crucial point that overhead (latching, locking, recovery, and buffer pool) makes up 88% of the work that a typical RDBMS must do. Useful work (doing your SQL) accounts for only 12%. Attempting to gain speed by optimizing the useful work (sorting, joining, indexes) is thus pointless. Doing the database in memory (getting rid of buffer pool) is a good way to gain speed, but it can only hope to be two times faster (because the other 3 types of overhead remain). The only way to get really fast is to address all four types of overhead, which is what VoltDB attempts to do. Point taken. However, the author needs to work his pie chart skills. The 12% useful work on slide 17 is displayed as a tiny sliver (more like 3%) of the pie. This hinted to me that the whole presentation is a bit of an exaggeration.
- jhugg 16y ago
  The pie chart is based on this paper: http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.pdf http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.... The pie chart numbers have been updated to reflect the right charts in the paper, but the graphic hasn't. We'll try to get that fixed for future presentations. The point is very real. Stavros, Dan, Sam and Mike took the Shore RDBMS and stuck it on top of memory. Then they removed parts of it and measured the performance difference. Logging, buffer management, and concurrency management make up about 93% of the instructions run and 88% of the cycles for TPC-C "new order". There was no single area that dominated this overhead, so removing one piece doesn't make enough of a difference. Results on Oracle, SQL Severer and DB2 might be different, but it's hard to imagine they'd be dramatically different. Because VoltDB was built without these sources of overhead, it's usually quite a bit faster than systems that take legacy RDBMSs and back them with memory. VoltDB has limitations (especially in 1.0), but if your workload fits, it will go as fast as you need it to.

63 points by chuhnk 16y ago

kwyjibo 16y ago

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

Retric 16y ago
RAM is cheap and 32+GB is a lot of data so for a wide range of real world workloads can fit the database in memory. (You can get a server with 96GB on a PowerEdge R710 for less than $6,066$ today if it's 20x faster than a traditional database you will save money.) The problem is MySQL etc doesn’t are not designed for this so while they become a lot faster they are still relatively slow. Also, RAM is only getting larger so once you make the transition to a RAM based DB you are unlikely to need to transition back. PS: I suspect most real world workloads revolve around small datasets that connect to big blobs of data. Think Users/Projects linking to Pictures, Documents, and Video etc. You don't edit documents in your database but you do want to track version information, users, permissions timestamps, approval etc. It's often a good idea to mix a Key Value style data store with a front end SQL database.
jasongullickson 16y ago
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?
- dedward 16y ago
  What would that static ram device be, and how would you scale it out?
  - jasongullickson 16y ago
    I'm not sure that such a device exists.
    - nuxi 16y ago
      HP is working on memristors - http://www.hpl.hp.com/news/2008/apr-jun/engineering_memristor.html?jumpid=reg_R1002_USEN 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_applications http://en.wikipedia.org/wiki/Memristor#Potential_application....
      - jasongullickson 16y ago
        I should have been more specific. I'm familiar with all sorts of non-volatile memory (flash, etc.) but I'm not aware of any modern computer that uses it as main memory (that is, directly addressable RAM as opposed to connected via a storage bus). I think the last thing I used that would qualify as such was the Apple Newton.
  - domnit 16y ago
    Phase-change memory.
sgift 16y ago
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?
- JoachimSchipper 16y ago
  Not really, but do note that it is spectacularly faster.
- rayval 16y ago
  * 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.
  - jhugg 16y ago
    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/ http://hstore.cs.brown.edu/), it's not simply a removal of what's in existing systems.
barredo 16y ago
So, it would be better if compared with MySQL's "MEMORY" storage engine?
- jhugg 16y ago
  While VoltDB's persistence story is perhaps bleeding edge (active replication with rolling snapshots as a double backup), MySQL MEMORY storage has none.
- gaius 16y ago
  Hell, with SQLite's :memory: database (which can be persisted to disk using the Backup API).
drallison 16y ago
RAM is the new disk. See http://www.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf http://www.stanford.edu/~ouster/cgi-bin/papers/ramcloud.pdf does a nice job of looking at the practicality. See also the April 14, 2010 video at http://ee380.stanford.edu http://ee380.stanford.edu. The Stanford RAMCloud project page, http://fiz.stanford.edu:8081/display/ramcloud/Home http://fiz.stanford.edu:8081/display/ramcloud/Home, tracks recent activity in the area.

epochwolf 16y ago

- 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 block other transactions. I don't see how this is different than a NoSQL database. You cut a number of features (some critical to certain applications) from a relational database and get a bastardized version of a major database. It's a NoSQL database that uses a subset of the SQL standard and an enforced schema! I find these discussions extremely annoying. I'm currently using MongoDB for my application because: 1. I don't need join support 2. I prefer my current schema to be denormalized. 3. Documents store better than rows for my data. I could have used a relational database just fine. My data will fit with a little nudging. The point is, you use the technology that best fits your problem. My current problem fits well into MongoDB but it could be solved less nicely with a different database. All VoltDB is is another option if you have corners you can cut from the normal relational database model.

mattmcknight 16y ago
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/a96521/ds_txns.htm http://download.oracle.com/docs/cd/A97630_01/server.920/a965...
Retric 16y ago
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.
- 16y ago

richcollins 16y ago

Changing the database schema or reconfiguring the cluster hardware requires first saving and shutting down the database This is where it fails when compared to many NoSQL solutions.

jhugg 16y ago
This isn't a permanent problem. Working on it...

ericflo 16y ago

Ridiculously sensationalist

toddh 16y ago
In what way?
- jbooth 16y ago
  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.
  - toddh 16y ago
    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?
    - jbooth 16y ago
      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.
      - toddh 16y ago
        Definitely. If you don't grab you may as well not write. And it wasn't googley-eyed as much as it was laying out what they claim to see how it held up later.

silentbicycle 16y ago

At a glance: This sounds like kbd+ (http://kx.com/Products/kdb+.php http://kx.com/Products/kdb+.php), but open source, and with Java as a query language instead of K/Q. Edit: Thanks for the clarification.

aweisberg 16y ago
kbd+ is a column store (analytic database) and does not partition horizontally. The two things they have in common is that they are both in memory (and kdb+ not necessarily) and support SQL as a query language (kdb+ only supports SQL like stuff). kbd+ does not emphasize stored procedures as a means of bringing multiple queries and arbitrary logic to the data. Nor does it need to since it doesn't partition.

jmulho 16y ago

The article links to a presentation by one of the authors of VoltDB. On slide 17 he makes the crucial point that overhead (latching, locking, recovery, and buffer pool) makes up 88% of the work that a typical RDBMS must do. Useful work (doing your SQL) accounts for only 12%. Attempting to gain speed by optimizing the useful work (sorting, joining, indexes) is thus pointless. Doing the database in memory (getting rid of buffer pool) is a good way to gain speed, but it can only hope to be two times faster (because the other 3 types of overhead remain). The only way to get really fast is to address all four types of overhead, which is what VoltDB attempts to do. Point taken. However, the author needs to work his pie chart skills. The 12% useful work on slide 17 is displayed as a tiny sliver (more like 3%) of the pie. This hinted to me that the whole presentation is a bit of an exaggeration.

jhugg 16y ago
The pie chart is based on this paper: http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.pdf http://cs-www.cs.yale.edu/homes/dna/papers/oltpperf-sigmod08.... The pie chart numbers have been updated to reflect the right charts in the paper, but the graphic hasn't. We'll try to get that fixed for future presentations. The point is very real. Stavros, Dan, Sam and Mike took the Shore RDBMS and stuck it on top of memory. Then they removed parts of it and measured the performance difference. Logging, buffer management, and concurrency management make up about 93% of the instructions run and 88% of the cycles for TPC-C "new order". There was no single area that dominated this overhead, so removing one piece doesn't make enough of a difference. Results on Oracle, SQL Severer and DB2 might be different, but it's hard to imagine they'd be dramatically different. Because VoltDB was built without these sources of overhead, it's usually quite a bit faster than systems that take legacy RDBMSs and back them with memory. VoltDB has limitations (especially in 1.0), but if your workload fits, it will go as fast as you need it to.