Feeds

back to article Sun does Google's dirty work on MySQL

Sun Microsystems will fine tune MySQL for some big-name customers unwilling to get their hands dirty supporting the open source database themselves. Google, a MySQL user, will be among those benefiting from Sun's engineering expertise and resourcing to help improve the database's scalability and performance of its storage engine …

COMMENTS

This topic is closed for new posts.
Bronze badge

Multi-processor

I don't think Falcon is really going to make a huge difference to scalability, although it should improve things at some levels. The problem is that the data structures lead to IO bottlenecks in environments with multiple writers.

I'm also concerned that MySQL is moving more towards the proprietary side of the fence. The more it does this the more I feel like either looking again at Postgres, or moving to Sybase or DB2 who don't have scaling problems.

0
0
Bronze badge

Hmmm

Sod scalability, MySQL needs to stop corrupting data when tables go beyond a couple of GB. It also needs to be better documented (for example, clearly noting that changing InnoDB cache parameters will quite often drop all your indexes and foreign keys - a bug I guess, but one they should document if they're incapable of fixing it). They should also They also need to put a lot more work into the query optimiser, as anything involving substantial joins will fallback to full table scans far more readily than any other RDBMS I've used. Better ANSI SQL conformance, and an end to silent truncation or conversion of input (often to invalid values in the case of dates) wouldn't be amiss either.

0
0
Thumb Up

Postgres an "alternative"?

I don't see Postgres as a direct alternative to MySQL. Sure, there's overlap, but MySQL has and always will have the edge in the web environment where speed and ease of use and installation has been it's strengths.

With so much more web technologies out there, and with the web "platform" becoming more widely used, and more flexible in what it can offer, I don't see MySQL's market being eroded by Postgres to any significant extent.

a

0
0
Silver badge
Flame

@Mr Poodle

"MySQL has and always will have the edge in the web environment where speed and ease of use and installation has been it's strengths."

You obviously haven't tried PostgreSQL recently regarding ease of installation. As for the rest: speed may vary wildly depending on your data model - PostgreSQL usually runs faster for me - but the main reason for any RDBMS should be data integrity and PostgreSQL is ahead there by miles.

0
0
Stop

@Andrew

Andrew, that would have been +1 insightful if MySQL was actually faster or easier to install and use.

And that's not me making that up, that is visible from published SPEC results. (http://www.spec.org/jAppServer2004/results/)

I happen to regularly meet the Sun guy that does all this testing (http://blogs.sun.com/tomdaly/) and know for a fact he doesn't have a bias. He actively works as coder on both, to try and make them go faster, regularly submitting patches.

Speed wise there isn't that much between them, though Postgres still has a massive edge on 4 cores or more, MySQL can't take advantage of those.

Also, on Linux it is the same, but the Windows installer for Postgres is actually better than MySQL's. (which might be taste)

The only thing MySQL has going for it is the enormous amount of books written and the ubiquity it seems to have because of LAMP. Which is strange because with the dual license MySQL isn't exactly free. (as in speech) Plus there are lots of options you have to pay for, like a thousand Euros for online backups in InnoDB!

So no, Postgres won't eat too much into MySQL's market share soon, but that has nothing to do with speed, technical ability or ease of use.

0
0

This could be big... maybe.

You know.. years and years ago, Sun could have purchased the likes or Oracle outright...

Sun is one of the largest server vendors that have oracle put on 'em...

If they pull this off, and scale MySQL out the wahzoo... it could take a nice byte outta Larry's wallet.

Perhaps not some die hard Oracle shoppes... but certianly make for a heck of a middle ground to fairly high-end database. Just off the top of my head... I can think of a handful of ways this would make my work a whole, whole lot easier.

0
0
Thumb Up

@Steve Mueller

Nice comment, but I would have thought it would be much easier to take up Postgres as an Oracle beater, as thats what its made to be.

0
0
Go

And have you seen the initial memory requirements for MySQL?

Last time I compiled from source, PostgreSQL used 22Meg (including VM needs) of memory - MySQL? 115Meg! Given several hours, I was able to get that trimmed down to about 35Meg... but still. The reason for MySQL way back when was "small & fast." Now it has neither...

Makes me glad I started with Postgres all those years ago, and stuck with it; for me, MySQL has nothing but disadvantages now.

Laterz!

0
0
Thumb Down

Application Support?

Large Enterprises tend to make strategic database decisions, and these are usually driven by the apps that run on them. People buy Oracle not just because it's fast, but also because it's so popular they know there will be several apps in a particular solution area capable of running on them, giving them a choice of vendor.

I can't help but think Sun should be going after Enterprise Software Developers in the Information Management camp in order to make inroads into Large Enterprises. E.g. ERP, BI, MI, ECM type vendors to help reduce their price point in the required underlying database, but give MySQL at the same time Enterprise credentials in the market. (I.e. the JBoss vs. WebLogic/WebSphere argument)

The software we sell at work runs on MS SQL Server (Enterprise vs. Ubiquitous, anyone? ;o) ), Oracle and DB2. I don't think I've ever heard of a deal being lost because we didn't support MySQL/Postgres. Funnily enough, this is probably because our customers realise that no Enterprise solution vendor for our type of software supports those two DBs.

0
0
This topic is closed for new posts.