Live data from Hacker News

MySQL is bazillion times faster than MemSQL

dom.as

41–50 of 148 posts

Re: MySQL is bazillion times faster than MemSQL

#41
post #33

MemSQL CTO here. Great article- Domas has done a good job of digging into the internals of MemSQL! A few questions/comments: 1.) The range query issue you pointed out can be explained by a well known limitation of skip lists. Unlike B-Trees, skip lists are unidirectional. By default, our indexes are ascending, so indeed you have to skip to the end to run a MAX() or "ORDER BY id DESC" query. To fix this, just change t…

Regarding #2, we do normally run MySQL with full transactional durability at Facebook. We have for a very long time (several years at least). For example, here is a FB note regarding our enhancing performance under full durability in MySQL from Oct 2010:

https://www.facebook.com/note.php?note_id=438641125932

Re: MySQL is bazillion times faster than MemSQL

#42
post #36
post #31

When debating a fresh new database project - benchmarks aren't really the way to go, because those can be improved. What should be debated is what underlying fundamental has the new project gotten right. Almost every successful database project got something fundamentally right - MySQL, Redis (in-memory), MongoDB(page based storage), Riak(Distributed). On that note, here's my take on MemSQL - People who love MySQL, a…

> People who hate MySQL, usually hate it because of SQL. Or because of the shortcuts it has taken to avoid the "hard stuff", which results in developers taking shortcuts by using MySQL to avoid the "hard stuff". Love or hate SQL for what it is, not the MySQL implementation of it.

> Or because of the shortcuts it has taken to avoid the "hard stuff", which results in developers taking shortcuts by using MySQL to avoid the "hard stuff".

I am deeply interested in what you think this is

Re: MySQL is bazillion times faster than MemSQL

#43
post #3

Whenever one sees a claim about new database technology outperforming standbys like MySQL and Postgres by factors of 10x or more, it's a good idea to suspect the out-of-the-box configuration isn't really durable. What kills write performance in databases is the time it takes to write to disk, not the software overhead.

Or in the case of a lot of vendors we won't mention - blatant lies.

Vendors lie. That is the sole truth of IT purchasing. When testing network gear, some of our network engineers would say, "Vendors lie, but packets don't".

Re: MySQL is bazillion times faster than MemSQL

#44
post #33

MemSQL CTO here. Great article- Domas has done a good job of digging into the internals of MemSQL! A few questions/comments: 1.) The range query issue you pointed out can be explained by a well known limitation of skip lists. Unlike B-Trees, skip lists are unidirectional. By default, our indexes are ascending, so indeed you have to skip to the end to run a MAX() or "ORDER BY id DESC" query. To fix this, just change t…

You seem to be missing the main reason why people have an issue with MemSQL. The issue are quotes like this on your website and video: "MEMSQL IS 30 TIMES FASTER THAN MYSQL." It's an extremely invalid and biased comparison. You're quite literally comparing the speed of writing to RAM versus the speed of writing to disk. If you didn't make such ridiculous assertions, people would accept your product for the actual awe…

This is exactly right, and should be addressed.

memcached is probably 30 times faster than MySQL too, but they don't go around claiming it's a durable database.

Re: MySQL is bazillion times faster than MemSQL

#45
post #3

Whenever one sees a claim about new database technology outperforming standbys like MySQL and Postgres by factors of 10x or more, it's a good idea to suspect the out-of-the-box configuration isn't really durable. What kills write performance in databases is the time it takes to write to disk, not the software overhead.

Or in the case of a lot of vendors we won't mention - blatant lies.

Are you specifically not mentioning Oracle by any chance?

Re: MySQL is bazillion times faster than MemSQL

#46
post #33

MemSQL CTO here. Great article- Domas has done a good job of digging into the internals of MemSQL! A few questions/comments: 1.) The range query issue you pointed out can be explained by a well known limitation of skip lists. Unlike B-Trees, skip lists are unidirectional. By default, our indexes are ascending, so indeed you have to skip to the end to run a MAX() or "ORDER BY id DESC" query. To fix this, just change t…

You seem to be missing the main reason why people have an issue with MemSQL. The issue are quotes like this on your website and video: "MEMSQL IS 30 TIMES FASTER THAN MYSQL." It's an extremely invalid and biased comparison. You're quite literally comparing the speed of writing to RAM versus the speed of writing to disk. If you didn't make such ridiculous assertions, people would accept your product for the actual awe…

Hi Tim, we're not comparing "the speed of writing to RAM versus the speed of writing to disk." You can run InnoDB with a buffer pool large enough to keep the entire database in memory and we'll still outperform it significantly. We're actually working on a blog post right now with that comparison.

Re: MySQL is bazillion times faster than MemSQL

#47
post #31

When debating a fresh new database project - benchmarks aren't really the way to go, because those can be improved. What should be debated is what underlying fundamental has the new project gotten right. Almost every successful database project got something fundamentally right - MySQL, Redis (in-memory), MongoDB(page based storage), Riak(Distributed). On that note, here's my take on MemSQL - People who love MySQL, a…

And people who know just use Postgres and sit back and watch the fireworks.

Re: MySQL is bazillion times faster than MemSQL

#48

Whenever one sees a claim about new database technology outperforming standbys like MySQL and Postgres by factors of 10x or more, it's a good idea to suspect the out-of-the-box configuration isn't really durable. What kills write performance in databases is the time it takes to write to disk, not the software overhead.

For what it's worth SQL Server doesn't meet his definition of "durable." It writes a transaction log and then writes those transactions to disk on a checkpoint [1]. Typically, that checkpoint automagically happens, but you can also force it to clear the buffer with a "checkpoint" command. InnoDB also does this, too [2]. I don't know if MemSQL actually has checkpointing or what, but it's just worth noting. [1]: http:/…

SQL Server writes to the transaction log immediately, it writes the contents of modified data pages on checkpoints, but only for transactions that have committed. For data pages that haven't been written to (dirty pages) when the system crashes, the recovery process can recreate completed transactional changes from the log (which is rolling forward), or wipes out failed transactions from the log (rolling backward).

Re: MySQL is bazillion times faster than MemSQL

#49
post #33

MemSQL CTO here. Great article- Domas has done a good job of digging into the internals of MemSQL! A few questions/comments: 1.) The range query issue you pointed out can be explained by a well known limitation of skip lists. Unlike B-Trees, skip lists are unidirectional. By default, our indexes are ascending, so indeed you have to skip to the end to run a MAX() or "ORDER BY id DESC" query. To fix this, just change t…

I don't think the point of the article was seriously about the details of performance in MemSQL versus MySQL. I took it as a criticism of the irresponsible reporting of benchmarks.

Re: MySQL is bazillion times faster than MemSQL

#50
post #46

Earlier quoted context omitted.

You seem to be missing the main reason why people have an issue with MemSQL. The issue are quotes like this on your website and video: "MEMSQL IS 30 TIMES FASTER THAN MYSQL." It's an extremely invalid and biased comparison. You're quite literally comparing the speed of writing to RAM versus the speed of writing to disk. If you didn't make such ridiculous assertions, people would accept your product for the actual awe…

Hi Tim, we're not comparing "the speed of writing to RAM versus the speed of writing to disk." You can run InnoDB with a buffer pool large enough to keep the entire database in memory and we'll still outperform it significantly. We're actually working on a blog post right now with that comparison.

I think it might help more to explain how your design works and why we should trust it, than to provide simple benchmarks proving the speed. Speed is only one part of the equation, and frankly it's the one I care about only after durability is taken care of. Explain thoroughly how you achieve both and it will be more relevant to me. Looking forward to the post.
Post reply on HN