> 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.
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.
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.
Regards,
--keith
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Keith Bostic bostic@sleepycat.com
Sleepycat Software Inc. keithbosticim (Yahoo IM)
118 Tower Rd. +1-781-259-3139
Lincoln, MA 01773 http://www.sleepycat.com