Forgot your password?
typodupeerror
Databases Programming Software Sun Microsystems IT

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

Posted by kdawson
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."
This discussion has been archived. No new comments can be posted.

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

Comments Filter:
  • by webword (82711)

    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)

    by FranTaylor (164577) on Monday December 08, 2008 @10:07PM (#26042435)

    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)

      by coryking (104614) * on Monday December 08, 2008 @10:24PM (#26042595) Homepage Journal

      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?

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

        • If your database is crashed and is no longer capable of accepting data, how is that different from losing data?

          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

          • by crucini (98210)

            I work at BIGCO. Everything you say is partly true, but:

            I've developed apps on Oracle and MySQL. Cost is not a factor; we get Oracle for free here. And yet I always choose MySQL for new projects. And that is the overwhelming majority preference, among experienced engineers who disagree on lots of other things. Why?

            1. Performance. Even with good DBAs investing a lot of time, Oracle cannot deliver. Remember, we tune our schema and MySQL instance until it's faster than many custom-written datastores. (Obv
          • by juuri (7678)

            (like never using a "JOIN" because it mysql is "faster if you give it small SELECT statements).

            This isn't entirely accurate. And surely not what MySQL themselves recommend. I attended their high performance tuning class earlier this year and there was extensive talk of using Joins and Table Views in 4.x+ because it *was* much faster. Both are expected to be even more improved in 5.X so they want developers to start using them now.

            You really shouldn't blame MySQL for the hordes of new developers who are jus

        • by multipartmixed (163409) on Monday December 08, 2008 @11:44PM (#26043139) Homepage

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

      • Re: (Score:2, Interesting)

        by domatic (1128127)

        MySQL has never been a stable database program. I've never had any other database system that just blows a database table at random.

        I see you've never tangled with FileMaker Pro.

      • Re:To their credit (Score:5, Interesting)

        by QuietLagoon (813062) on Tuesday December 09, 2008 @12:04AM (#26043249)
        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: (Score:3, Interesting)

          by Just Some Guy (3352)

          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)

        by Sentry21 (8183) on Tuesday December 09, 2008 @12:14AM (#26043291) Journal

        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: (Score:2, Insightful)

          by trawg (308495)

          Why do I never have mod points whenever MySQL threads come up?! good post.

        • Re: (Score:2, Insightful)

          by larry bagina (561269)

          There is no year 0.

        • Re: (Score:3, Insightful)

          by ortholattice (175065)

          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.

          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)

            by MikeBabcock (65886) <mtb-slashdot@mikebabcock.ca> on Tuesday December 09, 2008 @10:39AM (#26046319) Homepage Journal

            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.

            • by jlechem (613317)
              Are you serious? There should never just be one stop for detecting shit input. Code should check for it and the database shouldn't allow storing of it. At least if the database stops it and someone forgets to code it because they're obviously not as good as you are they're not completely fucked.
              • At least if the database stops it and someone forgets to code it because they're obviously not as good as you are they're not completely fucked.

                Did you at least ask to subscribe to his newsletter? There's nothing quite as exhilarating as expecting the data to be pristine (it is called "ACID" compliance for those of you who've only ever used MySQL) and then some other guy comes along and adds a new method to your model and ... WHOOOPS!

                Sorry, Bud. You know all 100,000s of those customer transaction record

                • If your app stuck a date of Feb 31st in a customer's record, then your App is to blame. Jeez.

      • Re:To their credit (Score:4, Insightful)

        by wytcld (179112) on Tuesday December 09, 2008 @12:25AM (#26043361) Homepage

        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.

        • Re: (Score:3, Interesting)

          by Jellybob (597204)

          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)

          by MikeBabcock (65886)

          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)

          by Just Some Guy (3352)

          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

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

              But none of those are failures of the databases themselves. I won't blame MySQL if a meteor takes out the data center. I'll blame the heck out of it when I get "Table 'FOO' is marked as crashed and should be repaired" for no apparent reason.

              FWIW, I have never had a MySQL database lose data

              I don't doubt you at all, but my point is that it's happening to some people often enough that people are talking about it. That's wholly unacceptable.

              Also FWIW, it is possible to experience data loss with Postgres, where it is Postgres's fault (as opposed to the RDBMS not being able to recover from some external fault). Example 1 [juniper.net]. Example 2 [postgresql.org].

              Example one was fixed in 2002. Example two only crops up when you've inserted more than 4Gigarows without the (once

              • But none of those are failures of the databases themselves. I won't blame MySQL if a meteor takes out the data center.

                Actually, what you said was "A database should work 100% of the time, for everyone, and discussion should revolve around features or price or support. It should go without saying that it never loses data. That's just not something you should ever even have in the back of your mind.", and I was bringing up those other failure modes to reinforce the fact that you should always have data loss in the back of your mind.

                No one is offering you a 100% guarantee that when you put data into your RDBMS, you will neces

      • Re: (Score:3, Interesting)

        I'm not having any troubles, and I populate several million records each day spread across approx 100 tables without error. I've done this for several years.

        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)

        by blind biker (1066130)

        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?

      • by PitaBred (632671)

        Lose. When data goes bye-bye, you lose it. Loose is what your lips are if they're sinking ships.

    • Re:Debate? (Score:4, Informative)

      by ruin20 (1242396) on Monday December 08, 2008 @10:32PM (#26042653)
      From what I could tell the debate was over how serious the bugs were and how they should or shouldn't be allowed into something that is an official release.

      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.

      • 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)

        by iminplaya (723125)

        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, Informative)

          by datacharmer (1137495)

          Seems to confirm the original complaint.

          Please read carefully the next statement in the article.
          After that phase, there were a lot of bug fixing before Community and Support agreed to a release. (or read the original article [sun.com])

          G.M.

    • Is this unacceptable? Maybe, maybe not. Surely people rarely rely on latest versions of DBs for production code. I'm not in the DB biz any more (and I wasn't really heavily into it when I was) but it seems to me you can't afford to be taking risks, using the latest versions.
    • by Z00L00K (682162)

      It's not debating about a crashing database, but allowing a voice to be heard and not silenced.

      There are certainly problems, but there will always be yet another bug no matter how hard you try. And let them be open about it.

      If you like ignorance - stick with closed vendors like Microsoft.

      What may be debated is if it was pushed into GA too early, and maybe it was. But don't shoot any messengers about that. The real benefits from this is that developers will know more about the issues and can work to solve th

  • by nluv4hs (1422261) on Monday December 08, 2008 @10:12PM (#26042481)
    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 [mysql.com] public forums [mysqlperformanceblog.com], with no response from the MySQL community. Would someone please stand up for MySQL and save it from looking weak here?!
    • by uss_valiant (760602) on Monday December 08, 2008 @10:35PM (#26042677) Homepage

      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?

      • Re: (Score:2, Informative)

        by nluv4hs (1422261)
        Thank you for these thoughtful questions.
        1. The example setup [mysql.com] is intended as a minimal demonstration, so I left out any keys on address.
        2. I played a lot with where clauses, with no benefit. Anyway, shouldn't an industrial-strength RDBMS be able to interpret and optimize the simplest possible range join written as such?
        3. I configured the strongest possible indices on range: 2 unique, 1 non-unique. Yes I tried FORCE INDEX [mysql.com], it made no difference (in execution time or EXPLAIN [mysql.com] output).
      • by Shados (741919) on Monday December 08, 2008 @11:33PM (#26043077)

        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.

    • by Antony T Curtis (89990) on Monday December 08, 2008 @11:13PM (#26042957) Homepage Journal

      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.

      • by nluv4hs (1422261)
        Thank you for this interesting suggestion. I want it to work but I tried what you suggest and I don't see any difference in MySQL's query plan. I created exactly the same tables, except all columns of type int(10) unsigned converted to binary(4). The query plan is identical to the original [mysql.com].
      • by kestasjk (933987) *
        That's silly; IPs are 32 bit numbers, and MySQL has functions INET_NTOA and INET_ATON specifically to allow IPs to be easily stored as integers.

        Looking at his query I'm not really sure what he's trying to do, but it's a full join without join clause or an index on one of the tables which throws up a few red flags. Whatever the guy was trying to do can probably be done in a much better way.

        If MySQL can't do inefficient queries efficiently I don't care. It does efficient queries like the ones that run m
    • Re: (Score:2, Informative)

      by tabrisnet (722816)

      Having experience with this problem, I can tell you that the problem is that MySQL's implementation of b-tree indices doesn't work well for ranges (specifically, it can only eliminate rows on one side of the inequality). The solution is to use rtree indices (GIS functions, 'SPATIAL INDEX').

      I didn't come up with the technique, but I can't find the webpage where I found it. I did end up using it for a geolocation system though.

    • Re: (Score:3, Informative)

      by James_G (71902)
      I'd suggest looking into the polygon type. This [mysql.com] article may be of some use.

      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.
  • by QuietLagoon (813062) on Tuesday December 09, 2008 @12:00AM (#26043223)
    ... the Microsoft developers would say if they were allowed to?

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

      by jadavis (473492)

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

  • I fail to see the problem.

    MySQL 5.1 isn't upto snuff, just ditch it entirely and just use Postgre.

  • MySQL is a decent row store.
    PostgreSQL is a robust relational database.

    Please use and evaluate accordingly.

    I'm actually as excited about Drizzle as I am hard on MySQL. MySQL has tried to grow into something it just wasn't designed for. Drizzle is a project to return MySQL to its strengths of being a simple, fast row store with SQL interface. I have no problem with that, I just object to MySQL masquerading as an "enterprise class" RDBMS.
  • Most of my posts are marked funny, as I am usually in a fairly irreverant mood when reading posts on /.



    I have been using mysql for 5 years(Before that 3 years in Oracle), in hundreds of websites and a few intranets. Some driving huge queries. Some driving simple high volume queries. A few enormous transaction numbers in a few.

    I have never had mysql "Blow a table" once, or any other issue, the exception being failing drives.

This place just isn't big enough for all of us. We've got to find a way off this planet.

Working...