6 ms·

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 FAST

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 awesome things it does and not focus on refuting your bullshit claims.

calinet6 14y ago
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.
- mariusmg 14y ago
  It fucking says "Durable by Default" on their main page !!!! edit: memSQL main page says "Durable by Default"
  - slurgfest 14y ago
    To clarify, memcached's page does not say "durable by default"
    - deleted 14y ago
      [deleted]
      - zaphar 14y ago
        Read more carefully next time. The post you are responding didn't say anything a bout MemSQL. It was talking about memcached.
nikita 14y ago
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.
- calinet6 14y ago
  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.
- ankrgyl 14y ago
  @calinet126 We have the durability interface and configuration options here http://developers.memsql.com/docs/1b/durability.html http://developers.memsql.com/docs/1b/durability.html This should give you a good idea about how durability will react to tuning, but it doesn't dive deep into the internal design. If there's enough interest (seems like there is) we'd be happy to discuss it in a blog post.
- themonk 14y ago
  Does 'significantly' means '30 times' here?
tigerBL00D 14y ago
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?
- phillmv 14y ago
  >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.
  - tigerBL00D 14y ago
    You are asserting that databases are always I/O bound and never CPU bound. Your assertion is wrong. A properly tuned database will become CPU bound (whether it's MemSQL or MySQL). At that point hyper-efficient execution results in higher throughput and lower latency.
    - dhruvbird 14y ago
      I agree with what you have to say, but I don't see how you can determine that this query: SELECT * FROM table WHERE id > 5 LIMIT 10; is actually of the same form as this query: SELECT * FROM table WHERE id > 10 LIMIT 5; without actually parsing the two. I mean you will incur a parsing overhead either way. What I think MemSQL is trying to optimize out is the actual execution of the query. I mean rather than interpreting and running it with checks performed in every iteration, they are compiling the code. I don't know how much of a difference this would make without actually seeing the numbers.

calinet6 14y ago

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.

mariusmg 14y ago
It fucking says "Durable by Default" on their main page !!!! edit: memSQL main page says "Durable by Default"
- slurgfest 14y ago
  To clarify, memcached's page does not say "durable by default"
  - deleted 14y ago
    [deleted]
    - zaphar 14y ago
      Read more carefully next time. The post you are responding didn't say anything a bout MemSQL. It was talking about memcached.

nikita 14y ago

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.

calinet6 14y ago
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.
ankrgyl 14y ago
@calinet126 We have the durability interface and configuration options here http://developers.memsql.com/docs/1b/durability.html http://developers.memsql.com/docs/1b/durability.html This should give you a good idea about how durability will react to tuning, but it doesn't dive deep into the internal design. If there's enough interest (seems like there is) we'd be happy to discuss it in a blog post.
themonk 14y ago
Does 'significantly' means '30 times' here?

tigerBL00D 14y ago

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?

phillmv 14y ago
>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.
- tigerBL00D 14y ago
  You are asserting that databases are always I/O bound and never CPU bound. Your assertion is wrong. A properly tuned database will become CPU bound (whether it's MemSQL or MySQL). At that point hyper-efficient execution results in higher throughput and lower latency.
  - dhruvbird 14y ago
    I agree with what you have to say, but I don't see how you can determine that this query: SELECT * FROM table WHERE id > 5 LIMIT 10; is actually of the same form as this query: SELECT * FROM table WHERE id > 10 LIMIT 5; without actually parsing the two. I mean you will incur a parsing overhead either way. What I think MemSQL is trying to optimize out is the actual execution of the query. I mean rather than interpreting and running it with checks performed in every iteration, they are compiling the code. I don't know how much of a difference this would make without actually seeing the numbers.