Slashdot Log In
Sun's Mickos Is OK With Monty's MySQL 5.1 Rant
Posted by
kdawson
on Mon Dec 08, 2008 08:11 PM
from the say-what-you-want dept.
from the say-what-you-want dept.
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."
Related Stories
[+]
MySQL 5.1 Released, Not Quite Up To Par 175 comments
Mad Merlin writes "It's no secret that MySQL 5.1 has been a long time in the making, with the first beta release being in Nov 2005, but MySQL 5.1.30 has finally been released as GA. MySQL users can expect new features such as table/index partitioning, row based replication, a new plugin architecture, an event scheduler and a host of performance improvements from 5.1." Monty also had a blog post outlining some of the challenges faced in 5.1, including crashing bugs and a beta quality to most new features.
[+]
Five Questions With Michael Widenius 71 comments
volume4 writes "With two MySQL execs leaving Sun in the last week, the internet is buzzing about what is going on at Sun, what is the future of MySQL and what lies ahead for Michael Widenius. Over at Open Source Release Feed, Widenius spoke candidly regarding his split from Sun, the future of MySQL, Monty Program AB, and the open source ecosystem in general."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Transparency (Score:2, Funny)
If code's too transparent you see right through it to the bloody programmers and their coffee and Monster drinks. In fact, you might see into their dark hearts. You'll see little Guitar Heroes and Battlestar Gallacta action figures. Maybe even, gasp!, some Natalie!
Transparency? Shudder!
Debate? (Score:5, Insightful)
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.
To their credit (Score:4, Insightful)
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?
Parent
crashing database == lost data (Score:2, Insightful)
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. Do they have another data store where you can keep your data until the database is fixed?
Sun should be ashamed of themselves for even calling this abomination a database in the first place. The word 'database' carries a whole host of expectations that the product simply does not live up to. A text file makes a better database than MySQL.
We are in a post-rational debate (Score:3, Insightful)
I mean this is mysql here, not a real relational database. Kind of like sloppy cowboy VB coders of yore, MySQL has the same kind of attitude. "If it works, who cares if it is right".
I mean, sure people site "Well, Slashdot, FaceBook, and BIGCO use it, so MySQL is okay". But have those people ever realized how easy it is to lock yourself into MySQL? MySQL is so full of non-standard behavior and
Re:crashing database == lost data (Score:5, Insightful)
> 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.
Parent
Re:To their credit (Score:5, Interesting)
. (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.
Parent
Re: (Score:3, Interesting)
I've run MySQL datase servers on my websites for nearly 10 years without one problem.
I think the discriminator is the ratio of reads to writes. If it's read-mostly with just a few updates here and there, MySQL can (probably) go a long time without serious data corruption. I would absolutely not recommend it on a site with many update. Slashdot, for example, is in the former category. At say 20 stories per day with maybe 200 posts per story, that's only 4,000 insertions to the comments tables. Since it doesn't allow editing, there are no updates involved. I'll throw in another 10,000 m
Re:To their credit (Score:5, Informative)
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.
Parent
Re: (Score:3, Insightful)
Wow, I am speechless. This is one of the best attempts to turn a bug into a feature I've seen in years! You should work for MySQL's marketing department. Now I'm really excited to hear about the creative things one can do with Feb. 31st...
Re:To their credit (Score:5, Insightful)
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.
Parent
Re:To their credit (Score:4, Insightful)
Must be in YMMV territory here. I've been running MySQL behind production Web servers for years, through many iterations of MySQL. I've not once had it "blow a table." No doubt that's been your experience. But I have to wonder if it was MySQL that was the weak point in your configuration.
I've found, and reported, bugs in years past. Those were all in peripheral capabilities though, not in basic data handling. MySQL was always good about addressing them. Haven't hit any since Sun took over.
Parent
Re: (Score:3, Interesting)
I think people are blowing this out of proportion, but in 5 years of using MySQL, I've seen it happen twice.
Once was on a personal site I didn't really care about, the other time was on a site getting tens of thousands of requests an hour. As other people have said, there really is no excuse for dying like that.
Re: (Score:3, Insightful)
The only time I've blown a table, I did something stupid to the filesystem MySQL was running on while MySQL was still running.
I might add, I've been using MySQL since before InnoDB, when it was a glorified query engine for flat files.
It would seem to me that many developers are lazy and expect their tools to do the work for them. People who complain about some of the little MySQL issues (like date ranges) wouldn't be able to write a working C program with compiler errors disabled.
And yes, I think the latte
Re: (Score:3, Interesting)
I've not once had it "blow a table." No doubt that's been your experience.
Here's my problem: the fact that it's even a debating point indicates that it happens way more often than should be tolerated in a database of all things. When people talk about PostgreSQL, they gripe about the (supposed?) lack of replication, but no one complains that they've lost data to it. Same with Oracle: no one loves the price, but it works. SQL Server: hate the lockin, but it works. Even SQLite: not very concurrent, but it works.
That is the reason why I don't recommend MySQL. A database should
Re: (Score:3, Interesting)
Any database can experience data loss. That includes Oracle, SQL Server, and even your beloved PostgreSQL. This can happen for any number of reasons, including (but not limited to) hardware failure, power failure, user error, etc.
Postgres isn't going to help you if you forget a WHERE clause. Oracle isn't going to help you if your RAID is corrupted.
FWIW, I have never had a MySQL database lose data, and I have committed more "user errors" than I'd like to admit. Hell, I once pulled up the wrong window and
Re: (Score:3, Interesting)
I happen to be in a situation where the host system isn't ODBC-compliant so we hosted MySQL on the same box and use custom code to get data out of it. Then I import from MySQL into MS SQL Server. It's very quick for what I do and I haven't had to spend time on maintenance and tuning really like I do MS SQL Server. No table partitioning yet, no manual
Re: (Score:3, Insightful)
I have been criticizing MySQL for years, because of what I perceived as awful stability. I would be the last one to defend them.
That said, MySQL has never ever crashed for me. Not once. But my usage scenario is one of very light load. That seems still more traffic than "The damn thing might not even have a load on it and it will blow up!", so, maybe (please don't get mad, just an idea, OK?) there is a chance that your configuration is in some way contributing to this?
Re:To their credit (Score:5, Informative)
Parent
Nice (Score:4, Insightful)
But what happens if you want to do full text search? Besides, your nice ACID InnoDB kinda backfires when half the tables are using MyISAM, doesn't it? And good thing MySQL lets you know when your nice happy transaction will not roll back properly because half the tables are MyISAM, right?
As I said, what fun is a database server that is consistent or predictable?
Parent
innodb != fast (Score:2, Interesting)
Sure, innoDB gives you transactions, but at the cost of a lot of MySQL's vaunted speed; half of the reason it took so much of the early open source DB business, lo those many years ago (the other being ease of app development.)
I'm a database rube, but even I've left MySQL for PostgreSQL. Try PostgreSQL, just try it. This isn't your old 7.3 postgres anymore, no siree. ACID all the way, kicks InnoDB's butt and is probably faster than MyISAM most of the time for most of your stuff.
8.4 is nearing completion and
Re:Debate? (Score:4, Informative)
Monty went beyond that to suggest that all the company talent was going toward other projects instead of MySQL and that was hurting the quality of the project. So it doesn't seem to be so much about where the quality bar is set and how the company is managed rather than over the existence of bugs. Some of it might be because there isn't a strong enough grasp of how the product is being used to allow for people to make those kinds of value decisions.
More importantly though it's impressive to see a company realize that instead of trying to squelch their development people, letting them say what they want and contribute to the conversation rather than telling them to shut up and get in line is rather impressive. The idea that open source means more than just disclosing code is a key part of becoming a member of the community and it seems like a culture shift in Sun's thinking. Definitely progressive from 5-10 years ago, when this would have been unthinkable.
Parent
What terrible expectations! (Score:2)
It's impressive that a company ships junk and admits it? Since when is that impressive? Boy are you setting the bar low.
Re: (Score:2, Informative)
Sun may be more "progressive" than some, but this statement from the article clearly reveals who's running the show:
"...There were still some outstanding critical bugs, and Marketing and Sales were pressing for a release," Maxia added.
This was "understandable," he said. "The economic situation of Sun was not good, the company had just cut 2,500 jobs, and we needed the new release to boost sales.
Seems to confirm the original complaint.
Re: (Score:2)
MySQL join performance deficiency, 2 orders of mag (Score:5, Interesting)
Re:MySQL join performance deficiency, 2 orders of (Score:4, Interesting)
I'm not really touching this potato, maybe you're running into some quirks / unfortunate query. Just some quick questions:
- Why don't you have a PK / any index in the address table?
- Did you try a different syntax (e.g. WHERE vs. JOIN ON)?
- Did you try setting different indexes? Tried forcing a specific index?
Parent
Re: (Score:2, Informative)
Re:MySQL join performance deficiency, 2 orders of (Score:5, Informative)
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.
Parent
Re:MySQL join performance deficiency, 2 orders of (Score:5, Informative)
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.
Parent
Re: (Score:3, Informative)
The basic idea is that you create a polygon column and create an entry that corresponds to the start/end points for each row in your table, then you can run a query like this:
SELECT * FROM your_table WHERE MBRContains(polyfield, POINTFROMWKB(POINT(INET_ATON('1.2.3.4'), 0)));
As a point of reference, the above query runs in my local DB here in 0.02 seconds for any IP I can throw at it.
HTH.
Re: (Score:3, Interesting)
Okay... so what's your query?
Does anyone ever wonder what.... (Score:3, Interesting)
.
Does anyone remember those Windows 2000 source code comments that leaked a few years back?
We should not punish Open Source for being Open Source. We are a community. OK, more like a family at Thanksgiving, bickering and such.
Re: (Score:3, Insightful)
We should not punish Open Source for being Open Source.
But we should criticize it when they unleash bugs onto an unsuspecting public by mislabeling it "GA".
Re:Uhm (Score:5, Insightful)
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?"
Parent
Re:Uhm (Score:4, Interesting)
So tell us, what exactly IS yourSQL?
Parent
Re:Uhm (Score:5, Funny)
50% more pretentious, runs all the coolest sites in the world.
Parent
Re:Uhm (Score:4, Funny)
If there really was an iSQL it would cost money, decide which SQL statements you wanted to run and how to run them, have no export to other databases but come in a really really flashy box.
Parent
Re:Uhm (Score:4, Funny)
Parent
Re: (Score:3, Informative)
Re: (Score:3, Funny)
Uh... I didn't know yourSQL was actually a thing, I was trying to make a joke.
Re: (Score:2)
So tell us, what exactly IS yourASL?
Fixed that for ya.
Re: (Score:2, Funny)
Re: (Score:2)
Only if you pronounce it MySEQUEL.
Re:Uhm (Score:5, Insightful)
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.
Parent
Re: (Score:2, Interesting)
The problem is, MySQL hasn't had a stable, crash-free release in MANY years. The version you think is stable is only stable with your data set and queries.
Cue Donald Rumsfeld (Score:3, Funny)
prepare to hear about known unknowns
Re:Same old, same old (Score:5, Insightful)
Except that mySQL is open Source, how can they kill the copy that I have on my hard drive and can re-distribute?
Parent
You're a genius (Score:2)
Finally, somebody who can explain when the MySQL binary package installer is broken on a bone-stock Solaris 10 sparc machine.
And, yes, it's totally broken, and yes, I reported it... last year. It simply does not, and CANNOT work unless you chmod a directory in /var/tmp from another window halfway through running.
My God People.
Re: (Score:2)