Slashdot Mirror
Why MySQL Grew So Fast
jpkunst writes "Andy Oram, who attended the MySQL Users Conference which was held April 16-18 in Orlando, Florida, attempts to explain MySQL's popularity in his weblog at oreillynet.com. (More weblogs about the 2004 MySQL Users Conference can be found at the The 2004 MySQL User's Conference & Expo Blog Collection.)"
1. MySQL can be installed without cost.
2. MySQL is easy to install and learn.
"You spoony bard!" -Tellah
Too bad indeed.. if it weren't for poor products that get widely adopted fast, graet products would never be adopted. For instance, the reason why the world wide web took off was because Microsoft created a HORRIFIC web browser, but since now all computers had a web broswer, everyone had access.
MySQL was in it's own, a huge part of the dot com boom, and therefore a huge part of the history, and therefore, the future, of the internet. Hate it, love it, it's a great product with a great niche, and for now, it'll continue along that path.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
Slashdot users complain that MySQL doesn't have the full feature set of some RDBMSes... but they miss the point. The reason MySQL has been succesfull precisely because it's been very good at delivering the features that a particular set of people need. To these users, additional features are a liability, not a feature.
This reminds me a lot of DBase III. (Bear with me here...)
DBase III wasn't a very good database program, but in its heyday millions of people used it and it got the job done for them. Even relatively inexperienced users could make use of it and write simple programs to manipulated their data. Even though it sucked, it was the right tool for a lot of jobs at the time.
Compared to DBase III, both MySQL and PostgreSQL are excellent. I wish I'd had either one a decade ago when I started work doing clipper programming for a dog track related publishing company.
For the dog track application I would have preferred Postgres; the rollback support would be pretty compelling for an application like the one we were doing. Rosebud is a sled, and Verbal is a huge liar. Darth Vader is Luke's father, and the Sixth Sense guy is actually dead. The planet of the apes is Earth, and Rocky loses. For something where I was just kicking around a database (Which I've also done a lot of) MySQL would be perfect. MySQL would be ideal in something like the RHS Orchid Registry, for instance.
If application bigotry keeps you from choosing the right tool for a job, you will be a less valuable resource to those who employ you. Not too many people seem to "Get" this. People are often surprised that I will, on occasion, suggest that Microsoft products are the best tool for what they're trying to do. Usually those people asked me expecting a "Windows sucks use Linux" spiel, but if I think their situation warrants it (Inexperienced user, just wants to browse the web, word process and send E-Mail or wants to play games at all) I'll tell them to use Windows.
In a nutshell, MySql is free. Is it great? Hell no, but it's free. The only deep understanding of human nature or the DB marketplace one needs to comprehend here is that given the choice between something great and expensive vs. something mediocre and free, the overwhelming majority will go for free.
MySql has always had huge problems preventing it from being accepted in the real "enterprise" marketplace, but most of us aren't in that market. Most of us need to yank a bit of data and cram it into a web page moderately quickly and as cheaply as possible. MySql does this quite well.
What doesn't MySql do well? For starters, it's much slower than Oracle, MS-Sql, and even Foxpro. It has no row locking, no transaction support, and minimal cross-platform compatibility. But, it's free and it works more or less ok on Linux.
Perhaps the real truth that Oracle fears is that eventually DBAs will come to realize that 99.9% of their storage needs aren't so "mission critical" as they would like to believe. I mean really, how many people out there can truely justify the cost of a full featured, robust database like MS-Sql? 10%? 5%?
For the rest of us, a free - albeit slightly dodgy - solution will work fine.
Not.
MySQL has always been fast. That is probably why most people use it.
MySQL has also been easy to manage (e.g. move database files from one subdirectory to another and the tables have also moved). That kind of simplicity brings tears to the eyes of an Oracle admin. There are a few options you can tune and teak, but by and large it just works out of the box (er, RPMs).
And of course the reason it has been so popular is that it has been so popular. If you get my circular drift. People use it because there is a lot of documentation about it. Perl and PHP pretty much always have the MySQL libraries so it can be used on web sites, etc.
Speacking of those subqueries, what's up with the delay getting 4.1 out from alpha to beta/gamma/production. I want to start using it. And 4.1 has been out in alpha for over a year now. Not to mention new development is already proceeding with the 5.0 release.
- Run the latest and greatest alpha MySQL database on your own VPS
Not everyone is a database elitist. Not everyone has to worry about transactions nor store procedures. Triggers are neat, but not always necessary. (Insert obligatory VHS/Beta comment here.)
What is great about MySQL is that it gives the average Joe or Ho with a machine a chance to build a database backed application of some sorts. Its cool. Its free. Its fun.
Now for all of those who have based their fragile nerd self esteem on their DB experience or knowledge need to turn off their computers and go down to the local bar and talk to the local people about local people's reality. Ya MySQL is not DB2 nor Oracle, but it is still pretty cool. And the fact that Monty has written the greater portion of it is pretty cool too.
Naysayers need to get laid!
As a programmer who values practicality above theoretical purity, I don't really understand how something as incredibly useful as MySQL can be so "poor".
All I know is that I've built three highly successful, high volume websites off of MySQL over the past five years and there's no way I could have done it as cheaply or quickly otherwise.
Poor product indeed.
Cheers.
The statement "move database files from one subdirectory to another and the tables have also moved" is a tautology. The tables are in the files, so of course they move.
"That kind of simplicity brings tears to the eyes of an Oracle admin." No, it doesn't. I'm an Oracle DBA, and I'm not crying because MySQL lets you move datafiles - so does Oracle. Typing "alter database rename datafile..." isn't exactly rocket science.
Oracle also works "out of the box", especially when it's used for the sort of applications that can make do with MySQL. Granted, big motherfucker DBs might need some basic memory tweaking, but small sites can generally get by with the default parameters.
MySQL is popular because it's free, and it meets the needs of certain users. That's all there is to it. It isn't better, and it isn't worse.
Access and mysql aren't even competing. It's like saying, "Why would I use openoffice when I can use notepad?"
Access is a minimal driver-loaded (no deamon) RAD tool, for when you need a quick and dirty forms and business logic driven app for a few people.
People use it as a simple DB, but people also use MSword as a note-taking app. To replace access, you'd need mysql + a gui DB design tool (I know they're out there, just can't think of one off the cuff) + one of:
-apache + php (no gui designer though!)
-java (swing or swt with a gui designer)
-VB
-VC++ (although now you're getting heavier...)
Plus a server of some sort to run the mysql on.
Access is generally crap, and I hate using it, but it's great for a small office of 10 people to do small amounts of ordertracking/whatever type of small app they want pieced together quickly and cheaply, without UPKEEP of a server.
Poor design probably is less important than wide adoption when it comes to growth. But that is circular. Growth and wide adoption are really the same thing, right? At a minimum, wide adoption is a result of growth. They are tied together.
So, taking a step back, what elements drive growth? That's the question. Google taught us that popularity matters.
Taking a different step back, I would argue that usability has driven growth. Namely, ease of use. A quote from the article supports this:
"But MySQL's very simplicity made it so small and fast that it quickly won over small users who wouldn't even understand what they were missing and how to use the fancy features offered by "real" database engines."
My final comment about "poor design" is this. Assuming the design is poor, does it really matter? If it solves problems, and if people use it, and it is a Good Enough solution, and if the price is right, poor design is largely unimportant, right?
How to Download YouTube Videos
Remember when Reasoning, Inc audited the code? They found that it had 0.09 errors per 1,000 lines of code while proprietary competitors had 0.56 errors per 1,000 lines. That's more than 6 times as many errors in the proprietary databases. http://searchenterpriselinux.techtarget.com/origin alContent/0,289142,sid39_gci941817,00.html
Quality product. That is why it is popular. Perhaps you should research your argument before posting a flame next time.
bash: rtfm: command not found
Over the years I have been a user on PostgreSQL, MySQL, Oracle, and MSSQL, and an admin on PostgreSQL and MySQL.
Having said that, I prefer MySQL and PostgreSQL to both Oracle and MSSQL, in most situations. However, given my experience with MySQL and PostgreSQL, I am glad that I have returned to PostgreSQL.
Why PostgreSQL? Simple. I am able to use referential integrity, triggers, and foreign keys in my databases. I can use subqueries, and more. There are certain databases where the data integrity is the important part. Having the database enforce that integrity is cheap insurance. Having transaction support, including rollbacks, are great for operations that affect multiple tables. I also like the way Postgres strives for SQL compliance.
MySQL is improving. Everytime I check they are getting more and more support of things I consider critical. Especially in the last 9 months to a year. But not yet enough for me.
I was involved in a fairly large scale production system that used MySQL as its heart. Unfortunately, at the time, PostgreSQL just did not have the performance that was needed. And, the main DBA was a mysql zealot. With MySQL, we seemed to constantly have to figure out creative work arounds for what MySQL lacked. Table level locking was a headache. No referential integrity and lack of transactions were a nightmare.
I still see MySQL as the better solution when you need to serve text files via SQL really really fast. But, when you need to provide a specific level of accountability and traceability, PostgreSQL is still my choice.
. 62,400 repetitions make one truth -- Brave New World, Aldous Huxley
"On the other side of me, at that lunch, sat a database administrator whose facility is planning a migration from Oracle to MySQL"
Whatever moron made that decision needs to be outsourced to India. Thats sort of like trading in a shiny BMW for a freakin go-cart.
Sure, MySQL has gotten better, has always been speedy and is great for down and dirty webservices. But the bottom line is still the same: It's not a **real** database. Transactions? Stored Procedures? Triggers? Schemas? Groups? Views? Uhhhh Hello!!!
Granted, MySQL is popular; just about every cheapo hosting service has installed it and offers it up as part of their base level $20.00 a month hosting pack.
Being a seasoned webdeveloping gun for hire I deal with online data services all the time. Time and time again I use postgreSQL.
Sure, the client always brings up the MySQL question, but when I show them what can be done with postgreSQL and what can't with MySQL it becomes glaringly obvious that MySQL is __NOT__ the tool to use if you have any real service to offer or data to mine.
For all you MySQL advocating web developers out there:
If you put all the SQL functionality where it should be -- in the database -- and not the middleware you'd never even think of MySQL as a real alternative, because MySQL doesn't support that.
I for one cannot understand how anybody can do *any* serious database work without views and subqueries (the latest MySQL alphas/betas have support for subqueries). The whole relational theory is (almost) broken without these.
To me that's mindboggling. Without that I'd rather use berkeley DB or flat files to load and store my data. How do you do row-level security without views, what about column security. Or just different views for different users. These are just a few example that require *a lot* of coding without database support (not to speak about performance). Heck, do people even understand what views (or triggers, etc) are?
People say it's easy to move databases around my MySQL. Yeah, sure, as long as you stay with the ISAM tables, which do not support ACID. InnoDB tables support ACID but cannot simply be copied around.
It makes me shudder to think about all the future DBAs that accept the low standards MySQL is setting.
Access is the database sibling to Visual Basic... in fact, a code module in a .mdb file is Visual Basic for Applications... which aside from the fact that it depends on having Microsoft Access present is just about as powerful as Visual Basic itself. Access projects can even be compiled into .mbe files which locks down the forms and code users can't see or change your source.
It's a great cheap tool when what you've got to do is open up a bunch of flat files, grab some data from each of them, and then output a pretty-looking report. You can then get it down to a push-button interface so that a newbie can run your tool, and you can go on to something more important.
You're right, not everybody has to worry about those issues, but maybe they should. However, the problem is not so much with MySQL itself (it's a good, fast, lightweight storage system for simple and small amounts of data). It's with the perception that MySQL is every bit as good as a more robust engine (Oracle, MSSQL, DB2, take your pick) for any application. That is definitely not the case. As well, knowing MySQL does not make you uniquely qualified to decide that it's better than one of the other choices for a system that needs that level of robustness. The biggest problem is that people who only know MySQL choose MySQL because that's all they know, even when it's completely unsuited to the task.
Add to that the arrogance of the MySQL developers ("These aren't the stored procedures you're looking for ..."), and the zealotry of the user base, and it's easy to see why those of us who do know a thing or two are bitter about MySQL. I laugh anytime someone tells me that they can enforce data integrity from their application layer instead of using foreign keys (usually while trying to clean up their mess of a data set so the data itself can be trusted). I find it hysterical when I'm told that stored procedures are a complete waste of time (typically while fixing someone else's SQL injection problems because they insisted on writing dynamic SQL queries from their code).
I'm all for making databases and db technology more available to the Average Joe, but MySQL is not the way to do it. If you need free, there are many better alternatives to MySQL (especially if you only need free for training purposes, because then the big three are available to you as well).
Comment removed based on user account deletion
A view is just a query which you can run again sometime?
You really need to learn RDBMS theory.
I do find it interesting that Linux users like to lord over Windows users how "sophisticated" they are, but when it comes to MySQL, they use the "well it does what I need" excuse, ignoring the gaping technical issues with the product.
"MySQL uses table locking (instead of row locking or column locking) on all table types, except BDB tables, to achieve a very high lock speed. For large tables, table locking is MUCH better than row locking for most applications"
The article rambles a bit, but it does hit the nail on the head when it comes to what drove the rapid increase in popularity of MySQL -- that it was small, fast, and easy to learn, mainly due to the fact that it did not include features that were, for many users, extraneous.
When I first went looking for a database to drive my website, my more knowledgeable friends and professional acquaintences all hawked postgresql. Since it was the default db that shipped with Red Hat, I figured I'd try it. I liked how robust it was, but I had a hell of a time finding support for it in the applications I wanted to run. I eventually switched to MySQL (which I had already used for various other projects) because it still remains easier to use, and because PostgreSQL is way more than I need.
The simple fact of the matter is that most users don't need ACID compliance, or transactions, or what have you. They need a storage system with sql interface, and that's it. Users who need more from a database would pass up MySQL for something better suited to their needs... but those users are in the minority. Everyone else's needs are simple -- MySQL sacrificed the less essential features for speed, simplicity, and ease of use. As a result, it was more attractive to people who were adequately served by its feature set.
And as MySQL has progressed, it has added in many of those features that higher-level databases like PostgreSQL offer, allowing us the option of using those features in the future.
The dual license is, in my view, a great business model. It provides the revenue stream open source projects need without sacrificing the freedom for those users who embrace the open source concept. As I understand it, it's free for use, and free to distribute under the terms of the GPL... but you have to pay if you want to use it in a non-GPL product. To me that's genius -- it forces a licensee to play by the same rules he sets, which seems only fair. I wouldn't be surprised to see more projects adopting similar models, nor would I mind.
who says that MySQL is better than Oracle? i've never read or seen that anywhere. it is two different products in two different classes. they can't be compared.
it's all about the right tool for the right job.
coding up the next Ebay? use Oracle.
wanna keep track of your DVD collection? use MySQL.
i've used Oracle and Postgres, and i've setup triggers and stored procedures and hard relationships.. sure it's useful,
but it's rare when i'm doing a project that's out of scope of MySQL (and i can do all the trigger, stored procedure stuff within the application code, big deal).
MySQL also allows you to do rapid development of small to medium sized projects. what if one of my projects gets so big that i need to scale it up? well, if i am so unfortunate to have one of my projects go big time, then i'm sure i'll get big dollars and redesign the project for the big leagues.
here's another example:
i was working for a small company that finally recieved it's funding (15 mil for 10 employees). well, the company started hiring corporate types left and right.
well, these corporate folks had little to do except dress nice and figure out how to spend our funding.
i was called into the CTO's office. he sat me down and explained to me that he wanted to setup a database to store employee information (address, phone number, normal stuff). at that point we had about 25 employees. i was like, no problem i'll setup a MySQL database with a PHP front end and have it done this afternoon.
he told me to do nothing and wait for the Oracle people that were coming the next day to discuss licensing.
my jaw hit the floor.
but this is exactly the problem. people don't realize which tool they should use for what job.
One thing that MySQL isn't is a bloated whale of an application. Oracle is feature rich and under heavy load, when administered correctly, is blazing fast. But that also makes it a system resource pig.
Part of the reason why every SQL feature in the world isn't implemented is because it sometimes pays to make an application lean. I tend to believe the authors/maintainers have a lean-mean philosophy, and sometimes prefer to let the users implement their own creative solutions instead of providing every bell, whistle and horn.
As a hypothetical example, one can easily implement an auto_increment feature outside of MySQL using a combination of a simple table declaration and some create PHP or Perl programming. Not that you'd want to, but some creativity can make up for non-implemented features.
In simple terms, MySQL is the equivalent of a cheetah. It's fast and lean, and accomplishes it's task with agility and grace.
MySQL is also easy to learn and easy to implement, especially if you are using the Apache/MySQL/PHP or Perl combination. Even better, this entire scheme will run using only 128-megabytes of RAM (thereby making my 5-year old AMD 500MHz still usable!). Try that with Oracle... can you say swap partition hell???
Now the feature set is stable, it can always be re-implemented in a more "beautiful" style. Well, since the mysql_*, pg_*, sybase_* and so on functions use very similar syntax, try using sed.
But I think the question we should be asking is, why would you want your code to support a different database anyway? MySQL is free software, so it'll always be available and supported. Ditching some of the bells and whistles and relying on the scripting language (perl, PHP or python) to do some of the donkey work made it bloody fast {e.g. the primitive % and _ wildcards work so much quicker than full-blown regular expression matching, that it's quicker to pull out more records than you need, have the wrapper script do the regular expression matching and just throw away the ones it doesn't need; more of the queries you are going to do are going to be right than wrong, so let the script provide any 'rollback' functionality you may need}, and -- barring a power failure -- it doesn't corrupt its own tables either.
You obviously think that constraining a programme so it only performs one function is a bad thing -- I guess your ultimate piece of software is one that doesn't care what kind of hardware it is running on or what function it is being asked to perform. But such high ideals are too far removed from reality for most ordinary people to take seriously.
Most programmes don't need to have so much changeability, because they are designed to do a specific task. You can add your fancy object oriented classes and methods, abstraction layers and sundry filibustering tricks all you like; but nothing will change the fact that, at the end of the day, sooner or later, you can't avoid the inevitable fact of having to get your hands dirty and actually manipulate some data. It does mean that a programme meant for handling order forms with a Postgres backend is going to need a lot changed to make it do cooking recipes with a MySQL backend, but if your audience prefers to see a pony doing one trick well rather than a full repertoire of tricks badly, who's disappointed?
Je fume. Tu fumes. Nous fûmes!
I can give you the reason why MySQL is so popular: practitioners are ignorant of data management fundamentals (perennial links: Unskilled and Unaware of it and Database Debunkings).
If you don't understand or know the necessity of things like constraints and tying business logic close to the data then you don't care that MySQL can't do them. It's obvious that MySQL developers do not have a clear understanding of the relational model, either.
And how is this elitist? Is it elitist to require that engineers who build bridges know the physics behind bridge building? Would you go to a doctor that didn't know the science of human physiology? Why do we not expect the same level of competence from people who build databases?
As computer professionals we need to hold ourselves to the same standards that we require other professionals. I'm not suggesting, or even think it's a good idea, to license developers but we need to get out of the mindset that it's acceptable to eschew formal ideas (predicate logic/set theory and the Relational Model) for ad hoc junk science (XML, UML, virtually every SQL DBMS product, etc.) all in the nebulous name of 'performance'.
Thanks,
--
Matt