Sun's Mickos Is OK With Monty's MySQL 5.1 Rant 155
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."
Re:Uhm (Score:4, Interesting)
So tell us, what exactly IS yourSQL?
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?
Same old, same old (Score:1, Interesting)
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.
Re:MySQL join performance deficiency, 2 orders of (Score:3, Interesting)
Okay... so what's your query?
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 it's going to be fabulous. Try it.
Re:Uhm (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.
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:To their credit (Score:2, Interesting)
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)
. (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)
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)
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:MySQL join performance deficiency, 2 orders of (Score:1, Interesting)
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)
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)
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)
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].