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

MySQL is bazillion times faster than MemSQL

dom.as

Post reply on HN
Print view View original

61–70 of 148 posts

Re: MySQL is bazillion times faster than MemSQL

#61

Post by tigerBL00D »

timaelliott wrote: post #40
nikita wrote: 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…

Tim, if you want to talk substance, you have to peer deeper under the covers. And if you do that, then you just can't overlook the fact that the query execution model used by MemSQL is significantly different than that used by old school relational databases, including MySQL. And what's different is that MemSQL translates you SQL query into extremely efficient C++ code. Code that is compiled and executed natively. Whereas MySQL, SQL Server, Postgress, Oracle - all of these products evaluate queries by interpreting their respective tree representations of your SQL queries. So which database do you expect to be faster? The one that runs native code or ones that interpret?

This is a huge differentiator we are talking about here. For someone who has been around databases for quite some time (of which I had spent about 5 years working on SQL Server engine) this is very exciting. Is it not?

Re: MySQL is bazillion times faster than MemSQL

#62

Post by slurgfest »

timaelliott wrote: post #27
ericfrenkiel wrote: post #5

When someone writes on their intro "... and now in return I want to waste your time a bit." it's a sign that someone isn't being serious. Domas' main criticism is that our video, http://vimeo.com/44087431 , uses a MySQL with standard defaults. Since tuning a database is by definition a custom process, we wanted to demonstrate what performance you'd get "out of the box." The video speaks for itself. MemSQL can push 80…

> If you want to throw an anchor behind a speed boat, you can do it, though we don't recommend it. So, what your video is saying, is that your speedboat is 80,000 faster than MySQL with an anchor attached. Seems like a fair comparison.

I have no interest in MemSQL.

I think it is reasonably fair to test MySQL's default, recommended configuration which writes to disk frequently, particularly if the other configuration is not worth using.

If it is worth using, then the real question is what you give up by using MemSQL instead of MySQL in the alternate configuration.

If you mean to ding MemSQL on durability then you can ding MySQL on speed. If you aren't going to ding MemSQL on durability (because you are comparing it to less disk-intensive MySQL configs) then presenting a case for MySQL means you have to come up with something that you are giving up other than durability based on frequent disk writes.

Re: MySQL is bazillion times faster than MemSQL

#63

Post by slurgfest »

mariusmg wrote: post #51
calinet6 wrote: post #44

Earlier quoted context omitted.

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.

It fucking says "Durable by Default" on their main page !!!! edit: memSQL main page says "Durable by Default"

To clarify, memcached's page does not say "durable by default"

Re: MySQL is bazillion times faster than MemSQL

#64

Post by HarrisonFisk »

nikita wrote: post #52
HarrisonFisk wrote: post #41

Earlier quoted context omitted.

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

Harrison, what are these settings for InnoDB? innodb_flush_log_at_trx_commit, innodb_flush_methodm, innodb_doublewrite,

The primary settings are:

sync_binlog=1 innodb_flush_log_at_trx_commit=1 (which is default, but we add it to our configs since we run with =2 on the slaves since they don't need full durability)

We do use some performance related settings related to this as well:

innodb_flush_method = O_DIRECT innodb_prepare_commit_mutex=0 (enables group commit in the Facebook patch, other branches have a different setting)

For settings like innodb_doublewrite we leave the default of enabled.

Re: MySQL is bazillion times faster than MemSQL

#65

Post by slurgfest »

maratd wrote: post #34
cs702 wrote: post #15

Whenever I read an article like this, I often end up feeling that on the 'truthiness' spectrum the scale goes like this: lies, damn lies, statistics, benchmarks ;-)

Every public benchmark is a horrible blasphemous lie. The only benchmarks that are honest are the ones you conduct in private, with your very specific use case. There is no point in publishing them, because they're useless to everybody but you. Public benchmarks, on the other hand, are crafted as advertising for your favorite [fill in the blank].

If you generate some data which would be dishonest when published, it is also dishonest in private, except that you are only being dishonest to yourself and nobody can review your dishonesty.

If you generate data which are honest in your use case, then you can publish them honestly as long as you are specific about your use case.

Re: MySQL is bazillion times faster than MemSQL

#66

Post by phillmv »

tigerBL00D wrote: post #61
timaelliott wrote: post #40

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…

Tim, if you want to talk substance, you have to peer deeper under the covers. And if you do that, then you just can't overlook the fact that the query execution model used by MemSQL is significantly different than that used by old school relational databases, including MySQL. And what's different is that MemSQL translates you SQL query into extremely efficient C++ code. Code that is compiled and executed natively. Wh…

>And what's different is that MemSQL translates you SQL query into extremely efficient C++ code. Code that is compiled and executed natively. Whereas MySQL, SQL Server, Postgress, Oracle - all of these products evaluate queries by interpreting their respective tree representations of your SQL queries.

This sounds like absurd cargo culting. I've never designed a database but parsing the SQL can not have ever been the bottleneck; the fact that you rarely write to disk is where any speed improvements can be found.

Re: MySQL is bazillion times faster than MemSQL

#67

Post by mumrah »

This reminds me of some early MongoDB benchmarks. Claims of extremely high write throughput when really it's writing to memory and relying on mmap to eventually sync the data to disk.

Making write speed claims when you're not touching the disk is like bragging about how fast you can cat a file to /dev/null.

Re: MySQL is bazillion times faster than MemSQL

#68

Post by antirez »

nikita wrote: 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…

It's not specifically related to the original article discussed here, but skiplists don't need to be unidirectional. For instance Redis implements all the sorted sets operations using doubly-linked skiplists, so once you identify a node you can traverse other nodes in both directions.

Re: MySQL is bazillion times faster than MemSQL

#70

Post by ankrgyl »

antirez wrote: post #68
nikita wrote: 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…

It's not specifically related to the original article discussed here, but skiplists don't need to be unidirectional. For instance Redis implements all the sorted sets operations using doubly-linked skiplists, so once you identify a node you can traverse other nodes in both directions.

Good point- ours are currently unidirectional because they have to be lock free. We have some ideas on how to keep them lock free and make them bidirectional, but that's not part of the current release.
Post reply on HN