Re: Thoughts on MySQL and InnoDB

bostic(at)sleepycat(dot)com writes:
>> First BDB is not a viable replacement for InnoDB for two reasons
>> both of which stem from BDB architectural considerations (it simply
>> wasn't designed to function well as a backend for a high
>> concurrency RDBMS). Basically, while InnoDB uses MVCC, BDB uses
>> page locks. BDB therefore has locking issues because you don't
>> have the snapshot capabilities that MVCC gets you with InnoDB, and
>> it is unlikely that one will ever be able to provide multiple
>> transaction levels with the BDB storage engine.
>
> I don't agree.
>
> While Berkeley DB was not designed as an RDBMS backend, it's not
> that far from where BDB is now to being a RDBMS backend: the
> significant missing pieces might be MVCC, foreign key support and
> moving from page-level to row-level locking.

Well, do you think those are likely to appear in version 4.5? :-)

They may not be "fiendishly difficult," but in order for a system to
even start to depend on those things, they have to be present in the
"backend engine" in the first place.

Based on what's there now, which is what people would have to
initially depend on, MySQL(tm)-atop-BDB would initially suffer from
there being a great deal more locking than any of the other 'modern'
database engines require these days.

> Berkeley DB has had multiple transaction levels for a long time.
>
> I don't believe MVCC is that hard. I think foreign key support is
> more cleanly done above the backend engine -- MySQL used InnoDB's
> support for foreign keys because it was there, not because it's the
> right place to do it.

PostgreSQL doesn't really handle FK support inside the storage engine;
it does so via triggers, which lie outside the strict scope of
"storage engine."

> RLL... well, there you have me, that's not an afternoon hack.
> :-) But that's the big missing chunk, if we could solve that
> problem, I think Berkeley DB could be a fine RDBMS backend.

The present absence of MVCC (hard or not, it's not there) would make
the result quite a lot less satisfactory than people would like.

That's not a flame against BDB; it represents something that has been
(and still is) out of the scope of what your folks have tried to
implement. For the common "use cases" for BDB, I don't imagine the
absence of MVCC has caused anyone a need to pause up until now.

I daresay that adding MVCC wouldn't necessarily make BDB forcibly more
attractive for MySQL(tm) users. In effect, the really _big_ problem
with InnoDB(tm) has turned out to be that it was owned by someone
other than MySQL AB, which made it a technology vulnerable to being
bought out from under MySQL AB.

Replacing InnoDB(tm), an engine "owned" by someone other than MySQL
AB, with Berkeley DB, another engine also "owned" by someone other
than MySQL AB, leaves MySQL AB potentially vulnerable to the same
sorts of problems.
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://cbbrowne.com/info/linuxdistributions.html
"If you give someone Fortran, he has Fortran.
If you give someone Lisp, he has any language he pleases."
-- Guy L. Steele Jr.