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

Show HN: I built a MySQL storage engine which is InnoDB compatible

upscaledb.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Show HN: I built a MySQL storage engine which is InnoDB compatible

#11

Post by j_jochem »

cruppstahl wrote: post #7
Animats wrote: post #4

Earlier quoted context omitted.

Ulp. The whole point of the InnoDB engine is that it supports atomic transactions, even over crashes. If you want an unsafe table, there's the ISAM engine, which is faster. What does "100% compatible to InnoDB" mean here? It's not functionally compatible and it's not disk-file-format compatible.

If that's your definition of atomicity - yes, upscaledb offers atomic operations. If you define atomicity as the "A" in "ACID" then no - BEGIN/COMMIT wrappers are not yet available. Work in progress!

So what you're saying is that in general, transactions are implemented, but the begin/commit syntax for transactions is not yet supported?

Re: Show HN: I built a MySQL storage engine which is InnoDB compatible

#13

Post by evanelias »

The upscaledb FAQ indicates "it is not yet concurrent; it uses a big lock to make sure that only one thread can access the upscaledb environment at a time".

InnoDB is designed for concurrency (using MVCC, granular locking, etc) so I'd expect it to be slower at single-threaded workloads than another engine that skips all that.

Only using single-threaded benchmarking is a bit misleading, imo. This is mentioned in the article but only in a small bullet point towards the bottom.

Re: Show HN: I built a MySQL storage engine which is InnoDB compatible

#15

Post by rodgerd »

marmaduke wrote: post #6

Stopped reading after no transactions. Theory question: musn't transactions reduce necessarily performance?

> Stopped reading after no transactions

Ironically, back in the day, the core MySQL team argued that was a feature, not a bug.

Re: Show HN: I built a MySQL storage engine which is InnoDB compatible

#17

Post by endymi0n »

No transactions? Single-threaded? Global lock?

Don't want to put anyone's work down, but at first sight this looks much more like MyISAM than InnoDB - and just like this, MyISAM's a helluva lot faster than InnoDB for single writer workloads throwing ACID out of the window.

Just that MyISAM is battle tested over the course of several years. Again, interested to see what comes out of it, but if history is a lesson, it's usually easier to go from correct to fast (PostgreSQL) than from fast to correct (MySQL et al.).

Re: Show HN: I built a MySQL storage engine which is InnoDB compatible

#18

Post by morgo »

cruppstahl wrote: post #8
marmaduke wrote: post #6

Stopped reading after no transactions. Theory question: musn't transactions reduce necessarily performance?

Not necessarily. I ran sysbench with InnoDB and manually switched off transactions, and it was a lot slower. I don't know why - didn't look into it. upscaledb does use transactions. I.e. if you insert a row with a primary and a secondary index then upscaledb inserts two key/value pairs in two databases. All these operations are wrapped in Transactions. They are just not yet supported on SQL level.

In InnoDB everything is a transaction. If you do not begin/commit then each statement will be its own transaction.

Batching a group of statements together in a small transaction is usually better because it reduces log flushing. ACID only needs to be guaranteed on commit. Similarly, applying transactions in parallel is faster because of group commit.

Re: Show HN: I built a MySQL storage engine which is InnoDB compatible

#19

Post by __jal »

rodgerd wrote: post #15
marmaduke wrote: post #6

Stopped reading after no transactions. Theory question: musn't transactions reduce necessarily performance?

> Stopped reading after no transactions Ironically, back in the day, the core MySQL team argued that was a feature, not a bug.

To be fair, that's normal, if unfortunate, competitive behavior. "We meant to do that" is the rule until there's running code correcting the initial mistake.

Less forgivable is training a couple generations of developers that all the other mistakes they made are the Right Way...

Re: Show HN: I built a MySQL storage engine which is InnoDB compatible

#20

Post by nine_k »

endymi0n wrote: post #17

No transactions? Single-threaded? Global lock? Don't want to put anyone's work down, but at first sight this looks much more like MyISAM than InnoDB - and just like this, MyISAM's a helluva lot faster than InnoDB for single writer workloads throwing ACID out of the window. Just that MyISAM is battle tested over the course of several years. Again, interested to see what comes out of it, but if history is a lesson, it'…

Version 0.0.1 looks much like an experiment in writing a working storage engine. It lacks a lot of critically important things. It's hard to say anything at this point about any real-world scenarios where this storage engine would be useful.

What concerned me a bit was absence of an interesting and promising general idea behind the implementation, the reason to implement a new engine. Maybe it is there, but the blog post does not say anything about it.

Post reply on HN