Sun's Mickos Is OK With Monty's MySQL 5.1 Rant

narramissic writes "Back on November 29, MySQL developer Michael Widenius trashed Sun's decision to give MySQL 5.1 a 'generally available' designation in a now-infamous blog post. Widenius warned users to be 'very cautious about MySQL 5.1' because 'there are still many known and unknown fatal bugs in the new features that are still not addressed.' And now we get Sun's response. In an interview Monday, Marten Mickos, senior VP of Sun's database group, said, 'I learned over many years about the benefits and the painfulness of absolute transparency in open source. A little bit of debate never hurts. This is part of being an open-source company. ... People are free to blog about what they want.' Doubtless, this will do nothing to end the debate over whether Widenius will follow fellow MySQL co-founder David Axmark's lead and leave Sun."

Comments

Re:Uhm

[WillDraven]

While I think the AC may be overstating this a bit, I do think the term 'infamous' is being a bit overused here. Ask any random person on the street about this issue and you're probably going to get a response along the lines of "What's MySQL?"

Debate?

[FranTaylor]

What is the debate? MySQL releases with known crashing bugs. Noone is disputing that.

Is the debate over whether or not it is okay to ship a database with known crashing bugs?

It really surprises me to hear someone from Sun saying that one can debate the merits of a crashing database. If this is the expected level of performance from MySQL, no wonder people shun it. At the very least they could have called it a beta or rc release, that would set the expectation level at something approaching reality.

Re:Uhm

[Anonymous Coward]

We use MySQL in a number of critical aspects of our company. I'd rather have a company be honest and let me know I might have some issues with this new release than pretend there are no issues. That lets me stay with my current version and upgrade later.

Rather be on the stable blunt edge in critical infrastructure, not the bleeding edge.

Re:Uhm

[moderatorrater]

iSQL

50% more pretentious, runs all the coolest sites in the world.

MySQL join performance deficiency, 2 orders of mag

[nluv4hs]

My subject line sounds inflammatory yet see below for hard numbers and a simple, real example. Someone please show me how to coax MySQL to perform as well as PostgreSQL for this simple query (Postgres 496 times faster). It's been over two months since I posted this problem on two very public forums, with no response from the MySQL community. Would someone please stand up for MySQL and save it from looking weak here?!

• mysql forums post: optimize IP range join - postgresql is 496 times faster
• original mysql performance blog post

To their credit

[coryking]

MySQL has never been a stable database program. I've never had any other database system that just blows a database table at random. Nothing is more exciting then having a website go down because one of the tables got marked "corrupt" and you have to go "REPAIR TABLE". The damn thing might not even have a load on it and it will blow up!

First of all, what is MySQL doing that corrupts tables during normal operation and second of all? Seriously, a database shouldn't crash like that, ever.

Second of all, it might as well try to auto-repair the damn table. I mean, I've never had it loose data, only somehow decide the table was "corrupt" and then taken offline. And who cares if you do it automatically and it looses data, this is MySQL we are talking about here! They make no claim about data integrity and the user base doesn't even know what that means (must be a car or some "enterprise" feature used only by NASA and Fortune 50 companies)! I mean, 0000-00-00 is a valid date according to them!

But alas, this is MySQL we are talking about here. I mean, it isn't like you are putting any sensitive data on it right? I mean, surely only a fool would use it for anything besides storing data like "number of shoes in my closet" or "number of purses owned by the wife", right?

Good 'ol MySQL. I mean, what fun is a database server that is consistent or predictable?

Re:To their credit

[carlzum]

If you consider InnoDB part of MySQL, then it has supported ACID compliant transactions for a while now.

Re:To their credit

[QuietLagoon]

MySQL has never been a stable database program.

. (5 insightful???) Well thats kind of harsh.

I've run MySQL datase servers on my websites for nearly 10 years without one problem. Tens of thousands of hits per day. No problems. MySQL is always there, and always working.

I only can wish that my desktop Windows were one-hundreth as reliable.

Re:To their credit

[Sentry21]

Sounds like you were using MyISAM. InnoDB will find and detect corrupt pages - and considering that pages get written into the doublewrite buffer, then written to the log, then written to the tablespace, it's fairly unlikely that things end up corrupt without some kind of disk-related issue.

It doesn't auto-repair table because there can be several issues that could cause that to be a bad idea - for example, a broken RAID controller or faulty disk. If your disk is losing writes sporadically (which I've seen happen), then you'll move from a few corrupt records to a swath of corrupt records.

Re: the date thing, the philosophy was that it's not the database's job to validate data. You could use -00-00 to refer to an all-year event in some kind of astronomical calendaring system, for example, or 0000-mm-dd to refer to something that happened 2008 years ago. If you really want to limit it to a specific range of dates, then you can tell MySQL that, and you can enforce it in your application (or in a trigger, for that matter).

Your rant would have been very apropos ten years ago; nowadays it sounds like you're just holding a grudge because you don't know how it works or what it does.

Re:To their credit

[MikeBabcock]

I'm sorry, I forgot that many developers expect their storage engine to BE their application instead of writing good code themselves.

Shouldn't you be validating your dates or numbers or other values BEFORE sending them to your storage system? Shouldn't the database's job be to store your data in a logical fashion so its easy to find later, and then find it when you query it?

I don't understand people who expect the database to replace the middleware of their application.

Re:MySQL join performance deficiency, 2 orders of

[Antony T Curtis]

You're probably not going to like this answer but....

The data is not in an optimal form for MySQL. Consider storing the IP address as a BINARY CHAR field, and not as a number. Order the bytes so that it is in big-endian byte order. Now MySQL can use it's indexes.

The problem is that MySQL treats index keys as a binary string so if you are using a function to join two tables, MySQL does things the hard way.

Re:Same old, same old

[/dev/trash]

Except that mySQL is open Source, how can they kill the copy that I have on my hard drive and can re-distribute?

Re:MySQL join performance deficiency, 2 orders of

[Shados]

The problem with this scenario and why it will always bother people who are used to non-MySQL RDBMS, is that really, you haven't had to think about things like that in a decade (more if you were giving your first born to Oracle).

Equivalent where vs joins should give similar query plans. If not, since the SQL standard where JOINs are first class citizen state that its what you should use for linking tables (no matter how exotic the JOIN), it should handle that better, and having to force an index is usually a crutch (even Microsoft will often consider it a bug, and the logical scenarios get fixed between versions... in 2000 you had to force em every so often, in 2005 they solved most of them, in 2008 I haven't seen an occurance where the analyzer got it wrong...).

The lack of index in the address table is indeed fairly illogical here, but for such a simple query, most RDBMS will be able to do it fine anyway, -especially- with table statistics. In this case, my pragmatic self would never expect it to be fast, but in most RDBMS, it will still be zippy. The only ones I've personally tried that will choke (even with gigs of data) are MySQL and PervasiveSQL (Pervasive makes MySQL look like the holy grail, thats for sure). I've had douzens of databases with up to 50-100 gigs of data (though it was spread out over at least 75-100 tables, sometimes up to a thousand) with no indexes aside for the primary keys and the systems were fast, on MSSQL, Oracle and Postgres (not saying indexes wouldn't have helped a ton, but it wasn't my decision to take), so its a bit of a culture shock to many when you have to spell out your intent to the database that much.

Re:crashing database == lost data

[multipartmixed]

> If your database is crashed and is no longer capable of accepting data, how is that
> different from losing data? Go ahead and explain that with a straight face.

Well, for example, losing bank deposits is a lot worse than not accepting them because the database is down. This illustrates why in database land it's important to never lose data, and to always know that the contents of your database is correct.

Or, to explain in more detail...

There are known knowns.
There are things we know we know.
We also know
There are known unknowns.
That is to say
We know there are some things
We do not know.
But there are also unknown unknowns,
The ones we don't know
We don't know.

And the unknown unknowns are most dangerous when it comes to RDBMS integrity.