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.
Hmmm
By Chris Wareham
Posted Friday 29th February 2008 11:15 GMT
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.
Postgres an "alternative"?
By Andrew Poodle
Posted Friday 29th February 2008 12:02 GMT
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
@Mr Poodle
By Charlie Clark
Posted Friday 29th February 2008 12:45 GMT
"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.
@Andrew
By Bas Scheffers
Posted Friday 29th February 2008 14:01 GMT
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.
This could be big... maybe.
By Steve Mueller
Posted Friday 29th February 2008 17:17 GMT
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.
@Steve Mueller
By Anonymous Coward
Posted Friday 29th February 2008 21:32 GMT
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.
And have you seen the initial memory requirements for MySQL?
By Roger Merchberger
Posted Sunday 2nd March 2008 01:24 GMT
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!
Application Support?
By Anonymous Coward
Posted Sunday 2nd March 2008 08:02 GMT
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.
The period for commenting on this story has finished
Find out how Trolltech has made it easy for developers to implement web content directly into their native applciations through the integration of the WebKit rendering engine.