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

It looks bad, but...

[lifterx]

I think there's hope for MySQL. With Oracle's products becoming more affordable and the recent purchase of InnoDB it looks bad for MySQL but I think this could be there chance to become more independant of other companies.

I think this could be the big push that they needed to seriously consider teaming up with the Postgres guys, which could be good news for everyone interested.

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

Re:Silly

[Anonymous Coward]

Having been at one end of the 'launch' it was marketed more as a reaction to the similarly licensed free edition of MS SQL Server (Express Edition) rather than mySQL.
Probably correctly, they think that people use mySQL because it's open source, rather than just because it's free.

Specifically, they think they're losing out in 2 ways - firstly to projects that are starting small using SQLServer, and then MS getting the server sale when the project expands (rather than locking them into Oracle early on - and yes, they did compare themselves to drug dealers!). Secondly, they're losing developer mindshare to SQLServer in MS codeshops and education. I'm not sure it would really make much difference there - those guys just want the tight integration of the VisualStudio/.NET tools and probably are not even going to be aware what changing D/B might offer them - you need to know about those cool analytic functions to use them rather than write client side code to do the same, but they're more something you'll use if you're already on Oracle than a deal breaker.

It's a moot point anyway, everyone knows a database is only a persistence layer and frameworks like Hibernate are going to do away with developers ever needing to know how or what database is used. Knowing nothing about the systems you connect to always results in better software.

Re:Silly

[Eivind Eklund]

The problem with NULL is that it doesn't fit into binary logic. Both

0 < NULL

AND

0 > NULL

is false.

This mess up a bunch of logic.

For your case above, I'd code the answers something like this:

CREATE TABLE answers (
question_id INT UNSIGNED NOT NULL REFERENCES questions(question_id),
answer INT UNSIGNED NOT NULL,
user_id INT UNSIGNED REFERENCES users(user_id),
PRIMARY KEY(question_id, user_id)
);

An answer is represented by a row (question_id, user_id) existing, lacking information is represented by the row not existing.

Eivind.

MySQL needs to build their own storage engine

[Java_Good_COBOL_Bad]

It always seemed lame to me that MySQL users had to concern themselves with with "storage engine" gets used under the covers. The obvious answer from MySQL's perspective is to build their own storage engine as an integrated part of MySQL.

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:Other storage engines compared

[einhverfr]

As for the "huge performance cost", I really doubt there is such a thing.

Sure there is. BDB uses page-level locking while Innodb uses snapshot technology.

This means two things:

1: BDB has blocking issues in high-concurrency environments and is thus not suitable for a backend for a higher-traffic RDBMS.

2: You can only support Read Committed transaction level. You cannot support Read Uncommitted, Serializable, and Read Repeatible because you lack the snapshot capability required to make this happen.

So no, BDB is not a viable alternative due to backend issues. This is why the table handler is not actively maintained-- because BDB, as great as it is, was not designed to be a backend storage mechanism for a high concurrency RDBMS.

BTW, InnoDB has a table bloat problem (in that it has trouble removing dead tuples) which can be quite serious if you have a lot of updates or deletes. So for some sorts of installations, InnoDB might eventually have more serious performance issues than BDB (imagine PostgreSQL without vacuuming the DB).

PostgreSQL 8.1 avoids all these issues. The RDBMS is integrated with an autovacuuming capability, avoiding the bloat issues with InnoDB, and it avoids the page locks you have with BDB.

For those who are wondering, in a page lock, a page of data containing a number of rows of data is locked until the transaction times out. This essentially locks all rows stored near the row that is updated.

What is it with technology and cutlery?

[jd]

Microsoft wants to knife the baby, OSS projects do fork (though not as often as Microsoft would have you believe), and Slashdot postings invariably have spoon(erism)s. In that case, to produce good, clean technology, all we have to do is build a dishwasher the size of California.

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:With Oracle's products becoming more affordable

[Anonymous Coward]

Yes. Do you really believe that they did this out of the goodness of their hearts?

No commercial vendor will do anything unless they believe it will make them money in the long run. Period, end of story. Oracle wants you to use their products for everything. Easiest way to achieve that, with MySQL and PostgreSQL out there for free? Give away a low end product. Let people tinker at no charge. Start charging them when they need the more powerful product.

Hook 'em early, and slug 'em when they're hooked. It works at pretty much every level. Oracle is moving along a very well worn path. How well it will work, remains to be seen.

Does mysql support non-literals for default values

[Anonymous Coward]

I ran into an annoying situation just yesterday trying to modify some code that 'depended' on mysql. I wanted to know WHEN a record was made in a certain table..

Quick and dirty solution was to add a column with the default value of CURRENT_DATE().. Too bad that didn't work. There is even an entry in the mysql bug database about it that date back years..

http://bugs.mysql.com/bug.php?id=1696
http://bugs.mysql.com/bug.php?id=2040

More retarded is that the lovely people on the mysql dev team have those classified as 'feature requests'.. Its not a feature request, its just another fundamental aspect of mysql that is missing and the type of attitude the mysql team has for missing features is just laughable(anyone remember reading the old mysql docs that talk about how useless transactions are and that you would never need them?)

I had to spend 3 hours(no joke) dissecting the code to have it insert the current date into the record I wanted, 3 hours I will never get back.

Thats just typical of every encounter I have had with mysql.. some annoying stupid feature I take for granted just isn't there.

Re:Not silly at all

[StrawberryFrog]

database that requires multiple tables related to each other.

That means, "any database" pretty much.

The claimed capabilities of that system, implementing a very relationally complete system, would bury even Oracle eventually, if not immediately

I don't think anything short of global nuclear war could "bury Oracle immediately". The installed base of very big DBs on Oracle is just too large.

If the company building the Trans-Relational database ever gets off the ground...

Does anyone have links or insight on this "Trans-Relational database" that I've nevre heared of, why it's so much better at "relational theory" than Oracle, why this is such a winner?

Re:The real problem

[ComputerizedYoga]

technically superior, sure.

But ... umm .... what's the word I'm looking for?

Oh yeah. Slow.

MySQL's got three big great things going for it: raw disgusting speed, relative simplicity to set up and administer, and the whole dual-license thing. Oh, and with innodb and with the 5.0 release, very nearly everything in the "technically superior" category (as far as most people are concerned) is covered. A lot of the things people bash mysql for are really complaints about the shortcomings of MyISAM instead. Oh, and don't forget that SO many websites and open source tools are built on top of the LAMP stack... and people wonder why it's talked about so much? Really, what's not to like?

Postgresql has relative simplicity to set up and maintain, but I don't think is quite as straightforward as mysql. And, as far as I've been able to tell, the speed just isn't there. We all love BSD licensing, and it still has some technical strengths over mysql, but the biggest issue is still speed, and all the benches I've seen still put mysql ahead on that one. (Besides, who's ever heard of the "LAPP" stack, and does it have something to do with strippers?)

Oracle, on the other hand, is already pretty fast and scalable, but non-free, non-f/oss, and generally an order of magnitude or two more complex to set up and maintain. In an organization large enough to have a dedicated database administrator, it's great, but it's not really suitable to be the database behind something like my weblog, or behind a small business's basic website.

Re:Which Database?

[Anonymous Coward]

Look at the licensing for Oracle 10g Express and you'll see that it is limited in terms of CPU and memory utilization and database size. The limitations still allow it to be useful for development and a number of small systems, but it would preclude 10g Express from replacing MySQL for situations like we have where MySQL is a back-end db for a variety of web apps (forum software, webCMS systems, weblog systems, etc).

That being the case, Oracle has done a nice job with 10g Express. The web admin interface is quite nice and the install is a breeze. We run Oracle for our ERP systems and 10g Express provides a good database for our developers who work offsite to install on their home systems.

If we weren't an Oracle shop, I don't see any real compelling reason why we'd go with 10g Express over Postgresql even if the admin tools are nicer.

--

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.

Re:Which Database?

[ajs]

I've watched dozens of projects in a handful of companies move from other databases to Oracle. These other databases have included Fame, Sybase, BDB, MSSQL, MS Access, MySQL, Postgress, PostgreSQL, Ingres, and a variety of lesser known databases.

NEVER, have I seen such a project which I would refer to as "painless". Oracle is a monolithic beast which requires constant care and feeding by experts who have been so steeped in its ways that they are prohibitively expensive. Oracle perpetuates this situation and, as best I can tell, deliberately obfuscates their product in order to continue to rake in huge fees for training and services. Mind you, I've done Oracle DBA work in the past, so I'm not talking through my hat, here.

I would never, ever rely on Oracle. I use it as a bargaining tool in project management ("if we hit a wall with PostgreSQL/MySQL/etc. we can always switch to Oracle"), but unless there is a practical reason such as customer requirements which cannot be altered by me, I dodge it, and I would suggest that others do the same.

This has nothing to do with petty in-fighting about what feature-set is better. This is about a company that makes its money by abusing its customers. Why would you stand for that, even if it means giving up some feature, or working harder to implement some feature with a different tool? I would rather hire 5 MySQL or PostgreSQL engineers that work on expanding their feature-sets full-time, than pay Oracle a licensing fee.

Whistling in the dark

[ppanon]

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.'

That's true enough, and yet MySQL uses GPL for its free Linux version but a different licence for the Windows version, don't they? They can't just pick up InnoDB and roll it into their Windows release because they don't hold the copyright to be able to release Windows InnoDB under their Windows licence. So, if Oracle kills InnoDB (or starts increasing the price for non-GPL releases) MySQL might have to revisit its business model.

I always liked PostgreSQL better anyways.

Re:The real problem

[jadavis]

I meant that I didn't know how it differs from the standard double-quote. Backtick seems to do the same thing as what the standard says a double-quote should do, so why don't they use the standard?

That's what seemed silly to me. I'd be interested to hear the reason for the use of backticks versus double-quote.