MySQL 5.1 Improves Performance, Partitioning, Bug Fixes

kylehase writes "CIO.com has a writeup about MySQL's 5.1 release planned for next week. Among the enhancements are many bug fixes from 5.0, some of which may increase performance 20% or more, as well as 'partitioning, events scheduling, row-based replication and disk-based clustering.'"

Comments

It's nearly caught up to PostgreSQL.

[Anonymous Coward]

MySQL has nearly caught up to PostgreSQL in terms of features.

PostgreSQL's Generalized Search Tree (GiST) indexing is still better than anything MySQL has to offer, in terms of performance and capability.

The PostgreSQL OpenFTS full text search engine is another marvel of engineering. It routinely outperforms similar extensions for MySQL in terms of performance, memory usage, and concurrency.

I hope that an upcoming release of MySQL deals with the maximum field size problem. With PostreSQL, there is a max field size of 1 GB. For MySQL, it's a mere 50 MB. For textual representations of certain geographic system data, it's not unusual these days to have individual fields that need to store 500 to 600 MB of data. PostgreSQL handles these fields fine. MySQL fails.

Re:It's nearly caught up to PostgreSQL.

[IversenX]

MySQL fails in many other cases, too.

Many people see MySQL as the consistent winner in database benchmarks. I don't mean this in a bad way, but a lot of people are so focused on the performance of MySQL vs. PostgreSQL, that they forget that MySQL is usually only fast for really simple queries.

That would be fine, though, if it weren't for the failing integrity.

In terms of data integrity, PostgreSQL is kilometers ahead of MySQL. With MySQL, I have seen tables get badly corrupted, sometimes even beyond repair(!) if a disk runs full. That's simply unacceptable.

The syntax is also pretty lax. Adding an integer and a string? No problem. String and a float? Sure.

You want a contraint? Sure, it'll accept that query. Will it honour the constraint? Not so much.

Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. This has the potential to create great data loss.

Inserting a row with a primary key value outside the legal range? It'll give no errors, but it also wont insert the row. Instant data loss.

I know it's popular database, but I would probably not recommend MySQL for any project. If you need something lean and fast, try SQLite. Then you _know_ you don't get any type checks and fancy things like that, so you code for it. If you want to proper, free database, go with PostgreSQL. Half-baked is not my kind of tea. I really hope they will work on data integrity in the upcoming releases, but I fear it's not going to happen.

Re:It's nearly caught up to PostgreSQL.

[chunk08]

1. Pick tea leaves
2. Preheat oven to 400 degrees farenheit
3. Arrange leaves on baking sheet
4. Bake until crispy and dry, but not burnt
5. ???
6. Profit!

Re:It's nearly caught up to PostgreSQL.

[Splab]

While I generally agree with you a few points and additions.

Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. This has the potential to create great data loss.

This is not entirely true. MySQL will revert to MyISAM even though you specifically asked for InnoDB - it will however issue a warning that it is doing so, this of course is a moot point since most application programmers never check for warnings.

And just to feed the flames while we're at it, MySQL will fail to fire triggers on cascading events.

If you got table A and B and C where B references some information in A and C in B all cascades on updates in A, then any update trigger on C (and possibly B) will fail to fire. This is a very big problem if you are using triggers to keep at least some form of consistency.

To top it up most replication services in MySQL are at best flaky, usually they replicate by using the binary log, so if the primary fails you lost the X last seconds/minuttes/hours (depending on setup and load) of transactions. Even if you got the binary log on a GFS you are still in big trouble since the secondary still needs to replay all transactions leading to the failure - I've heard of sites where this was taking minuttes to complete! (This might change in the new version)

Personally I wouldn't touch either PGSQL or MySQL in a mission critical environment, they are very nice toy databases, but when shit hits the fan - and it WILL happen - you need a reliable system with instant failover, which neither database can provide.

Re:It's nearly caught up to PostgreSQL.

[Anonymous Coward]

SQLite really isn't that fast and lean though. It's really only good for tiny data stores (in which case you can use RAM instead). If you take the same data and stuff it in the various DB systems you will see SQLite databases are huge compared to MySQL or PostgreSQL (lots of wasted space). Then there is the performance which isn't bad but not better than the other databases.

Don't get me wrong, I like the idea of SQLite. Per-user databases are needed very badly. I just wish SQLite performed better on normal sized data sets.

Re:It's nearly caught up to PostgreSQL.

[segedunum]

Personally I wouldn't touch either PGSQL or MySQL in a mission critical environment, they are very nice toy databases

I hear this refrain from every terrified analyst who ever wants to bring up the dreaded subject of open source databases, and I see no hard evidence for it. Sorry, but my bullshit detector goes into overdrive when I hear the phrase 'mission critical' and 'toy databases'. MySQL has its shortcomings, and has generally been the web database backend of choice (and it powers quite a few large 'mission critical' web sites), but Postgres really has been the open source database that has kicked on. Failover? Mirroring? Clustering? Yer, there are ways and means of doing that pretty well, and I have seen ample evidence that it can be trusted with lots of 'mission critical' tasks.

I've managed to start using Postgres in an organisation that has traditionally been all Oracle. The main reasons are the huge cost involved of additional licensing for additional servers, the incredible amount of DBA assistance that all Oracle installations seem to need and which they don't have the resources to provide and Oracle's incredible ability to suck any system resources you have into a black hole on any system. When any 'mission critical' database has the memory footprint of either MySQL or Postgres, and when it can actually start up in time for the end of the next ice age, give me a call.

but when shit hits the fan - and it WILL happen - you need a reliable system with instant failover, which neither database can provide.

An awful lot of people have been waiting an awful long time for that shit to hit the fan - and in the meantime it has cost them an arm and a leg in not only licensing and support costs, but also in a needless waste of system and hardware resources.

Re:It's nearly caught up to PostgreSQL.

[Splab]

Might want to get your BS detector checked then.

MySQL fails at some very critical points. As I said in previous post it fails to fire triggers on updates.
Also MySQL believe its better to serve a best effort than a failure - this is probably the biggest NO GO! out there. YOU NEVER EVER do something other than requested in a database. If the transaction model fails you are using no more than an advance file pointer.

Now PG is a very nice database, they got all the right things implemented, and often better than the competition.

PG however does not have any support for scaling, if you want to scale you need some form of middleware to handle it - and currently you have to buy continuent for that - which is a nice product, they however don't support stored procedures and triggers.

And please don't just hit google for PG and scaleability, and come back saying there are all sorts of products out there - most of them are based on triggers and some very bad methods for propergating data - all of them lack the ability to take down primary or secondary server(s) in a running environment and put a new up without interruption in the data flow.

An awful lot of people have been waiting an awful long time for that shit to hit the fan - and in the meantime it has cost them an arm and a leg in not only licensing and support costs, but also in a needless waste of system and hardware resources.

That line alone tells me you got your head so far up your OSS arse you are seeing pink elephants.

IBM Denmark just went down this week for a whole day, pretty sure their big clients are a bit unimpressed in their failure to bring multimillion installations back online.

If postgres can handle your situation then fine, but in my environment a database failure means everything comes to a grinding halt. And when you promise clients 99.999% uptime you sure as hell need subsecond failover *hint you can't do that with anything that reads binary logs from primary* and zero loss of transactions.

Re:It's nearly caught up to PostgreSQL.

[growse]

"Phone Sun" I believe is a reasonable answer to your last point. I also believe they're not the only people who do support.

But you're right - anyone who picks MySQL or Postgres to power a super-resiliant mission-critical service is an idiot. And anyone who uses Oracle to power a non-resiliant low to medium load webservice is also usually an idiot.

Tools for the jobs people, tools for the jobs.

Re:It's nearly caught up to PostgreSQL.

[segedunum]

When multimillion dollar installations fails and you are paying for the support + guarantee on uptime you got somewhere to send the bill if shit hits the fan.

In reality, you have absolutely nowhere to hide and no one else to blame. The downtime still happened, you still have to deal with it and you're the one who picked IBM or whoever. The enterprise vendor doesn't give a fuck because you ponied up the money and you're locked in anyway. The fingers always point at you. Spending other peoples' money in large quantities to cover your ample ass isn't going to help.

What will you do when your PG installation fail? Go on IRC and ask for help?

This is another point that gets made by idiot analysts banging on their blogs. Noting the above, that it is always your fault and your responsibility no matter how much money you chuck at an enterprise vendor, you have to have experienced some of the 'enterprise' support from vendors as I have. The caveats on what they will and won't support a lot of the time are unbelievable. In a lot of cases, Google gives you a faster response and more of a hint at the problem - and I've experienced that from everything from databases to server hardware. By the time a consultant arrives, I know more about what's going on than he does.

Also, I think you save a lot of time, money and stress by putting yourself into situations where dependency on emergency enterprise support is minimised. Just a small hint.

Re:It's nearly caught up to PostgreSQL.

[consumer]

With MySQL, I have seen tables get badly corrupted, sometimes even beyond repair(!) if a disk runs full. Perfect, an anecdote witout details or any way to reproduce the claimed problem.

The syntax is also pretty lax. Adding an integer and a string? No problem. String and a float? Sure. Turn on the strict mode.

You want a contraint? Sure, it'll accept that query. Will it honour the constraint? Not so much. Turn on the strict mode.

Createing an InnoDB table, for (some) referential integrity? Sure, it'll give no errors, but if innodb support is disabled for any reason, it will create MyISAM tables instead, without any hint or warning. That would be a fundamental configuration mistake. You would get a warning, and any time you looked at the table definition it would tell you it was a MyISAM table, not an InnoDB one.

Inserting a row with a primary key value outside the legal range? It'll give no errors, but it also wont insert the row. Instant data loss. Turn on the strict mode. Seriously, this stuff has all been there for YEARS and you have only yourself to blame if you haven't figured it out yet.

If you need something lean and fast, try SQLite. Give me a break. SQLite is a neat project and great for times when you don't want to bother installing a database daemon (e.g. the music database in Amarok), but its performance is terrible compared to MySQL, especially for concurrent access.

When shall we get a decent front end?

[bogaboga]

I am wondering when we shall ever have a free as is OSS, fully programmable front end to MySQL. All the free front ends available suck big time and the non free ones, though somewhat functional, are not available without some kind of restrictions.

In my opinion, the day MySQL will have a fully programmable front end...I mean one that a programmer can add business logic to, program input masks, direct functionality at widget or control level and use to generate customized reports depending on various metrics, MySQL will kick ass. Right now, all front ends to MYSQL suck big time and there does not appear to be an end in sight - sadly.

SQL Maestro is very promising but it's not free!

Re:When shall we get a decent front end?

[NevarMore]

Fully programmable front-end for a database?

You mean like C, C++, Java, Ruby, PHP, Python, OO Calc, ASP, C# ??

Re:When shall we get a decent front end?

[ianare]

Toy database for small, unimportant projects? I don't think so. Access is one of the most stable, reliable, and secure DB systems out there, as the following shows so well:

Among revelations contained in the memos was information that the Microsoft Access database used by the Diebold system to collect and calculate votes was not protected by a password. source

Get PostgreSQL! No, shut up! YOU shut up!

[g_adams27]

I would simply like to point out that this MySQL update is completely irrelevant because PostgreSQL has had (g_adams27, fill this part in before submitting) for a very long time, and MySQL is simply playing catchup.

...

And now I would like to strongly disagree with g_adams27, who obviously doesn't realize that MySQL is an excellent choice even compared with PostgreSQL, and I wish he'd stop making silly comparisons.

...

In response to that, I say: g_adams27, SHUT UP! You obviously don't recognize the fatal flaws that MySQL still has, in that it still can't (fill this part out later) even after years of development. PostgreSQL is obviously the superior option, and you can take your stupid MySQL advocacy somewhere else.

...

Oh, yeah? Well maybe YOU should shut up! I can't say I'm shocked at g_adams27' mean-spirited response, because that's typical of PostgreSQL jerks. MySQL is AWESOME, and YOU need to shut up, jerk!

...

Well, g_adams27, maybe you should take your TOY MySQL and go play with your dollies, while us REAL sysadmins use a REAL RDBMS to do REAL work! Idiot.

...

And now, allow me, g_adams27, to step in to the middle of this debate and simply point out that you're BOTH right, and that MySQL and PostgreSQL are perfectly good choices.

Just doing my part to shorten this thread.

Re:What?!?

[Anonymous Coward]

I don't understand how you can say things like that when HUGE sites like Flickr are MySQL based...and Google uses MySQL code for their DB...

Re:License status.

[Fweeky]

php-mysqlnd is a replacement for libmysql, under the PHP license.

Re:License status.

[DAldredge]

http://www.mysql.com/about/legal/licensing/commercial-license.html The Commercial License is an agreement with MySQL AB for organizations that do not want to release their application source code. Commercially licensed customers get a commercially supported product with assurances from MySQL. Commercially licensed users are also free from the requirement of making their own application open source. When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to or you may distribute MySQL software, you must first obtain a commercial license to the MySQL product. Typical examples of MySQL distribution include: * Selling software that includes MySQL to customers who install the software on their own machines. * Selling software that requires customers to install MySQL themselves on their own machines. * Building a hardware system that includes MySQL and selling that hardware system to customers for installation at their own locations. Specifically: * If you include the MySQL server with an application that is not licensed under the GPL or GPL-compatible license, you need a commercial license for the MySQL server. * If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries. * If you include one or more of the MySQL drivers in your non-GPL application (so that your application can run with MySQL), you need a commercial license for the driver(s) in question. The MySQL drivers currently include an ODBC driver, a JDBC driver and the C language library. * GPL users have no direct legal relationship with MySQL AB. The commercial license, on the other hand, is MySQL AB's private license, and provides a direct legal relationship with MySQL AB. With a commercial non-GPL MySQL server license, one license is required per database server (single installed MySQL binary). There are no restrictions on the number of connections, number of CPUs, memory or disks to that one MySQL database server. The MaxDB server is licensed per CPU or named user.

I'm Already Gone

[segedunum]

We've already started a migration from MySQL to Postgres, and we're not going back. Full Text Searching was one of the features, but Postgres all round just has a lot more to it. You can make the thing look like an Oracle database if necessary, there's auto vacuuming now, asynchronous commits and a ton of other performance improvements that don't skimp on features.

I really can't see why anyone would choose MySQL now, apart from inertia and backwards compatibility.

Re:Decipher for non DB types

[theantix]

- Disk based clustering: I assume this means I can dynamically expand the size of my database by adding more disks. Is this correct? Does PostgreSQL also support this (my project where this would be handy currently uses pgsql)? Disk based clustering only applies to people using the MySQL NDB Cluster product, which is quite different from the traditional MySQL product. So for the vast majority of MySQL users who use MyISAM or InnoDB tables, this doesn't really affect them at all.

- Partitioning: I can think of several things this could mean.. Splitting data among several tables at some logical dividing point. Or, limiting the size of tables so they can't overrun the complete storage space. What does this mean in MySQL 5.1 terms? This means splitting an existing table along logical dividing points, but still acting as a single table. Let's say you partition it by date, well then you would insert/select/update like normal -- but a query or update that looks at the date would only have to look at a smaller partition of the table to know what row needs to be updated.