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

cruppstahl wrote: post #3

tombert wrote: post #2

This looks pretty sexy. Are there atomicity guarantees?

BEGIN/COMMIT is not yet supported. But that's on my TODO list.

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.

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

#5

Post by spotman » Tue, Sep 27, 2016, 7:34 PM UTC

Performance is great, but what is more interesting is maintaining that performance in the midst of failures and things going wrong.

I don't know anyone who chooses InnoDB and says "gee I wish it were faster". While it isn't the fastest show in town, it is a known quantity, and how it breaks is well understood.

So if I was going to use a different storage engine, would want something more than its a bit faster, in some cases.

Having said that, what a wonderful amount of work, and don't stop hacking on it!

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

#6

Post by marmaduke » Tue, Sep 27, 2016, 7:35 PM UTC

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

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

#7

Post by cruppstahl » Tue, Sep 27, 2016, 7:36 PM UTC

Animats wrote: post #4

cruppstahl wrote: post #3

Earlier quoted context omitted.

BEGIN/COMMIT is not yet supported. But that's on my TODO list.

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!

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

#8

Post by cruppstahl » Tue, Sep 27, 2016, 7:42 PM UTC

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.

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

#9

Post by mey » Tue, Sep 27, 2016, 7:48 PM UTC

spotman wrote: post #5

Performance is great, but what is more interesting is maintaining that performance in the midst of failures and things going wrong. I don't know anyone who chooses InnoDB and says "gee I wish it were faster". While it isn't the fastest show in town, it is a known quantity, and how it breaks is well understood. So if I was going to use a different storage engine, would want something more than its a bit faster, in som…

The most recent break I encountered was ibtmp1 exploding to 100's of GB and killing the box with InnoDB, so I'm not sure "how it breaks is well understood".

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

#10

Post by philjohn » Tue, Sep 27, 2016, 7:56 PM UTC

mey wrote: post #9

spotman wrote: post #5

Performance is great, but what is more interesting is maintaining that performance in the midst of failures and things going wrong. I don't know anyone who chooses InnoDB and says "gee I wish it were faster". While it isn't the fastest show in town, it is a known quantity, and how it breaks is well understood. So if I was going to use a different storage engine, would want something more than its a bit faster, in som…

The most recent break I encountered was ibtmp1 exploding to 100's of GB and killing the box with InnoDB, so I'm not sure "how it breaks is well understood".

Funnily enough I encountered something similar years ago on Microsoft SQL Server 2005.

Never got to the bottom of it either.