Yes, I said InnoDB+ with a plus sign at the end (also see the first comment here).
Please note that this blog post is only based on public information. It has absolutely nothing in it that I only could have learned from back when I worked at Sun or MySQL AB. Everything has links or pointers to where you can find the information out on the Internet and all thoughts are based on stringing these things together.
There was a lot of talk around the acquisition of Sun Microsystems by Oracle about MySQL (MySQL AB was bought by Sun). Some of the talk centred around Oracle and their ability to make a closed source version of MySQL with added bits that wouldn’t be released as GPL. They’ve since proved that they’re quite willing to do this to an open source project (see OpenSolaris).
Relatively recently, a bunch of history from the old InnoDB SVN trees was imported into the MySQL source tree. You can pull the revision of the SVN tree as of InnoDB Plugin 1.0.6 release by using revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:6263  from the MySQL repository – or just use a branch I’ve put up on launchpad for it (lp:~stewart/haildb/innodb-1.0.6-from-svn).
The first revision from the SVN tree was created on 2005-10-27, which you may remember was not too long after Oracle acquired Innobase on the 7th of October that year. The next two revisions were importing the 5.0 innodb code base, and then the 5.1 code base. Previous history can be found according to this blog post on Transactions on InnoDB.
According to Monty in the comment on the Pythian blog:
Oracle did work on a closed source version of InnoDB, codename InnoDB+, but they never released it, probably because our contract with them stopped them.
and from Eben Moglen’s letter to the EU Commission (via Baron Schwartz’s blog post):
Innobase could therefore have provided an enhanced version of InnoDB, like Oracle’s current InnoDB+, under non-GPL license
Most tellingly is a lot of references in the revision history to “branches/innodb+” as well as this commit:
revno: 0.5.148
revision-id: svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:6329
parent: svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:6322
committer: vasil
timestamp: Thu 2009-12-17 11:00:17 +0000
message:
branches/innodb+: change name and version
Change name from “InnoDB Plugin” to “InnoDB+” and
version from 1.0.5 to 1.0.0.
So, from the revision history I’ve managed to work out that it likely was going to have the following features:
- innodb_change_buffering (for values other than inserts)
See revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/zip:4061
Or, more tellingly revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:4053
The latter tells about the merge of change buffering for delete-mark and delete in addition to the default of inserts. - Possibly compressed tables.
revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:2316 seems to show that it may have been copied across: “branches/innodb+: Copy from branches/zip r2315” in the comment. Â There’s a lot of other merges of branches/zip as well - Something named FTS
There is “branches/fts” in revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:2325 and revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:2324 Â (there’s an import of a red-black tree implementation)
If you also look at revid:Â svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:6776
you’ll see references to a innofts+ branch with ha_innodb.cc in it.
So between a red-black tree and handler changes, this is surely something interesting. - Persistent statistics (also revid:Â svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:6776)
- Metrics Table (also revid:Â svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:6776)
- posix_fadvise() hints to temp files used in creating indexes (revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:2342 )
- Improved recovery performance
See revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:2989
Talks about using the red-black tree for sorted insertion into the flush_list - native linux aio (revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:3913 )
- group commit (revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:3923 )
- New mutex to protect flush_list (revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:6330)
and finally, in revid:svn-v4:16c675df-0fcb-4bc9-8058-dcc011a37293:branches/innodb%2B:6819 you can see the change from “InnoDB+” back to “InnoDB” for being the built in default for MySQL 5.5
So, InnoDB+ was the internal name for the InnoDB plugin?
Most of this is in the plugin today. That is great for people like me who need maximum performance from InnoDB.
I totally agree – it’s great to see this stuff out in the open now – InnoDB really is a great engine. Not only that, but the code is (generally) quite nice.
Hopefully I’ve just managed to fill in some gaps in InnoDB history that weren’t fully known (at least publicly by those outside Oracle).
It seems that InnoDB+ was separate to the InnoDB Plugin, as in, they were two different things.
Hi Stewart
Interesting history! When you say that this contains nothing from your time at MySQL/Sun, you really mean that people like you and me weren’t in the know to begin with. At least I wasn’t.
After I left Sun I’ve heard this being talked about, but the first time I saw the actual name “InnoDB+” was when I spotted it in Eben’s submission in the Oracle-Sun case. At that time Google would show exactly zero hits for the term, so it wasn’t publicly known and this was the first occurence. (This was also the giveaway that SFLC’s “independent” submission was actually based on material and collaboration from Oracle, since it relied on Oracle confidential info out of the blue – this was confirmed months later when the EU decision became public, the log shows that it was Oracle that submitted Eben’s paper as part of their own paperwork. Anyway, borderline off topic…) After Eben had spilled the beans, Monty apparently felt confident enough using it in public, after which Baron and others mentioned it in their blogs.
I’m told I’m still not allowed to discuss in public some things I learned by being part of the Oracle-Sun investigation, yet the following I specifically did *not* learn from there since we were thrown out from the room. This is based on rumors from Oracle employees and otoh just independent database people in Helsinki who know both MySQL and Innobase well.
So by guessing, I would say that Oracle was developing a project called InnoDB+ that would have been an enhanced version of InnoDB. To follow through with this they needed either
a) an OEM license from MySQL so they could distribute a full SQL database as closed source – but MySQL refused to sell them such licenses. (This is what most 3rd party engines do, but it seems obvious why MySQL wouldn’t want InnoDB to do it.)
b) negotiate a change in the existing agreement that made InnoDB a subcontractor to MySQL, because that prevented Innobase Oy from selling or publishing a competing SQL database server. (It is commonly known the agreement prohibited MySQL from forking InnoDB – which is exactly what they did for the 2009 user conference performance version – so this alternative seems likely: that a similar prohibition existed for Innobase to compete against MySQL, even if they had developed their own SQL layer, which your analysis shows no trace of.)
or
c) both of the above.
One thing I noticed is how BerkeleyDB published their SQLite compatible interface only a month or so after the Sun acquisition was closed. That was the clue that such a restriction may have existed, since BerkeleyDB also used to be a MySQL storage engine once upon a time. Possibly BerkeleyDB had developed this stuff long ago, but couldn’t legally publish it before.
There was also a rumor last winter that Oracle was about to publish an enhanced and closed source “InnoDB with SQL layer”. But looking back, this might have been confusion with the BerkeleyDB+SQLite thing. Perhaps we’ll see a MySQL 5.5 enhanced and closed source version when GA time comes, but I doubt it. When MySQL was a separate company, it made sense to try to develop a MySQL competitor. But it wouldn’t make sense now for Oracle to launch an InnoDB+ to compete against MySQL, what would be the point of that? So as you explain in this post, the plan that was InnoDB+, is now regular MySQL.
So it seems that InnoDB had plans for their own product, which would have been an enhanced version of what could be found in MySQL. With Sun/MySQL not giving Oracle the license to do it as a standard SQL database server (whether option a or b), it seems this product evolved to InnoDB plugin, which was made a feasible product due to MySQL 5.1 plugin architecture (and the standalone InnoDB Embedded too). And today we see this stuff ending up in MySQL 5.5.
And they lived happily ever after.
Thanks to completely unrelated chat here in Istanbul, I realized that “Something named FTS” = Full Text Search.
Seems like this is not in MySQL 5.5. Will be interesting to see if it shows up in a closed source plugin, or it was canceled, or… (More conspiracy theories and FUD coming up at 11.)
Pingback: Persistent index statistics for InnoDB | Ramblings