MySQL Criticisms

csn

I was recently looking at Mysql's Wikipedia page. Included is a section of criticisms:

MySQL recently (2008) released version 5.1 with 20 known crashing and wrong result bugs in addition to the 35 present in version 5.0.[22] Critical bugs sometimes do not get fixed for long periods of time.[23] An example is a bug with status critical existing since 2003.[24]

MySQL shows poor performance when used for data warehousing; this is partly due to inability to utilize multiple CPU cores for processing a single query.[25]

MySQL does not offer a single table type ("storage engine") offering all features; the two most common types, MyISAM and InnoDB, do not completely overlap in their feature sets.[26]

Previous versions of MySQL did not support many standard SQL features, with the manual claiming that they were unnecessary or would hurt performance.[27] Even now, MySQL has many limitations that other RDBMS software (e.g. PostgreSQL) does not, such as the inability to refer to a temporary table twice in one query[28] and extremely poor subselect performance.[29]

The developer of the Federated Storage Engine states that "The Federated Storage Engine is a proof-of-concept storage engine",[30] though it was included and turned on by default in the main distributions of MySQL version 5.0. Some of the short-comings are documented in the "MySQL Federated Tables: The Missing Manual".

Monty's post related to all the bugs sure doesn't inspire confidence.

Also, the alphabet soup of storage engines is confusing:

Native storage engines (MyISAM, Falcon, Merge, Memory (heap), Federated, Archive, CSV, Blackhole, Cluster, Berkeley DB, EXAMPLE, and Maria)
Partner-developed storage engines (InnoDB, solidDB, NitroEDB, Infobright (formerly Brighthouse), Infobright (Open Source))
Community-developed storage engines (memcached, httpd, PBXT, Revision Engine)
Custom storage engines

Are MyISAM and InnoDB still considered the de facto storage engines?

I also noticed that PostgreSQL's page doesn't have a criticism section. Which I infer to mean it's perfect. 🙂

Weedpacket

csn wrote:
I also noticed that PostgreSQL's page doesn't have a criticism section. Which I infer to mean it's perfect.

It was taken out (see the discussion).

But in 2000 I was picking a DBMS. Looked at PostgreSQL and MySQL; PostgreSQL was far and away the more mature product so I picked that. I've had no credible reason to switch since.

Bjom

MyISAM and InnoDB ARE the defacto storage engines.

The criticism above concerning these two ("does not offer a single table type ("storage engine") offering all features") seems to me a bit non-sensical:

Both have different strengths and were developped with a different goal in mind. You have a choice there and can optimize your DB by choosing a storage engine on a per table basis. That's a nice feature, not a bug.

MyISAM is very fast and fit for anything were you do mostly (or better ONLY) reads from the table, so if that is what you need: you'll get impressive speed. As everything in life, this speed comes at a price: MyISAM lacks support for transactions among other things (see this wikipedia article) making it a bad choice for anything that needs to be extra-secure.

InnoDB on the other hand has all the relational niceties that you would normally expect, but speedwise it's just 'normal'.

As for the other points: these are a few and there are more, but mySQL is doing ok, I guess...

Bjom

csn

Bjom;10913149 wrote:
You have a choice there and can optimize your DB by choosing a storage engine on a per table basis.

Yikes. Can't imagine trying to distribute such an app to others. OK, you need myisam for these tables, innodb for these, berkeleydb for those, ...

Rather just stick with PostgreSQL and not have to deal with all that. Far as I know, PG's one and only "storage engine" is just as good as, if not better than, any and all of mysql's.

Bjom

Well you dont HAVE to use that feature and can stick to InnoDB for all and everything.

Postgress' storage engine cannot compete with MyISAM when it comes to reading speeds (that is the base for the myth of postgress being slow and mySQL being fast). As their use is limited this is not a general factor for comparing both DB systems, but anyway that IS as strength of mySQL since there are a number of cases when you just need that.

As for deploying ...shrug... doesnt seem like an issue at all.

Bjom

csn

Bjom;10913258 wrote:
Postgress' storage engine cannot compete with MyISAM when it comes to reading speeds

Got data to back that up? I've never had performance problems with PostgreSQL.

there are a number of cases when you just need [mysql]

What exactly would those cases be?

dagon

narg the horse has been beaten to death, want speed test google it, want comparison tables google that, unless any one has nay thing NEW to add to the debate what's the point.

csn

I googled it and found that PostgreSQL beats mysql, hands down, all the way 'round. narg.

Bjom

google again narg

you got me wrong the statement that you (mis) quoted. I wanted to say: there are cases where you just need [raw-reading-speed because you read only and dont write]

csn

In that case, sounds like a bunch of html pages dumped from a database would provide the best performance... narg.

Bjom

yup. youtube must have got it all wrong.

Weedpacket

http://labs.google.com/papers/bigtable.html

csn

Bjom;10913435 wrote:
yup. youtube must have got it all wrong.

Obviously. I think I just read that YouTube is bleeding $500M a year or thereabouts. They'd be profitable if they used PostgreSQL.

csn

Weedpacket;10913457 wrote:
http://labs.google.com/papers/bigtable.html

Are you saying they use that as a storage engine for mysql? I've always wondered about Google's backend...

Bjom

Thanks for that piece of info, weepacket, I wasn't aware of that at all. Interesting read. they...omgooglefied it...

Weedpacket

csn wrote:
Are you saying they use that as a storage engine for mysql?

No, not for MySQL: they don't use MySQL for the major stuff. Check out the Google File System, too.