MySQL to Counter Oracle's Purchase of InnoDB

Miff writes "Computerworld is reporting that MySQL is hoping to counter Oracle's acquisition of InnoDB by providing its customers with an alternative." From the article: "Axmark said the storage engine is 'pluggable,' meaning other storage engines can be substituted instead. He said the code for InnoDB is under the GPL (General Public License), so 'the code is always out there. It will always be out there.'"

Comments

InnoDB

[damiceious]

So, I'm not an expert on the GPL, but it sounds like we're looking at a fork? Where the OSS community gets to continue to use a public GPL`ed version, and Oracle will develop what they bought? I wouldn't think that Oracle would undermine MySql OS'ness, but the article said without a continuance of their license Mysql Development could slow down, or be setback. Maybe someone can explaint the highlights of the GPL that apply here?

Re:InnoDB

[fbg111]

A few questions come to mind:

1. Does Oracle need InnoDB? Would Oracle gain features or capabilities they don't already have by incorporating it into their database? If so, then perhaps we're looking at a fork.

2. If InnoDB is forked, does MySQL have the developer talent to continue advancing InnoDB, or will the OSS community do it for them, or will it stagnate?

Re:InnoDB

[linuxhansl]

The issue is this:
MySQL makes some of its revenue by selling non-open-source licenses to customers who, for whatever reason, do not widh to publish their contribution.

Now, you can only release code under any license of your choice if you own all the copyrights.

Once Oracle owns the copyrights to InnoDB (and if Oracle does not extend the same relicensing rights to MySQL that InnoDB did), the only option MySQL has is redistributing a derived work under the GPL, they are legally no longer allowed to release under any other license. This in turn cuts off one of their revenue streams.

Silly

[jimmyhat3939]

I think this battle between Oracle and MySql is kind of silly. The two databases serve different purposes:

• MySql is excellent for anything ranging from the casual user (a few tables, 1000 rows in each) up to fairly complex transactional work (a small or medium-sized company).
• Oracle has a bunch of extra features, like an excellent fuzzy text search engine and certain optimizers for complex queries that MySql doesn't (and IMHO shouldn't) have. Oracle is the DB of choice for non-M$ medium-to-large databases.

There are other differences. Setup and configuration of MySql is much simpler, and you don't have to go as crazy creating complex partition schemes on your hard disks to get decent performance. But again, that's as it should be -- for simpler projects you want the free alternative.

--
Free 411! 1-800-411-SAVE

Other storage engines compared

[NickDoulas]

Does anyone know the practical difference in using other storage engines? For example, how does using Berkeley DB (http://dev.mysql.com/doc/refman/5.0/en/bdb-storag e-engine.html) compare?

Also, how typical are non-InnoDB configurations of MySQL?

Re:Other storage engines compared

[TheRaven64]

A lot of things where MySQL is used really don't need a database. What they need is something like VMS's structured files - something slightly more abstract than an arbitrary stream of bytes, but not much. In these cases, SQLite might be a better choice than PostgreSQL, although I'd still recommend PostgreSQL to anyone who actually needs a database.

Re:Not silly at all

[jimmyhat3939]

It turns out that configuration is a difficult task and so there's no way to obfuscate that from the DBA.

Also, there exist plenty of situations where there are absolute tradeoffs. Making something fast in one case makes it slow in another. While it would be nice for the DB to be able to figure all that out beforehand, in practice it's impossible.

Take a case where a bunch of precomputation is required to make an operation fast (a particular kind of indexing, for example). You have to instruct the DB to do that precomputation. It can't know in advance that you'll be doing a lot of queries that require it.

Bottom line is that, though the goal of SQL is to make the "how" hidden from the user, in practice this is impossible and not even desirable.

Re:The real problem

[jsonn]

Update your facts. There are exactly two areas where MySQL is noticable faster than PostgreSQL. Those are connection time and non-transactional queries. If you depend on the former -- rewrite your programs, they are bogus. If you depend on the second, pray that the load will not increase enough to kill your database either by inconsistencies or locking. As soon as it comes to complex queries, PostgreSQL runs circles around MySQL.

MySQL 5 is still lacking a lot, most importantly in the I of ACID. It does not ensure integrety, it does things behind the scene which do not match the SQL commands. Silently trunkating data is evil, just like creating invalid dates. No excuses, MySQL just sucks in that department. Besides, stuff like the query cache don't belong into the database server. They belong into the middleware, since that is exactly where the necessary context is.

Last but not least, I do consider PostgreSQL to be much easier to administrate. I have central authentication support, I don't need magic commands to update the internal state of the server etc. It just works.

The LAMP argument is useless. Neither is PHP often a good choice for good web programming, nor is Apache necessarily the best web server. Just because a lot of people ask for it, doesn't make it good. You know the most popular Operating System out there, don't you?

Re:The real problem

[rbanffy]

The single biggest problem with the MP part of the LAMP stack is that both PHP and MySQL attract the wrong kind of developers.

The developers who are willing to live with the shortcomings of PHP and MySQL should consider if they really want to develop software. They are just like the people who are willing to live with the shortcomings of VB6 and Jet databases - they live with them because they know nothing else. While the query language of MySQL has improved with the latest releases, it is still not quite on par with, say, PostgreSQL. Do a somewhat complex join and you will see MySQL's speed go down the drain. See what happens when you have lots of concurrent long-running transactions.

MySQL screams "cheap" since its beginning and no amount of engineering will make it look well built. It may look "overbuilt", at best.