Live data from Hacker News

MySQL is bazillion times faster than MemSQL

dom.as

81–90 of 148 posts

Re: MySQL is bazillion times faster than MemSQL

#81

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."

What does this mean? Does the SQL get converted into actual C++ source code, then compiled with an internal C++ compiler? That seems like a weird thing to do. Or is it translated directly into an AST? If yes, I can't imagine other db's not doing it? I don't understand the claim being made here.

Re: MySQL is bazillion times faster than MemSQL

#82
post #79

Earlier quoted context omitted.

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.

> At that point hyper-efficient execution results in higher throughput and lower latency. I don't get excited for 1% decreases in latency. I'm willing to bet money that the performance penalty behind parsing the sql queries is asymptotically a constant - or at least, a tiny fraction of the time spent computing the data set. I feel especially confident in this because memsql never brags about the specific increase in…

It is not about the cost of parsing SQL text. Think of it as intermediate bytecode for SQL that is interpreted as query is being executed. Every SQL database does some variation of it. What is unique about MemSQL is that this bytecode is actually compiled to native code using GCC.

Re: MySQL is bazillion times faster than MemSQL

#83

Why is "written to hard disk" considered to be "durable"? Isn't that just a higher likelihood of "durability"?

This is actually a fair and valid point. On all but the most delicately configured systems, the standard configuration of basically all SQL databases does not occlude committed data loss during power failure due to the hard disk's write cache. See for example http://www.postgresql.org/docs/8.3/static/wal-reliability.ht...:

    When the operating system sends a write request to the disk
    hardware, there is little it can do to make sure the data has
    arrived at a truly non-volatile storage area. Rather, it is the
    administrator's responsibility to be sure that all storage
    components ensure data integrity. Avoid disk controllers that have
    non-battery-backed write caches. At the drive level, disable
    write-back caching if the drive cannot guarantee the data will be
    written before shutdown.
Which almost nobody does, because performance falls through the floor unless you're pimping a $500 RAID card (don't even mention software RAID).

The SQLite documentation goes into further detail surrounding the atomicity of writing a single 512 byte sector during a power failure (on old drives, on 4096 byte drives, and on SSDs). Few people seem to account for any of this stuff, yet sleep soundly at night regardless.

Re: MySQL is bazillion times faster than MemSQL

#84

Earlier quoted context omitted.

That's a bit heavy-handed; additional benchmarks will be published against a variety of configurations and other databases. Companies use MemSQL because it uses memory as the primary locus of data. If you have a fast data problem, you couldn't use a disk-based system. At high speeds, you'd want to deploy any database in an active-active mode.

I just want to echo mike above with a slightly different tact that perhaps will get across my perception of our feelings. It's dishonest , at the very least, to claim ACID compliance and then do benchmarks against a known ACID compliant competitor without having the same level of ACIDity enabled in your program. If you want to prove how fast MemSQL is against MongoDB, that's one thing (I understand it also can be "fu…

> (I understand it also can be "fully durable" but it is not by default due to speed concerns)

Just a little addendum: MongoDB has been "durable by default" since v1.7 I believe (current: 2.0.6).

Re: MySQL is bazillion times faster than MemSQL

#85

Why is "written to hard disk" considered to be "durable"? Isn't that just a higher likelihood of "durability"?

Since it's impossible to completely avoid catastrophic hardware failure in the real world, obviously that can't be the threshold for durability. But losing data to anything short of hardware failure means you're non-durable. Software crashes can't lose data. Kernel panics can't lose data. Power outages can't lose data.

Re: MySQL is bazillion times faster than MemSQL

#86
post #30

Earlier quoted context omitted.

Shared environments with virtualized IO are not good places to run benchmarks.

I couldn't agree more, but its the closest to standardized testing we can get that everyone can use. I HATE the idea personally, but I cannot think of a better way to start comparing apples to apples.

I'd opt for the TPC workloads on standardized hardware: http://www.tpc.org/tpcc/results/tpcc_price_perf_results.asp

Re: MySQL is bazillion times faster than MemSQL

#87
post #81

Earlier quoted context omitted.

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." What does this mean? Does the SQL get converted into actual C++ source code, then compiled with an internal C++ compiler? That seems like a weird thing to do. Or is it translated directly into an AST? If yes, I can't imagine other db's not doing it? I don't understand the claim being made here.

Yes, they compile SQL statements into linux binaries using a bundled GNU compiler toolchain.

I am also curious if there is some way the developers have demonstrated the benefits of this approach vs. what other systems do. Most of the CPU time in a simple query in VoltDB is spent in networking, validating and suffering the cache-miss pain of walking index data structures. I can't see clearly how compiling to native code makes any of that much faster.

Re: MySQL is bazillion times faster than MemSQL

#88

Why is "written to hard disk" considered to be "durable"? Isn't that just a higher likelihood of "durability"?

This is actually a fair and valid point. On all but the most delicately configured systems, the standard configuration of basically all SQL databases does not occlude committed data loss during power failure due to the hard disk's write cache. See for example http://www.postgresql.org/docs/8.3/static/wal-reliability.ht... : When the operating system sends a write request to the disk hardware, there is little it can d…

While backup power might be expensive in a hard drive situation, it looks like even cheap SSDs are available with power loss protection. And as far as I'm aware you're better off using SSDs for databases anyway.

Re: MySQL is bazillion times faster than MemSQL

#89
post #84

Earlier quoted context omitted.

I just want to echo mike above with a slightly different tact that perhaps will get across my perception of our feelings. It's dishonest , at the very least, to claim ACID compliance and then do benchmarks against a known ACID compliant competitor without having the same level of ACIDity enabled in your program. If you want to prove how fast MemSQL is against MongoDB, that's one thing (I understand it also can be "fu…

> (I understand it also can be "fully durable" but it is not by default due to speed concerns) Just a little addendum: MongoDB has been "durable by default" since v1.7 I believe (current: 2.0.6).

Since 2.0, the journal is enabled. It flushes to disk every 100ms. Operations can return successfully without writing the data to disk. This is similar to what MemSQL is offering by default.

Re: MySQL is bazillion times faster than MemSQL

#90
post #53
post #43

Earlier quoted context omitted.

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".

Nice quote! More generally when considering any solution you should always test it in your environment according to your performance needs BEFORE you buy it. Any vendor worth their salt will let you do this.

From experience, that's pretty much no vendor these days.

I will say positive things for Microsoft: you can always trial their software before you buy it.

Post reply on HN