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.
Did they fix that thing where it always sacrifices data integrity for speed?
(I'm not even trolling, I do want to know if they fixed that)
sic transit gloria mundi
Ah, now this is how it's supposed to work. No bull like, "We're releasing improvements as MSN-SQL," or any other nonsense. Yay Google.
Always someone has power over you. The thing to consider is this: Is the power good, or bad?
MySQL is dual licensed so if they add this code they can't sell their product under another license..
Yes, but imagine the world's biggest Beowulf cluster of MySQL servers.
Now imagine them in Google's data centers.
Which, in fact, is where they are. Now do you see?
I think this illustrates a problem with trying to sell OSS as if it were closed source software, instead of relying upon contract work for improvements, customizations, services, and other closed source add ons or using that OSS as a tool yourself for some other market.
What good is speed without data integrity? If I can't trust my data, It doesn't matter how fast I can retrieve it.
If you have a read-only situation there's no need for full ACID compliance. I've seen some contrivances where MySQL reads happen from myASM databases, and the writes go into an InnoDB database, and something on the backend happens to replicates the changes into the 'read-only' databases reliably. I've just never had, myself, an application so speed critical that it was worth doing that instead of doing PostgreSQL for everything. But my use cases aren't everybody's use cases.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Gee, thanks. What about us jack-of-all-trade schmoes who only use the basics and aren't running company wide databases? The amount of data I use the database for is actually quite small, relatively speaking. I run (among all my other jobs) our internal webserver, which means I need to write all the code, including the presentation part, and administer the database.
Sorry, we can't all be gurus, but I still need to back up my tables every so often.
Stupid sexy Flanders.
Well said, not everyone can be the guru of everything. This macho geek attitude of 'If you cant do it in this super efficient, optimal way, you have no business doing it' is very detrimental to the OSS community. I am a software engineer, but I do basic admin stuff too, there are admins in my company who are obviously better than me.. but that doesn't mean that I cant take care of some of the duties too. I dont have to be supremely competent.. just competent enough.
- Tempestdata
Yeah, but the setup time and learning curve is atrocious, and you run the risk of shooting your own foot off.
BigMan, If you're coming from SQL Server, you'd be better off downloading and using Postgres 8.2.4 for windows, from here. PG is BSD licensed, which means you can bundle it with your commercial .NET-based apps for free.
The management interface for PG is on-par with SQL Server Studio; I use both on a daily basis. It's also "20 minutes to set up and start populating data". As an added plus, Postgres has all of the "standard" syntax and referential data integrity turned on out of the box.
You use MySQL if: a) you're developing a LAMP app for an inexpensive webhost that only allows MySQL databases, or b) all of your developers cut their teeth on MySQL and therefore productivity will drop if you ask them to use standard compliant syntax, or c) You're using an app (like SugarCRM or WordPress), the developers of which insisted on using funky MySQL-only features (instead of standard portable syntax) and therefore it's too much work to port to a standard syntax.
In all other cases, you use Postgres or some other commercial database. Postgres scales much better than InnoDB on any combination of a) larger numbers of read-write transactions, b) larger numbers of connections, c) more processors, d) larger datasets (including and beyond 400-500GB).
Cheers, -J