At a glance: This sounds like kbd+ (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.
VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
31–39 of 39 posts
Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
#32At a glance: This sounds like kbd+ ( 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.
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.
Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
#33- 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
See: http://news.ycombinator.com/item?id=1452636
The author's last comment was:
> Hey Mike, I'll get in contact with you shortly once I pull some logs. We've been analyzing the data and it seems that where we lose data coincides with some system reboots, we had a few problems with replication a few weeks ago, and had it disabled, so that's likely why we are seeing loss.
Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
#34- 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.
> Suggesting there is no difference between a Key Value store and an SQL database capable of ad hock queries, Transactions, and Joins is ridiculous.
My intent was to make the claim that VoltDB is a feature subset of a relational database and is overhyped in the same lines that many NoSQL servers are. It's just a different subset of features than the key/value store servers.
My point boils down to VoltDB is merely another option if you have corners you can cut from the normal relational database model.
I probably could have been more clear in stating that. Bringing mongodb into the discussion muddied things.
Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
#35Earlier quoted context omitted.
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.
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.
Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
#36The 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.
Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
#37The 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…
The pie chart is based on this paper: 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.
Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
#38Earlier quoted context omitted.
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... .
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.
Re: VoltDB. Speed = 100x MySQL & 13x Cassandra & 45x Oracle
#39Earlier quoted context omitted.
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.
> Suggesting there is no difference between a Key Value store and an SQL database capable of ad hock queries, Transactions, and Joins is ridiculous. My intent was to make the claim that VoltDB is a feature subset of a relational database and is overhyped in the same lines that many NoSQL servers are. It's just a different subset of features than the key/value store servers. My point boils down to VoltDB is merely ano…
I get where you are coming from, however if your application is already using SQL then the transition to a more limited but faster database is a lot simpler than going to NoSQL.
Also one of the simple hacks to increase speed is to have a smaller working set database on a separate system to handle more recent items. Because it's under a much higher load the "live" database tends to have really simple usage pattern also due to its smaller size it tends to fit into RAM. And, the “Live” DB tends to have different optimizations (EX: Fewer indexes because you have more writes). Based on this a "striped down" but still SQL database seems like a perfect fit.
PS: It's a lot like Memcached, something that can speed up your application with minimal development time is worth a lot.