Slashdot Mirror
MySQL Beats Commercial Databases in Labs Test
An anonymous reader writes "Many of the big players now offer free or 'light' versions of their databases, some would call them crippleware. Builder AU compared databases from Oracle, IBM, Microsoft and MySQL, and the open source offering came out on top."
Actually, it's quite true, and if you look at what's actually going on behind the scenes inside the database, it makes sense.
:)
If there's nothing going on in the database, then the 'summary' value that MySQL keeps is probably spot on accurate. But, if there's lots of simultaneous inserts and deletes, then it's really going to be very approximate. Until things are all flushed, the summary may include all the inserts and none of the deletes, or vice versa. If you wanted to make the summary information accurate, then you'd have to establish locks and the like around that summary value, and THAT will slow the database down. As it stands, inserts and deletes can be executed with ZERO regard to each other.
Postgresql has a similar problem, except instead of offering a summary value and informed that it's an estimate, whenever you do a count(*) it actually scans the entire table file looking for 'valid' rows. Ie, count(*) is not instantaneous. I think they were going to address this issue in a later release (or perhaps it's in 8.1 already), but it's NOT a simple thing. However, if you wanted instant answers in Postgresql NOW, you can do it by setting up a trigger on insert and delete, and maintaining your own summaries. This is a performance hit, of course... but you'd get the same, or a similar hit, if the database was maintaining for you.
What the 'big guys' do, I don't know. But... don't knock MySQL for doing something weird
Postgresql, for comparison, will give you an 'accurate' value, but it actually has to create rows: it can't rely on summary information.
Both you and the parent aren't reading what they wrote. SELECT COUNT (*) is accurate, it was SHOW TABLE STATUS that gives the estimate (as it should, IMO).
I just finished reading it, and the didn't run any performance tests (which I would have liked to have seen). They were comparing options, features, prices, etc. The only mention of performance was things like "here are some neat tunable options that affect performance." and "but performance won't scale that well because you are limited to one CPU" (not direct quotes). This article is an overview, not a "lab test". I'm not sure where that came from. The original article says they were "tested" also. They installed all the products and poked around, but no performance numbers were presented at all.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
This is THE most retarded review of modern database systems that I've ever read. From the moment I read the overview of MSSQL Express, I knew what the writer's opinion was going to be, and that was completely tilted in MySQL's favor. The basic descriptions of product feature were in most cases wrong. One would get the impression from this article that a major RDBMS would always allow dirty reads. And while it's true that you CAN do that, it is not the default behavior for any of them. It has to be explicity done and you have to go out of your way in your SQL code to make that happen.
It's things like that where you just ultimately conclude that the writer(s) of this article just does not know what the hell he's talking about and doesn't have a basic understanding of the concepts or products under review. It's just more OSS nonsensical propaganda in my opinion. And don't fool yourselves into thinking that an article like this is going to change any IT manager's mind about what DBMS he's going to deploy in his enterprise.
Actually, even the crippled versions of DB2, Oracle, and MSSQL still have the underpinings for advanced features that MySQL doesn't support. From real replication to actual performance monitoring (all three of the big guys provide detailed hooks into the guts of the DB) to support for multiple filegroups and indexes and databases spread across filegroups, the big DB's have features that are important but impact performance.
SHOOT!! you want to see MySQL get its bum kicked on performance? Run a test on a filesystem against MySQL.
Comparing performance among databases is only meaningful if all of the candidates have the features of which you need. MySQL has come a long way, and I use it in production every day, but this is kind of a silly comparison. The free versions of the big DB's are meant to provide an easy migration path to more feature-complete versions; if you use Sequel Server Express and want to upgrade to something that that supports clustering and log shipping, you may your money and get your features. With MySQL, if you outgrow it, you either need to start writing code, migrating to something else, or sitting on your hands waiting for it to get there.
Recap, for those who won't RTFC and want to slag me: I like MySQL. I use it for mission critical purposes in production environments. However, comparing a simpler product's performance to (crippled versions of) more robust products is silly.
Cheers
-AC
This is utterly false.
MSDE is based off SQL Server 2000, which itself a revision to SQL Server 7. MS Access has NOTHING to do with SQL Server (excpet proving nice single DB front ends via ADPs). When your dishonest (or just stupid) so early in a article, you loose your reader.
IIRC, EULAs are considered void in Australia because it's a contract occuring after the monetary transaction. After you paid, there is no way additional conditions can be added.
That's how it should be everywhere.
Slashdot anagrams to "Sad Sloth"
Lab test? What test? This was a list of features from the product documentation. What a disingenuous title.
Slashdot - where whining about luck is the new way to make the world you want.
If you want to distribute MySQL with your application to a customer, you have to pay a license fee. That means that for many people, MS SQL Express may be better.
If I wanted to do some complex database logic, I'd probably consider MS SQL Express, as stored procedures on MySQL haven't been out there for long.
If you are building a database to go on low-cost LAMP hosting, MySQL does the job well.
For a piece of shareware requiring a small database, something like SQLLite is probably better than these options.
And that is fixed year ago...