From the well-duh department last week came the startling news—brace yourself, this is a real shocker—that MySQL actually plans to do something about Oracle purchasing its essential storage engine, InnoDB.
“Obviously, because Oracle made that acquisition, we are evaluating options to replace that functionality in some way,” said Richard Mason, vice president of MySQL for EMEA (Europe, the Middle East and Africa), as quoted in a Computerworld article. “Were not at the point yet where we can go public with what that plan is, but we will be shortly.”
Mason didnt give any details on what MySQL plans to do to replace InnoDB, which is considered the best of a medley of available storage engines for online transaction processing with MySQL open-source databases. (For what its worth, sources tell me that Mason got taken out to the woodshed by MySQL CEO Marten Mickos, in return for this generous and premature sharing of plans.)
What MySQL is likely up to should be fairly obvious to anybody with knowledge of database history, however. To wit: Its extremely likely that theyre hard at work with Sleepycat to cook up a storage engine to replace InnoDB. Unless technical or business issues arise, theres a good chance well see an announcement early next year.
This is conjecture. Neither MySQL nor Sleepycat, purveyor of the open-source Berkeley DB developers database, cared to be interviewed on the topic.
Open-source database experts werent shy about chiming in, however.
“If I were the MySQL guys, I would be terrified that that engine was owned by somebody like Oracle,” said Mike Stonebraker, father of Ingres and PostgreSQL and, more recently, founder and chief technology officer of newly launched StreamBase.
“My terror would be that they would ignore it and simply put it on the shelf, or, worse yet, start charging high license fees for it. It seems like theres only downside,” Stonebraker said. “If I were the MySQL guys I would want to get off that storage engine as quickly as possible.”
There are two options, Stonebraker said: Go back to Sleepycat, with which MySQL used to have a relationship, or use a storage engine written and contributed by SAP.
Or, of course, build a storage engine itself.
As it is, some two years ago, before InnoDB contacted MySQL, MySQL had been working with Sleepycat to develop a transactional table type for MySQL using Berkeley DB. They got as far as implementing a basic transactional table type, but because Berkeley DB isnt a relational database, it didnt support such things as triggers or constraints.
“It was just the beginning of that kind of work,” said Josh Berkus, a core team member for PostgreSQL. “When they put together the stuff with InnoDB, they sort of dropped that.”
Its still an option, but the Sleepycat engine is pretty much stuck where it was two years ago, Berkus said.
Next Page: An experienced development team is key.
An Experienced Development Team
Is Key”>
Another possible scenario is that MySQL is cooking up its own storage engine to replace InnoDB. One thing it would need to do that, however, is a good stable of developers with database skills—something Sleepycat has that MySQL does not.
“Sleepycat employs a lot of database people with, like, 25 years of experience,” Berkus said. “One problem MySQL has is that most database people working there are new to the database field.”
Most of MySQLs development team hails from non-database-specific fields, such as PHP or Slashdot.
That has given MySQL plenty of perspective on what application developers want out of databases, and has been at the heart of the companys success in creating a database that makes Perl and PHP people happy. Think LAMP: Linux, Apache, MySQL and PHP/Python/Perl.
But, as Berkus pointed out, the disadvantage of that lopsided skill set is that, were MySQL to cook up its own InnoDB alternative, it would wind up rediscovering the wheel over and over.
“All of the hard problems in databases have been covered numerous times,” he said. “When you want to do something hard, including implementing transaction engines capable of full ACID transactions without slowing down MySQL, thats a hard thing to do and requires somebody with experience, or theyll explore dead ends for [a few years].”
But wouldnt a Sleepycat deal put MySQL in the same position that it is in with InnoDB? As in, beholden to an external company, and one that could well change policies when its next renewal policy comes up?
Yes, but bear in mind that InnoDB was pretty much an all-MySQL play. Sleepycat, on the other hand, between its standard, XML and Java flavors, has a robust installed base, completely independent of MySQL.
“Sleepycat has full transactional system now and is a very, very reliable [system],” Stonebraker said. “It essentially has the capabilities of InnoDB or MaxDB. So its efficient, reliable and a solid engine these days. And apparently is selling very well.”
As it is, theres no reason for existing MySQL customers to freak out over Oracles purchase of InnoDB. The move doesnt go over well with prospective MySQL customers, however—particularly not those concerned with SAP. MySQL in 2003 took over development of SAP AGs open-source database, SAP DB, renaming it MaxDB.
“The big issue with this is MySQLs partnership with SAP,” Berkus said. “People running SAP, no matter what the technical advantages are, wont consider migrating to MySQL if theres even a remote threat the product [will not be continued.] Theyll stick with Oracle as long as theres a cloud.”
The InnoDB purchase by Oracle has also driven those who were on the fence to come down squarely in favor of adopting PostgreSQL, specifically because of the InnoDB issue, Berkus said.
My guess is that MySQL is working with Sleepycat to dig itself out of the InnoDB hole. How much work would be needed to make this a viable option as a MySQL engine? Sources say when development was abandoned years back, there were a few months worth of tuning work left to be done.
Id say keep your eye out for an announcement around the first quarter of the new year.
Check out eWEEK.coms for the latest database news, reviews and analysis.
