MySQL A Threat To The Big Database Vendors?
geekinexile writes: "Bloomberg is running a story on the growth of MySQL as an alternative to the big commercial database systems." The story mentions PostgreSQL as well, and presents a generally positive view of both.
PostgreSQL is a serious competitor, but MySQL is not. Everytime someone slobbers off about how MySQL is the greatest thing since sliced bread, what they really are doing is yelling "I AM IGNORANT! I AM A FOLLOWER!". I'm not kidding. The basic database functionality missing from MySQL (though always "coming soon") absolutely KILL it in any credible comparison.
This is a dumb article, because what they're really saying is "These morons could have gotten by with Windows 95 and the ODBC dBase IV driver as their, err, relational database driver, so they used that instead of Oracle".
1.4.3.1 Using the MySQL Software Under a Commercial License
(snip)
When you link a program with code from the MySQL software or from GPL
released clients and don't want the resulting product to be GPL, maybe because
you want to build a commercial product or keep the added non-GPL code closed
source for other reasons. When purchasing commercial licenses, you are not
using the MySQL software under GPL even though it's the same code.
-----
This means you can't use libmysql in your closed source code.
If you have a need for the scalability, reliability, high-availability in Oracle (or similar), then MySQL isn't even a consideration.
Maybe someday. But not today.
---
Information wants...you to shut your pie hole.
As the report says, it will take couple of more years before the database vendors will be fearful of MySQL or PostgreSQL.
MySQL, in particular, is missing quite a bit of essential functionality like views and stored procedures that - this is the key - makes it more difficult for other applications to use it as one of the data sources. A lot of enterprise products supports one or more of these expensive databases, and unless those enterprise software are changed to use PostgreSQL or MySQL as the database for it, the big db companies will still have years of guaranteed revenue.
They may be able to take away some of the lower end market, but until the time when likes of SAP and OpenText supports MySQL and PostgreSQL as well as Oracle and DB2, I don't think the db companies will seriously be challenged.
I love MySQL, love the speed, the accessibility, the ease of deployment and its suitability for small and medium-sized projects. I'm an advocate.
... Nope. ASP and SQL Server. I cried my way to the bank.
...
But -- it can be a tough sell to the big fish.
I was hired by a Fortune 500 financial services and real estate company to do an internal project that really was not challenging development. Essentially, the requirements boiled down to a very hobbled version of Slashcode. I bid the project at X dollars, spec-ing PHP and MySQL, figuring that I was going a bit high for the actual hours involved and that I would make a nice roll of dough if they accepted. But I still knew that given the sheer size of the company, that my bid would be considered a bargain, if not a lowball.
What threw it? MySQL and PHP. What are they? (WHAT ARE THEY?!?!?!) Well, we're going to have to get through Standards and Compliance, issue an exception, and well, we'll see, we just don't know. Okay, said I, I'll do it for four times the cost and implement it entirely from scratch using ASP and SQL Server.
Great! Sold. Damn. And you have to understand I really TRIED. I wrote two papers, directed them to a bunch of links
I believe inroads will continue to be made for open source. I have faith. But I think there's still some time and a lot of tireless advocacy to come
Mind you, feeding a bunch of data into a read only system to be queried in a high deterministic way is hardly a real demanding task for a database system
Maybe it's not "demanding" from a RDBMS point of view, but that's what almost all sites do -- read data from a database, and MySQL fits this niche perfectly.
S
You have to remember that this is the kind of thing that MySQL is designed for. Lots and lots of SELECTs, almost no INSERT or UPDATEs.
Which says a lot more about ESR than it does about Big Unix, Linux or Microsoft...
The dirty secret of big databases is that most people don't know how to program them, how to configure them, and don't need most of the features. And even if they get everything right, they still end up with a very costly and complex solution, a solution that likely doesn't perform very well and needs a special DBA to keep it all running. That's why MySQL is successful.
They are two different products with two different uses.
MySql came along and took away the appeal of using text files as data stores for web applications and such - it gave perl scripters a simple, easy-to-understand database that works pretty darn well.
MySQL is a great product, but only for the things it does well. If you try to make it do things that it can't, of course you're gonna get burned.
If you actually *like* databases, you'll probably like PostGres better anyway - don't bother with MySql.
MySql has found its niche. Linux, Apache, Perl/PHP and MySQL are powering thousands of websites right now. I have a few myself and they work well - There is absolutely no need for me to change the database - it just works.
I wouldn't want American Express to start using it today though - they actually *need* the features that Oracle offers.
Not all databases need the kind of bomb-proofing that you can do with Oracle - some applications just need to be able to pull data quickly from simple tables.
The thing that I don't understand though, is why MySql has so much more popular appeal than PostGres - It seemed that one day, everybody just seemed to be using it. Why was that?
Cheers,
Jim
-- My Weblog.
Yahoo is using it for exactly what it's good at: Running websites. Why does it worry you they run their fintantial site? I cam't imagine why that needs something high end. Data comes in one way and gets read many times and that's the sort of use MySQL's raw speed will blow both postgres and oarcle away at.
If it was on something that needed replication, or writes were the common case I could see a problem. But I doubt either is true in this case. Instead it looks like it's being used for an application tht it will handle well.
Yahoo is only being smart; the high end databases
comsume a lot of resources and shouldn't be used where they aren't needed. It would be foolish to run the entire company on a single vendor's software.
...most people don't need Oracle.
Oracle has been used for a lot of projects where it doesn't really need to be used, usually because the company already had a licence, but sometimes because the project was way over-spec'd.
Don't get me wrong, MySQL doesn't even come close to challenging the benefits of Oracle or DB2 in replication, scalability and so on. However, in applications where you don't need them, MySQL is perfect, especially because it requires no monetary investment. (It requires other kinds of investment, of course, but everything does.)
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
The best part is that mysql is integrated well with other free technologies like php and perl, which have been gaining a lot of acceptance. So when you turn to an open-source web solution you're freed from the need (hey, that-- oh you know) to run expensive oracle or sybase (or DB2, I guess I should be fair) RDBMSes. This is especially easy because websites tend to be redundant these days, so they're pretty robust by default.
Anyway, the plan is to add stored procedures and triggers in mysql 5.0. It already does replication, which one expects to improve. It's one-way now. Once these things happen, mysql will just need to undergo some serious testing and possibly some serious bugfixing to ensure stability even under really terrible conditions, and maybe provide a better management GUI, and bango! The big guys will be running scared. At that point, mysql will be able to take over all but the largest installations.
So go mysql! We're counting on you. Oracle costs too much.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
It's sad how all criticisms of MySQL on slashdot are consistently modded down. Although MySQL is a fine product with a lot going for it - there is plenty to be *legitimately* critical about.
Is it that the MySQL supporters on slashdot are only familar with application programming interfaces to relational databases - and so don't understand the differences between a modern relational database and MySQL? Or are they simply pushing the product that they are most familiar with?
I've been involved in purchases of millions of dollars in relational database software over the last sixteen years; been a DBA on Oracle, Informix, and DB2; and developed on those as well as Sybase, SQL Server, Adabas (SAP-DB), Dbase IV, and Access. And I can say that there are plenty of traditional IT applications that I would try Postgresql out on - just about everything in the OLTP arena that doesn't require massive scalability. And unfortunately, there are far fewer traditional IT database applications that I would recommend MySQL for - it simply lacks too many features that are already available in postgresql, and that in the RealWorld(tm) save your bacon.
Ok, you can mod me down now.
(* Having said that, I think that is absolutely ludicrous. PostgreSQL is a serious database system, but, regardless of future potential, mySQL is not. Reading about it running the Yahoo Financial site says more about the quality of the Yahoo Financial site than it does about the quality to the mySQL DBMS. *)
You don't even know what their requirements are! Don't bash something until you see the requirements and environment it will be in. mySQL tends to favor read-intensive activities but is a little weak on write-intensive and transaction stuff.
Perhaps their needs are mostly reading. Maybe some other system dumps the data into mySQL once every midnight, and people query on it all day with little writing.
The point is that you are prematurely dismissing something without looking into specifics.
It is rarely X is always bad and Y is always good. Things have various strong points and weakpoints.
You are acting like a PHB.
Table-ized A.I.
You need to pick a database that suits your needs. For some people MySQL is all that they will ever need. For others, referential integrity, transactions, stored procedures and triggers are a requirement not an option.
I've seen instances where an app was done in Oracle when it should've been done in something like FoxPro v2.6 for DOS, and I've seen apps done in M$ Access97 that should've been done in PostGres/Oracle/Sybase/SQL Server.
Each has its place and should be chosen to fit a business model. Picking a database just because it has the most features is not always the correct solution. Picking a database because it has the least initial cost is also not always the correct solution.
Sure, MySQL is simple. Sure it doesn't do everything Oracle can do. But there are a huge number of small businesses, Churches, scools, etc which don't have huge budgets, have to work with a very limited IT department (In some cases volunteer labor) and need some sort of database capability. Used to be DBase III (And I've seen some HUGE apps implemented in DBASE.) MySQL provides the right combination of features, stability and price to compete really well in that arena.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I wish TPC www.tpc.org would do some MySQL tests and show just how it really perfoms when compared, to DB2, Oracle, and MS SQL Server.
.NET crap is doing this. Imagine XML results sets with heirachy. Tree based joins may also be in the works with this kind of power.
Why can we not put an end to this debate. I wish slashdot would just refuse to repost this crap that people keep saying to see their words be pubilshed.
It is simple, MySQL is a simple db system well suited to web-sites and application where it doesn't really fucking matter. Suppose if slashdot lost a couple of days worth of stories. Is the world going to end, NO, people will be, well whatever that feeling is when you loose data, but life will go on.
If I lost 5 minutes worth of production data, I'd probably have to find another job. People would not get their orders, we might loose a client. If I worked for the NASDAQ, it might mean real $ figures.
People who work in these high stress database positions understand the debate, and probably won't even post anything beause they are tired of it. I know I am. Learn Oracle, or SQL Server and MySQL postgres and then post your ideas, just don't learn MySQL.
Now that is not to say there is no hope for open systems, I sure hope there is because Oracle is expensive, and I hate most big companies. There is a large list of things that Postgres and MySQL have to do. Here are the big ones.
Log based transactions.
Whenever something happens to the data, the change is stored in another file, along with the data file. This way transactions can be rolled back or restored from transaction log backups without a need to restore the whole database. Get a copy of the datbase backup from a certain time and restore every transaction log backup after that and your back to your last transaction log backup. It also helps to replicate a database, and makes true "live" backups possible while a system is live without a huge performance impact, because the transaction log is also backed up, but at the last second, so when you restore the db, you also restore that log backup that was made at the last second while the database was locked.
One data file for multiple tables.
Having a seperate file for each table is like using dbase or paradox. Hell even Access has one file folks. It is needed for mysql and postgres to manage their own "file system within a file".
I think Postgres is going to do this soon according to some of the discussions.
Complete SQL-92 support.
for all the bitching we do about not supporting standards, MySQL seems to think it is all right to say, "oh they'll make it slower". Give me a break.
Locking, Locking, Locking.
This is imperitive for true transaction support. It is also complicated, deadlocks are no fun. But we must be able to do db, table, row, and key locking. This way you can lock down a row for editing, and not allow anything else to mess with it until your current transaction is done. The classic example is the checking to saving account transfer by two people at the same. MySQL and postgres are not as good of Multiuser system as the big boys. Right now postges sends a message to the application saying, this is locked retry transaction, this is just not up to real enterprise levels.
XML support.
This is a new one, but one that is going to rock the DB world. The crappy thing about current tech is that all record sets are 2 dimensional. But if you've ever done more than 3 or 4 one to many joins this can be a big bitch to scroll through. It also replicates data in the result set leading to more memory consumption, network bandwith, etc. MS SQL as part of the whole
Stop saying we will take over Oracle, and take the steps needed to make it a reality.
I've just recently gotten into Oracle out of necessity. It is very very reminiscent of my Novell days.
They are too focused on their appserver and various "microsoft replacement" apps. Documentation is awkward when it exists, and even the smallest things result in a support call to find out about a bug or workaround. It takes even the resident guru days to do what would take a morning for me on a BSD/Apache/PHP box.
The point? It's not that "Oracle is crap". That's clearly not the case. They're just so busy making the database do *everything* that they're going to look up and find out that people are using open source databases instead of Oracle. By then it may be too late. It won't happen overnight....remember that there are plenty of Novell boxes still humming.
It's Oracle's arrogance about the up-and-coming databases that make it a statistical goliath.
The brief history of software is littered with companies that were once of the same mentality as Oracle. They need to stop trying to be the end-all software co. and write some documentation.
I've been using it for quite some time, and I love it since it's nice and easy to use and very fast.
But if you think that it will replace a company like Oracle, you're way off. MySQL is cool, but it can't handle nearly what Oracle or even DB2 can.
Those bigger DB's run the biggest stuff for a reason. There's no way that MySQL (as it is today) could handle the loads that they do. It may happen in the future, but that's a ways off. There is no current threat at all to the big guys.
Sure not everyone that uses the bigger DB's needs their full potential, so some could switch to MySQL. But the biggest databases will stay with the commercial vendors.
But the GPL license isn't a problem, since you can buy commercial licenses for MySQL so that it can be distributed with non-free software. So that's a non-issue.
This is left as an exercise for the reader.
Whether MySQL or Postgres, I don't care as long as open source ends up being a platform for databases. Microsoft can try to portray Linux as a niche webserver platform now, but with a solid foothold as a database platform, open software, as a platform, will be substantially harder to dislodge.
--LinuxParanoid
For package A, it's not really clear that there is a monetary incentive to fix it. Is the bug likely to generate fewer sales or not? The company is motivated by profit only and has to consider the opportunity cost of fixing the bug -- not the needs of the consumer. Package B (almost) always has motiviated engineers and an incentive (whatever that incentive might be) to maximize the package's utility. Package B exists because this is true.
I/O Error G-17: Aborting Installation
It's important that MySQL and other similar open source is free of charge, as it reduces the price of web hosting, as you can get a server for a good cost and everything that runs on top of it is now open sourced. Dramatically bringing down the price of smaller upstarts to host on the web.
MySQL is basically a database as powerful as Access and others with no performance hit whatsoever. It's not that MySQL is an amazing feat of programming (a good one, but not an amazing one) but it shows what a simple database can do when performance is key. Consider /. which is run on MySQL. A personal database powers one of the best sites on the web, bar none...
I jumped at the chance to use MySQL for a large project as a win for opensource. I carefully designed a db that would hold one billion records, as required for my project at work. Well, after a week of importing, when it came time to reindex a field, MySQL's technique was to freeze the table and make a fresh copy (thankfully I had enough room), although the copy took 3 days (during which the db wasn't available). I switched to Oracle and life has been so much better.
In the end, MySQL might handle the raw numbers that some of the big players do, but when you're working with large data sets, Oracle (and presumably others) give you more power. Take the actual physical data structure that Oracle allows you to work with: each database comprises of dynamic multiple variable length data files that can allow tables to span physical disks. MySQL will get there someday, but they're still a little behind.
_______
2B1ASK1
Comment removed based on user account deletion
mySQL is the right tool for *far* fewer jobs than those to which most people believe it applies. Many people end up writing code to deal with various aspects of data management that the database is supposed to take care of because they don't know that the database is supposed to take care of the data.
If you only know mySQL, you will attempt to solve your problem within the limitations of the tool. The problem is that many things can't be done in multithreaded or worse, multi-process application code to ensure integrity. If the DB won't do it, and it doesn't support transactions, then you've just gotta hope people don't ever use your application in a way that will make your data invalid.
I just don't get the appeal of mySQL. The last time I tried it, it seemed more difficult to use than postgres, and it supports a subset of the functionality. I have not done a project that doesn't require at least some basic database feature that mySQL doesn't have in years. Sure, I suppose I could've written code to emulate some of those parts of the database, but certainly not all. For the parts I could emulate, the application would most certainly run more slowly (multiple queries to emulate a subquery or what I do in a stored procedure), and the ones I couldn't would just have to be left out, which would make the applications more buggy (lack of transaction support on applications that run on multiple front-ends would simply cause the apps to fail).
Anyway, basic point is that if you don't understand your problem and/or the tools that are out there to help you solve it, you will solve it incorrectly. It may seem like it's working, but those types of implementations fail really quickly when they go multi-user.
-- The world is watching America, and America is watching TV.
MySQL (or even Postgresql) don't claim to be drop-in replacement for DB2 or Oracle. But they claim to be good enough for simple database tasks, which happen to represent a huge share of the business market (for every high-availability banking application there are a 1000 small databases storing employee holidays, classroom affectation, etc.). These small databases are not only a bigger market in term of quantity (if not in value), but some of them also grow into big databases someday.
Remember when Microsoft was doing MS-DOS, no Unix vendors would have been worried, they had much better capabilities. When millions of PCs were sold with MS-DOS they started worrying. When Windows came out they growed gray hair. Now SQL Server and Windows Server have eaten the market of smaller servers and high-end workstation. This is the strategy of eating your way from the bottom to the top, and it will also work for MySQL and Postgresql : as time passes and as they mature they eat out an ever larger chunck of the database market.
Most database-systems set up by scientific projects I've seen, have been using either Oracle or Microsoft systems. This is of course completely insane considering the need they have, and a total waste of money. Unfortunately many people read a little about databases on sites like /. and start to belive that they are setting up a large database.
After reading this thread, one can easily think that American express is running an averaged sized system with normal demands on security... The truth is that almost no school systems, museums, scientific projects etc. etc. ever need an enterprize solution. An example of the problem is an institut for Marin research in Colombia where they used Oracle. They paid $15.000 each year in licence fees to set up a database for their collections. They wanted to put it on the web and needed to pay $5.000 more. This is a simple task that Mysql, with all it's flaws, easily could manage, and without the need of an experinced Oracle techincian. There are Highschool Linux geeks in Colombia as well...
The overkill in usage of database systems around is probalby enrmous and a very good source of revenue for Oracle and Microsoft. Think about this when you are bashing the lack of advanced features in Mysql. Someone might actually belive you and buy an Oracle licence to run the member database for their local bridge club...
When designing a database application the first decision is where the application logic should be stored. In a large database the choice is to store logic in the database or in the application. There are good reasons for both approaches, but mySQL limits you to strictly application logic. While this is not bad and makes most programmers happy, it's also one of the most common causes for inefficient database usage. Most programmers think more in loops than SQL and a loop is the kiss of death for a database. The one undeniable requirement of a database is the ability to filter and return only the data needed for a given operation. Since mySQL does not support sub queries, stored procedures, ref cursors, etc, it simply can't do this. The work around is to pull the required information and analyze it in the application. Again, this is a programming solution that has to be applied because the database is not up to the task. The argument against the big databases is that they offer too many things that folks don't use. This may be true, but the corollary is that there is a large pool of things that I can and will use. I would use mySQL in the same places I'd use MS Access for about the same reasons. This makes it a handy tool for database development and testing. However, I don't think it really qualifies it as an enterprise database or a realistic "threat" to Oracle, DB2, SQL Server, etc.
The dirty secret of big databases is that most people don't know how to program them, how to configure them
This is correct.
and don't need most of the features
This is where you're wrong.
They do need the features - they just don't know they need them... so they implement the features themselves in the apps..