Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



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:
  • Re:Uhm (Score:4, Interesting)

    by philspear (1142299) on Monday December 08, 2008 @08:45PM (#26042283)

    So tell us, what exactly IS yourSQL?

  • by nluv4hs (1422261) on Monday December 08, 2008 @09: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 @09: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?

  • Same old, same old (Score:1, Interesting)

    by Anonymous Coward on Monday December 08, 2008 @09:44PM (#26042751)

    Sun buying MySQL is no different than Microsoft buying FoxSoft. Fox Software created Foxpro, a dBase-like database system. Not a true database, but something you could put a lot of data into. Fox Software sold Foxpro to Microsoft. Microsoft already had (has) MSSQL. First release after Microsoft got their hands on it: it could only store 1/500 as much data as before, and suddenly it got slower. It isn't completely dead yet, but no development has been done in 14 years. So its exactly like Sun and MySQL -- Sun bought MySQL to kill it.

  • by JambisJubilee (784493) on Monday December 08, 2008 @10:33PM (#26043075)

    I can also make a query which makes MySQL look better the PostgreSQL. What's your point?

    Okay... so what's your query?

  • innodb != fast (Score:2, Interesting)

    by Anonymous Coward on Monday December 08, 2008 @10:41PM (#26043127)

    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 it's going to be fabulous. Try it.

  • Re:Uhm (Score:2, Interesting)

    by daeg (828071) on Monday December 08, 2008 @10:46PM (#26043149)

    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.

  • by QuietLagoon (813062) on Monday December 08, 2008 @11:00PM (#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:To their credit (Score:2, Interesting)

    by domatic (1128127) on Monday December 08, 2008 @11:04PM (#26043247)

    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 Monday December 08, 2008 @11:04PM (#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:To their credit (Score:3, Interesting)

    by StuartHankins (1020819) on Tuesday December 09, 2008 @12:44AM (#26043743)
    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 placement of indexes on separate filegroups etc. Oh, and no data loss. And while it's importing / exporting the MySQL load on the server is minimal -- I'm accustomed to seeing it 90%+ idle at that time of the morning.

    Granted, I use a small portion of its features, but even things like the ability to load data and have it either replace or append as needed saves another pass per table. With my tiny maintenance window this really helps.

    YMMV though. Maybe because I stay a version behind bleeding edge (5.0/5.1) it helps?
  • Re:To their credit (Score:3, Interesting)

    by Jellybob (597204) on Tuesday December 09, 2008 @06:10AM (#26045025) Journal

    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.

  • by Anonymous Coward on Tuesday December 09, 2008 @09:39AM (#26046325)

    The query is stripped down to the bare essentials, but I'd guess he's trying to track what countries his web visitors are from. The table in question (address) has ~2000 rows, each row with 1 32-bit number. That works out to 3-4 pages. At that size, using an index is detrimental to performance. Maybe it doesn't affect you, or most MySQL users, but MySQL's planner/optimizer sucks when you get beyond sql 101.

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

    by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Tuesday December 09, 2008 @09:42AM (#26046355) Homepage Journal

    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 moderation events. Now, compared to Slashdot's huge viewing traffic, that's practically read-only.

    Tens of thousands of hits per day.

    On a site that slow, you (probably) won't see corruption any time soon.

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

    by Just Some Guy (3352) <kirk+slashdot@strauser.com> on Tuesday December 09, 2008 @09:48AM (#26046437) Homepage Journal

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

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

    by Slashdot Parent (995749) on Tuesday December 09, 2008 @11:26AM (#26047665)

    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 moved the frickin' database file right out from under a running MySQL server to another volume. No data loss.

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

"'Tis true, 'tis pity, and pity 'tis 'tis true." -- Poloniouius, in Willie the Shake's _Hamlet, Prince of Darkness_

Working...