MySQL A Threat to Bigwigs? 505
Disoculated writes "Is MySQL a threat to bigwigs? is the question asked in CNN's technology section. The article notes that MySQL is running perhaps 20% of the web databases but its revenue is merely 0.02%... yet the company is still making money and putting out an excellent product. Is this a sign that the database market is in for a drastic change? Of course, there's no mention of PostgreSQL or mSQL, but I guess that's typical."
Cool and amusing. (Score:3, Interesting)
typical (Score:2, Interesting)
Or do you hear of anyone mentioning NetBSD (etc.
- Hubert
I think PostgreSQL is more of a threat (Score:5, Interesting)
On the postgreSQL general mailing list, people rarely talk about mySQL anymore (let along mSQL). It's (mySQL) is generally regarded as a good alternative to the Berkeley DB stuff (i.e. non-relational), whereas postgreSQL these days gets lots of traffic from Oracle people wanting to go somewhere cheaper.
Oracle mustn't be happy, I'd think.
SAP doing a deal with mySQL (Score:5, Interesting)
But the interesting thing is that SAP is currently working on a deal with mySQL, the details of which are unknown to me. If SAP was to throw their weight behind this, it could have a big impact. SAP is currently the world's largest Oracle reseller, and they gave a lot of credibility to Microsoft in the enterprise by supporting SQLServer. Likewise, their refusal to support Sybase was a major blow to that company when they were going blow-by-blow with Oracle.
SAP could be motivated to do this because of their animosity to Oracle, and because Microsoft is encroaching on their markets with the Great Plains and Navision acquisitions. This could be intersting to watch.
SAP DB (Score:2, Interesting)
I wonder who mysql steals marketshare from? (Score:4, Interesting)
I wonder about Sybase and Paradox which seem to be mid to high end of the market which Microsoft really hurt and now so its mysql.
I tried out mysql and its ok but postgreSQL is alot better for a RDBM. Its no wonder that RedHat picked postgreSQL for its database product. In Asia the situation is opposite of the west and all the technical books are for postgreSQL.
I just find it hard to believe its eating Oracle's or IBM's core markets. Mysql is a simple bicycle vs a high end car in comparison.
That depends... (Score:5, Interesting)
Furthermore, there are some applications that just don't make any sense to switch. An example is government databases. I'm working right now with a state government database written on top of Sybase, and i don't think it's ever going to move off of Sybase unless the company tanks. There's actually three pages of (somewhat unfounded) explanations as to why it can't be ported to MS SQL. Mostly bullshit about WACOM SQL being incompatible with Transact (which begs the question, why not just use Transact in the first place when MS' and Sybase' version are about 80% similar). Can you imagine the developers, who have big enough egos to include three pages of MS SQL Server bashing in their docs, redoing their whole bloated app just so it can run on a free environment? Lord no! Not to mention the cost to taxpayers, who have already footed massive bonds to pay the usually high up front costs for software. Think they're going to pay a hundred k for some developers to rewrite everything in a free environment when they could just pay a few thousand for a Sybase license?
Do I think that truly open minded (some would say wise) development houses looking to cut costs on new systems are going to go MySQL? Absolutely. But there'll always be a place for the behemoth server app, not because it's better, but because it's PERCEIVED as better.
Threat? (Score:3, Interesting)
In a job I had to migrate an application done originally in clipper to web/sql/etc, and choosed mysql because I thinked that it will be enough, but if not, the migration to a new sql server will be a lot faster and less complex than the first one.
Re:If MySQL was just a bit more user-friendly... (Score:3, Interesting)
very much so more because you can't even do anything with them if ms decides so that you don't deserve it to work anymore. mysql is pretty much easy enough to install for somebody who wants to have alternative to ms-sql server, however sometimes people don't for very questionable reasons even want to look for change(and i'm not saying mysql would be the only best option either, just that most windoze users can even install it, mysql's website does offer very good docs btw, and i thought support is what where the money mentioned comes in? and the point of the article is that it is __not__ a fringe, experimental db anymore, instead it is very widely deployed).
Re:And the answer is .... (Score:2, Interesting)
It simply have another user base, consisting of web designers that usually don't have the knowledge to handle all those features nor have the expectations to find them. To them transactions and checking of relational integrety only complicates things as they don't even know what it is.
Even if they don't manage to build technicaly good solutions the make solutions that are good enough in many cases. That's why MySQL is so popular in the low end markets.
Once your projects grows and you need to hire database aware admins they will require more features, such as those to be found in Oracle, DB2, SAPdb, Postgresql etc. And as you pay your dba a lot in salery it makes sense to chose a product that you think is well supported even if it cost you a little more.
This is why high end projects go for Oracle or DB2 and not Postgresql, (besides performance issues)
Re:Version 4 Will Tell (Score:5, Interesting)
That isn't to say that I am against using databases, but the overhead of MySQL is often pretty absurd for very simple dynamic websites (hell, a lot of kinds of dynamic web sites) and desktop apps managing a relatively small amount of information. If a DB was integrated into the OS as the preferred method of storing data, with the overhead paid for across many apps in increased convenience, it'd be worth it. But why the hell should I need to install MySQL just to maintain a list of todos and contacts? Look on Freshmeat- there is a torrent of applications using MySQL for managing small amoutns of data, both web and desktop apps.
It's too bad most Linux developers aren't interested in doing something really forward-thinking. If there was a DB integrated into the OS, and apps encouraged to use it, with avenues of data management made easily available to the user, computing could be actually pushed ahead by Linux. But not today, and probably nor ever.
Oh yes, my point: most of these apps would do fine with a flat file or (if one must get fancy) an XML file to manage this data.
Re:Version 4 Will Tell (Score:4, Interesting)
It depends on what you want to do (Score:4, Interesting)
I can't believe MySQL doesn't even have subselects yet. I've been living on subselects and 'connect by' for years. I never did like PL/SQL all that much, but it does allow you to run complex programs over the network without creating high traffic. And SQLNet does make things a lot easier. The whole thing is kind of like a database flavor of Unix, with its own world of commands, scripting tools and permissions.
As for Oracle's 'fancy' products, like Express, Forms, the OID, Portal, and Workflow, they are serious attempts to extend the database principles into a generalized suite of enterprise-level business tools. They are a little too cutting-edge for my taste, but you won't find anything like this in a non-proprietary product.
Re:Version 4 Will Tell (Score:5, Interesting)
The point would be for a unified model of data format, access and storage. No more file format worries. Empowering users to manage and manipulate their data. Easy sharing between apps on the same machine, over the network, across platforms.
The important change isn't in capability but in the way of doing things. Since I do not mean stuck in the kernel when I say OS integration, I simply mean that it would be a core part of the OS used by all applications. Instead of files as we know them. This could be provided by an existing user-space solution, but until there is some standardization the benefits wouldn't really materialize. E.g., it doesn't matter if MySQL is installed on this Linux box on my desk if none of the applications use it.
Why not mySQL? (Score:5, Interesting)
mySQL is, unfortunately, a SQL interface to a bunch of files based on various index sequential access methods. It gets its speed by ignoring transactions, triggers, stored procedures and other things that, when your company is successful, will need in its database. mySQL's replication is also not guaranteed and when its spotty, it doesn't tell you.
The open source DB community is a powerful force with a lot of potential and a lot of success. That success is in markets where transactions are low and/or not critical to the customer.
mySQL and others need to ensure that they have these features:
- stored procedures (implementation outside of the A in ACID aren't complete - perl, java, python, etc)
- Referential integrity, foreign keys, transactions
- hot backups where you don't have to take the database down to get a backup with guaranteed integrity.
- reliable replication (argue away, only shareplex, NT SQL server & Sybase have it today)
- sub selects
- temp tables
- function based indicies
- automatic partitioning
- rollback (true rollback w/transactions)
- triggers
- block and row level locking. A select on
a 50 million row table shouldn't lock
the table.
- joins that do not lock tables due to full table scans
There are a lot of good reasons for using mySQL as a platform to begin the development of a project. For personal use, it's hard to beat! If you are a professional in a company that needs to support real clients with real data with real guarantees, spend your money on a real database.Where do you want to spend your R&D money? On your product or on the database that does most of the things you need, but not all of the things you need. Don't you want to spend your time building the product that pays your salary and makes your customers happy? Why spend time on the database, just buy something that works.
One more thing, a not unreasonable architecture for a database driven application is:
- UI layer
- Business rule/application layer
- Application Programming Interface
- Stored procedures (potentially hundreds)
- Database
Good luck.Re:PostgreSQL has every feature but Replication. (Score:2, Interesting)
I see it as one of the main advantages of MySQL over PostgreSQL is that you are able to turn off transactions if you don't need them.
The main difference between MySQL and PostgreSQL is more 'philosophical'. MySQL does not attempt to hunt Oracle based on features. Instead, the main objective for MySQL is speed. PostgreSQL on the other hand attempts to duplicate as many Oracle features as possible.
BTW: MySQL does support replication well, even in its non-commercial version.
Surprised.... (Score:5, Interesting)
Personally I have seen SQL server most on small/medium size business environments. Any large 'enterprise' sized business deserves what they get if they are dumb enough to rely MS SQL server. Look what happened to Bank Of Americas ATMS when the last MS virus du jour made its rounds.
I think MySQL is the best bet to reduce Microsofts share of the DB market. Oracle is better, but small business isn't willing to fork out that kind of cash, especially in this economy. MySQL is especially perfect for the small business web site, and with Microsoft irrationally increasing subscribtion fees and forcing upgrades, a good percentage of their customers will be running into the open arms of MySQL/Postgres.
Re:Version 4 Will Tell (Score:3, Interesting)
What gives? Personally I only use 3.x.x but that is because the scripts I use were developed for it and don't take advantage of 4 AND I'm not as comfortable with 4, what it brings to the table and what it may or may not break in my setup.
Am I Elitest Yet? (Score:2, Interesting)
Let me backtrack for a moment and say that I'm a big fan of easy-to-use. I like Windows' usability on the desktop, always have, from the beginning (Windows '286). I hate command lines. Easy is good. GUI is good. WHEN APPROPRIATE.
However, I've seen more people screw up database stuff than I wanna think about. Really horrible stuff. People seem to think that datbases are like spreadsheets, that it's easy for a clever newbie to just toss something together and the whole company can start using it. No! Wrong! Bad!
Multiuser databases should not be tackled by folks who haven't had a lot of exposure. There are all kinds of issues to be wrestled with. If a person is scared off by (the reasonably easy) PostgreSQL installation, then we can feel pretty confident that she or he would have made a big mess of a database, and that something super powerful like PostgreSQL would have been a bad move.
One final thing: PostgreSQL is ASTONISHING. So powerful, so reliable, and... free! Wow! Use it! (If you know what you're doing, of course)
Re:I think PostgreSQL is more of a threat (Score:5, Interesting)
I've developed my last application for MySQL. Everytime the server looses power, I have to ssh into client's servers and tell them how much data they've lost (repair table). It's not a happy time, and buy a UPS is not reassuring (most have them, accidentally bumping power switches/knocking cables loose still happens).
InnoDB doesn't have this problem, but then again, it has buggy key problems on all of my servers. Sometimes it can't find a record that is there (often this is worse than just loosing the record... you can't create a duplicate). I have to periodically rebuild the index on inno, so I scrapped it too.
I've used postgreSQL before, and it seems MUCH more robust. It can be a little slower on certain queries, but I'll sleep better after my clients are ported over. I also get updatable views, custom objects, sub-selects, embedded procedures (in a variety of languages), transactions, cross table deletes/updates, and speed when I take advantage of key clustering and these other features rather than hacked solutions for sub-select. I've seen people select "delete from table a where bid=\""+b.id+"\"" from b where c=3 into outfile d; then run mysql -u user -p d
Sure vacuum could be automatic when there is a great degree of fragmentation, but those are scratches compared to the gaping holes in MySQL like ACID compliance. I've looked at version 4, and it changes the queries so much that I would have to port my app to version 4. It's best I go another route than be disappointed again.
It sure does help Oracle migrants that pgplsql is about the same as Oracle's plsql
Re:Missinfg Features (Score:1, Interesting)
No, it doesn't do transactions, doesn't do stored procedures, doesn't even have referential constraints for $deity's sake. But that doesn't matter when you're programming a cheap web app where 5-10 extra lines of code in Perl of PHP can make up for it. Is it the best way to do it, strictly speaking? Probably not, but it works! And it works for really really cheap.
Who's to say that's such a bad thing?
You're overlooking many other database engines (Score:3, Interesting)
In addition, MySQL isn't really all it's cracked up to be. Features such as page-level locking, (used by MySQL) and locking escalation (used by M$ SQL) will degrade performance in a multi-user application. So, while MySQL is great for a web-server, developing/deploying an application that uses MySQL can cause undesired performance degradation when multiple users are simultaneously accessing the data.
SQLite (Score:3, Interesting)
SQLite [sqlite.org] claims to be twice as fast as both MySQL and PostgreSQL, and is more SQL92-compliant and ACID-compliant than MySQL.
Does that mean everyone should drop MySQL and PostgreSQL for SQLite? No. It means you have to evaluate your situation and choose the best tool for the job.
Personally, I've have very good luck using PostgreSQL [postgresql.org], and probably won't ever consider using MySQL until it is truly ACID-compliant.
My Story (Score:5, Interesting)
Re:Version 4 Will Tell (Score:3, Interesting)
MySQL DOES have sub-selects (Score:2, Interesting)
The next version of mysql will also have views.
Re:which one? (Score:3, Interesting)
http://firebirdsql.org
it's had all these abilities for years.
I've had 76GB single-file databases on my FreeBSD machine since last year.
Faster than Postgres on everything but deletes, but it cleans up after itself when postgres just marks pages for deletion during the next sweep.
Same speed as MySQL on insert/update/delete.
Slightly slower on selects, but that's understandable.
After all, it does have:
Stored Procedures and Triggers using the same PL.
Views, cursors, custom datatypes.
Multi-terabyte file handling capacity
Transactional Engine, with full Commit/Rollback.
Full referential integrity
I've had it doing ~300 transactions/sec on my Celery450, so it rocks along nicely.
I've used Mysql, PostgreSQL, SQL Server.
So far, Firebird outstrips them when you weigh all the features and performance.
Sure, you can power huge sites with MySQL, in the same way you can pull a 6-berth caravan with a Daewoo.
Firebird is a 4MB install. Why choose anything else?
BTW. It works a dream with PHP, Perl(DBI), C.
Probably more, but they're the ones I've used personally.
Re:SAP DB (Score:3, Interesting)
SAP DB is a true, tested enterprise database - did anybody out there start using it when SAP open sourced it? Anybody??
MySQL is ACID (Score:5, Interesting)
In my (informal) tests MySQL/InnoDB is less than half the speed of MySQL/MyISAM but still about 50% faster than PostgreSQL for simple and small tasks. That said, PostgreSQL has more features than MySQL and I still prefer it for most tasks.
Re:which one? (Score:2, Interesting)
These databases are extremely fast, loosely typed, support many different table types, support SQL, support multi-valued (columns within columns) versions of SQL, fully ACID, have APIs written for every major language out there. All of these databases usually support two procedural languages underneath which are native to the database. One is called Access/TCL (Terminal Control Language). The other language is ordinarily a flavor of BASIC. The former language is extremely terse, much like RPG. While the latter is much more like writing a GW-BASIC program.
These databases have been around for decades now. They are running in huge environments, processing terabytes of information, have been tested and re-tested, and have been stable for decades.
Check them out if you are interested.
The other shoe has dropped (Score:3, Interesting)
During the last 18 months or so I have run my personal sites with a MySQL back end. I have never had an outage or loss of data that can be traced back to the MySQL servers. I ran it first on Windows 2000, later on freeBSD4.5 and now on a freeBSD4.6 jail. It still works perfectly.
Back when we were still arguing (two jobs ago) about using MySQL, the DBAs usually claimed that you could not trust MySQL because of the lack of stored procedures and the fact that it could not pass an ACID test. Since then I never bothered learning the DB system itself beyond the minimum needed for SELECT/INSERT/UPDATE/DELETE operations, I did not try to verify this on my own. Years later and I am convinced that these DBAs probably read that in a magazine, and that none of them had even seen MySQL running.
After the dot-bomb nightmare nobody in his right mind should be proposing to their managers to spend obscene amounts of money in SQL Server and Oracle licenses just to do simple SELECT/INSERT/UPDATE/DELETE operations. Sure, stored procedures rock but it does not make any sense to spend that much money just for the 1% of your functionality that will be run by stored procedures!
Most of the people I know that use SQL Server don't even know how to write one, and in the last 5 years I have only written two web applications that have more than 1% of their sql operations as stored procedures. And for Oracle it is even worse!
Re:Version 4 Will Tell (Score:3, Interesting)
Re:PostgreSQL has every feature but Replication. (Score:3, Interesting)
For example, imagine that I have a bugs database (which I do; its called Bugzilla). I want to find all bugs where I'm either the reporter, or I've commented. Since bugs can have zero comments, I need to outer join the busg table to the accounts table. With randomly generated data, and 100,000 bugs, 1,000,000 comments randomly distributed among the comments:
select distinct bugs.bug_id FROM bugs LEFT JOIN longdescs USING(bug_id) WHERE (bugs.assigned_to=86 OR longdescs.who=86);
mysql: 3.33 sec
postgres: 14423.07 msec [I can get this down to 11758.74 msec by changing a
config option - I should probably file a bug on that]
(returning 46 rows)
But the thing is that I just want bug numbers. I don't care how many times I've commented, or need to know the contents of the comments. What I really wanted to ask was:
> SELECT bugs.bug_id FROM bugs WHERE bugs.assigned_to=86 OR bugs.bug_id
IN (SELECT bug_id FROM longdescs WHERE longdescs.who=86)
mysql: error
postgres: 137.66 msec
(To be fair, this does need CVS-postgres to be fast. It is, however, possible to create a UNION join to make it much faster, arround 6ms. Thats not appropriate for the generated SQL bugzilla uses, and having the db do the transformation from teh LEFT JOIN requires knowleges of the distinctiveness of bugs.bug_id, and the distinct in the original query, so its not trivial)
Oh, and it took almost 2 minutes with innodb. I will admit to not having tuned the various innodb parameters, plus this was 3.23, so I'm sort of ignoring that.
Queries are often slower, too - as far as I can see, mysql doesn't produce a query tree, but rather a list. If you only have one table, then this doesn't matter, but if you start doing complex joins (and without subselects, you do that more often than you may want to) then it does make a difference. Yes, I know that mysql has subselects in the development version. I'd be interested to see if they have the same speed problems as in postgresql I see it as one of the main advantages of MySQL over PostgreSQL is that you are able to turn off transactions if you don't need them.
You always need transactions. If you think that you don't, then its obviously not important to you if your data gets lost. (You also want foreign keys and constraints, but....) And whilst I don't know too many 'bigwigs', I'm pretty certain that most of them want half of their commited data to not vanish if there's a power failure.
Now, I'm certainly not saying that postgres is always better than mysql, and I'm sure that people can come up with similar examples to the above, but where postgres sucks and mysql blows it away.
MySQL bashers out there (Score:2, Interesting)
There are very good reasons for using MySQL. A need for a reliable, ACID-compliant datastore isn't one of them.
A Few More Details
Instead of performing one complex query that is entirely processed on the database end, MySQL users have to perform 2 or more serial queries that each must go over inter-process or network communication between the app and the database. This significantly reduces the speed advantages of MySQL.
If a series of DB actions need to be performed in a block, MySQL requires each SQL statement to be sent from the app, again in a serial manner, again over IPC or network.
Data invariants must be maintained by application-level code, which requires building carefully-planned abstractions to guarantee integrity (for every means of accessing your DB), and even more unnecessary back-and-forth communication between the app and the database.
Only one user can write to a table at the same time. For web usage, that falls under the category of "pathetic."
The Bottom Line: MySQL is just a glorified filesystem with a SQL interface.
Re:Version 4 Will Tell (Score:2, Interesting)
> cases where MySQL would be much more cost
> effective, and probably better performing as well.
It's remarkable how many shops will choose Oracle, DB2 or SQL Server over MySQL or Postgres for even the most mundane tasks, and choose to pay HUGE licencing fees as a result.
One project that I worked on had the (Web-based) clients sending out parallel requests to a mainframe DB2 backend, and progressively assembling the results in an "intermediary" SQL Server database. Once all the results from the DB2 database had been collated together, the data would then be sent from the SQL Server database back to the client. Although this wasn't a particularly high-throughput app, the sheer quantity of iron that was required for the SQL Server DB boggled the mind - I think it was something like a 4-way active-active cluster - and the SQL Svr licence fees were something over $100k - **for a database that only ever held transient data**!!!
MySQL would have been perfect for this job. It would have saved big bucks on licences alone, then it would've saved more due to its much faster throughput and lower resource requirements. If really necessary, it could've run on hardware bigger than the biggest Intel boxes, which obviously wasn't an option with SQL Server.
Why didn't they go with this? Three words - Microsoft Consulting Services.
MySQL vs PostgreSQL vs MS SQL Server (Score:2, Interesting)
-- MySQL
MySQL's #1 feature is exceptionally simple use and administration. #2 is excellent read performance. If you are building a web site with a simple DB backend, a lot of reads, a few updates/deletes, no transactions, then MySQL is ideal. It may have an infrequent index corruption problem. A couple of versions had a problem of eating all CPU on occasion. But most of the time it just runs. Very easy to learn, nearly 0 maintanence.
The problems start when the database grows in size and complexity. DISTINCT sucks: if a query is large enough distinct just does not work. UPDATE/DELETE don't work with joins. No transactions. Yes, yes, I know, some things are addressed with another table format, some are patched up in 4.0. But it's done at the cost of what I listed above as #1 and #2.
-- PgSQL
PgSQL is the #1 OS ACID-compliant DBMS. It has transactions out of the box. It works. It can be tuned to run as fast as MySQL. But the learning curve is steeper both for programmers and for DB admins. The first thing to learn is VACUUM ANALYSE. If the table has a lot of updates/deletes, do it often, otherwise performance would suck. And I mean really suck. When the the V/A is running, the table is pretty much unaccessible. Pg's aggregates are bizzare. MIN() and MAX() can be programmed around, but if you need COUNT() you are out of luck. Flat out can't use it on large tables because aggregates do not use indexes! Another surprize is difference in performance between queries WHERE
Pg's query planner/optimizer is not too smart. It can be easily confused with variable types. It often chooses wrong indexes. It's about the same quality as the p/o in MS SQL 6.5. Be prepared to spend time tweaking the queries and indexes. On the other hand, the memory cache is too smart. You can't make it read the whole DB into RAM and keep it there. Pg is trying to behave nicely and releases RAM when the table is not used for a while. Which is a bad thing on a dedicated server.
Hopefully, the next release will have failover and replication. And maybe aggregates will be eventually fixed. Then PgSQL can be seriously considered for enterprise-scale projects.
-- MS SQL
Microsoft went a long way from MSSQL 6.5 to 2000. 7.0 and 2000 are pretty much the same. If it were an OS project, 2000 would have been called 7.1 or 7.2. The MSSQL 2000 is a pretty solid product. For an all-Windows shop it works. But the price! The MS SQL server license, The NT Server license, a license for each connection. If you need to access it from a FreeBSD or Linux box, then FreeTDS is needed. FreeTDS has its own issues. MS SQL has a problem with scalability because it's tied up to NT and NT is not available (yet) on massive hardware.
In conclusion I would say that MySQL is certainly no threat to big boys, not now, not in the near future. PgSQL may become a real contender in the next two years. It is already eating into the lower end of the MS SQL market. Unless MS ports the SQL Server to other platforms, it's going to be sqeezed really hard.