Slashdot Mirror
Google Releases MySQL Enhancements
An anonymous reader noted that "Google has released its internally developed enhancements to MySQL to the open source community this week. Changes include improvements in replication, high availability configuration, and performance." It'll be interesting to see if the changes they made are of interest to other places using MySQL.
I was curious what the actual changes were, so I went a looked...
Why am I not surprised?
* mypgrep.py - a tool, similar to pgrep, for managing mysql connections
* compact_innodb.py - compacts innodb datafiles by dumping and reloading all tables
* patches - patches to add features to MySQL 4.0.26
Dumping and reloading all tables?!? That must be one of the "enterprise" features MySQL boasts about?
Well, that's saying something, because from my point of view SQL Serer's admin tools suck.
I mean honestly, a database that's supposed to be for the enterprise, but it lacks even rudimentary log analysis tools?
Also, way too much of what go's on in Enterprise Manager is undocumented. Oh, the way to do it in the GUI is documented, but under the covers it is impledmented with undocumented Transact SQL. The reason this matters is that making changes on production databases through a GUI gives me the willies. I'd rather write a script I can test, then know exactly what is done, not be at the mercy of a slip of the mouse. If your mouse does slip, you may never know why something happened, due to the above mentioned lack of log tools.
I'm not anti-GUI. GUI has its place, for example in prototyping. But when getting it right matters (or when finding out what went wrong matters), you want to be able to do everything in a script. It's nice to have a GUI, but its essential to have well documented scriptable operations for everything you might want to do.
I think it is interesting to compare MySQL to SQL Server, because they have analogous natural niches. SQL Server is a good choice as a simple backing store to an application created in Visual Studio. MySQL plays a similar role in the LAMP stack.
SQL Server is not a good choice for situations where many different applications use the data, especially if the way they use the data requires sophisticated relational functionality. It isn't that SQL Server is quirky, although it is. It isn't that SQL Server's treatment of advanced queries is flaky, although it is. It isn't even that SQL Server only gives you the crudest of physical DBA options, althogh it does.
The killer management deficit of SQL SErver is the inability to detect problems created by rogue programs, diagnose, and correct them. With a more capable databases, it is often quite easy to undo the damage of a rogue program without resorting to backups. This includes undoing arbitrary deletions and modificatoins of important data.
Everything in a relational database should be undoable in strict choronlogical order to any point in the past you specify. Any sequence of operations should be undoable even if other transactions are interleaved with them, provided no inconsistency results. I have personally extracted all the transactions done by certain people, found out various ways they were screwing up the data, and with a touch of my magic wand made it as if they had always done the right thing.
This is career saving/making stuff we are talking about here. SQL Server flunks. I don't know about MySQL.
There are aftermarket log analyzers for SQL Server. They are a must-have if you run SQL Server. But even so, they are not easy to use. The log file structure in SQL server is not structured to support the kinds of operations DBAs need to do. This may be in an effort to eke out a bit more transaction speed: updates to databases aren't just in the database files; the full scope of the change must be reflected by changes to the log file before and after the data file per se is changed. Making the log lest robust could create a significant improvement in transaction throughput.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
a) google is an inexpensive webhost b) google most only have MySQL developers c) who woulda thought the google search engine was developed from WordPress? you're right! no wonder google uses mysql