Slashdot Mirror
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.'"
I am really looking forward to disk based clustering in MySQL. I have tried the NDB clustering, but the hardware requirements can be hefty. I am also curious about performance in this area. Contrary to what one might assume, the in-memory clustering is generally slower than storing the files on disk. I am curious how the disk based clustering fares compared to NDB clustering and a traditional on-disk MySQL DB.
Do they still insist that simply connecting to the server process requires a commercial license if you aren't GPL?
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!
Probably less than slashdot got for this one
I am trolling
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.
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.
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.