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.)"
Like Access 2003 it the cream of the crop? I use Access at work and I would gladly change over to MySQL. Better yet, what would you recommend?
Open Source: Every now and then, you get what you don't pay for.
MySQL gets a lot of heat from the DBAs here (and probably with reason), but it's kind of like bashing MS Access -- it's useful enough for most small businesses.
Put identity in the browser.
3. A very clean and easy to use API, in a language that is universally understood and almost universally portable (C) for incorporation into other products such as PHP, Perl, Python, Apache itself, and an endless amount of other applications.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
For myself and many other college students, MySQL was a great system to play with SQL and experiment on. It's easy to setup on most systems, and it's also fairly easy to use (not to mention free). Don't get me wrong- I've used other systems that are much better than MySQL, but without MySQL to get my hands dirty, I'm not sure I would have bothered with anything else.
You forgot to add an important qualifier here - for a certain set of circumstances. MySQL is one of those products that is suitable for database content that isn't changing much - it's very fast reading from the database. The numbers change quite a bit when you're doing heavier work on the database, which is where Oracle & MS-SQL (or even PostGreSQL) come into their own.
MySQL, even now, is actually rather sparse as database engines go: it lacks stored procedures, triggers, constraints, etc., in short many of the things that a serious DBA considers necessary in a database engine.
But the mission it was originally created for is a mission that's a very common one: a simple, network-enabled data store with a SQL interface. That it lacked transactional capabilities didn't really matter: it was good enough for what many people needed.
So its popularity exploded. In the free software world, there weren't any other contenders at the time that were sufficiently reliable or fast to do the job. PostgreSQL back then just wasn't fast enough, and tended to eat data. Not that MySQL was perfect in that regard, mind you, but at least MySQL gave you the tools to recover your data quickly in the event of a hiccup. PostgreSQL didn't -- it required you to do a full restore from backups, whereas MySQL let you use 'isamchk' to get you up and running quickly. That made a big difference to a lot of people.
Today the story is very different. PostgreSQL is at least as fast, if not faster, than MySQL in many situations, especially under load, and has essentially all the features needed to make it a "real" database: transactions, stored procedures, triggers, views, constraints, etc. About all it lacks now is built-in replication (there exist third-party solutions), nested transactions, and point-in-time recovery (a.k.a. archive logs), things which MySQL is not likely to get anytime soon.
Nevertheless, despite the fact that PostgreSQL is very much a superior solution in just about every respect, MySQL is more popular and thus has better third-party support. And it's thanks to the fact that it was in the right place, at the right time, with a "good enough" feature set.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
Didn't help PostgreSQL or Firebird did it?
Being free is one thing, being fast, elegant, easy to use and administrate, having a pretty clean security record, AND being free, those traits are something to write home about.
Yes, we know, we know, MySQL isn't 99.99999% standards compatible. Well that's something to work toward, but at the time, it was quite usable for anyone who needed to use it, therefore it was used. If the internet needed transactions for things as simple as serving dynamic pages, then MySQL probably wouldn't have prospered, but it did have what the developers needed, when they needed it.
"Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
I mean really, how many people out there can truely justify the cost of a full featured, robust database like MS-Sql? 10%? 5%?
How about 100%!?!? Ever hear of PostgreSQL?
ACID compliance, features that compare very nicely against MS-SQL/Oracle, foreign keys, triggers, transactions, embedded function definitions, the whole shebang.
About the only thing that it lacks (for free) is decent clustering/replication capability - and you can buy that fairly easily in the form of patches.
I've been using it for years, and it's a joy to work with!
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I understand it's supposed to be better because it supports more ACID compliant features (and has for a long enough time to consider them stable). I just can't seem to get the hang of PG though. I far prefer the mysql command utility (and mysqladmin) over psql, I just find it easier to use. I also don't like the way PG handles users. I find it easier to add and modify users in MySQL and set their privileges with it's table method than PG which is more configuration based. I could figure everything out, but I've been too swamped lately to learn the in's and out's of PG. That's why I continue to use MySQL, because it fits my needs. Not PG's fault, but it's one of several reasons people still use MySQL.
-----
How can you have any pudding if you don't eat your meat?
If you're interested: the database in question comprises about thirty tables, ranging in size from ~500 rows to over 200,000, with a fair number of three- to five-table joins. I'm not saying by any means that this proves MySQL is faster than Oracle for every query, but I think this is a fair-size test. Granted, it doesn't cover the multi-TB data warehouses which seem to be Oracle's primary claim to fame, but I know that some organizations with much, much larger data needs than my company use MySQL and seem to be happy with it.
The correlation between ignorance of statistics and using "correlation is not causation" as an argument is close to 1.
...provided the MySQL server isn't under load. Watch those queries get slower and slower the more users you add. With Oracle, watch the queries perform the same under a far greater load than MySQL will handle.
At this point anyone with RDBMS experience is rolling on the floor. THAT is why MySQL gets no respect.
It was the simplest database at the time that was marketed well. Minisql was not marketed at all, and of course wasnt really opensource.
People need to use SQL and need something simple and fast. Postgresql is not optimised for simple web applications out of the box.
sqlite I think came much later, but would have fit the bill and IMHO would have taken Mysqls place early on. I know I was looking for something like sqlite making my simple website and mysql seemed to complex.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Another reason is that so many (web) programs incorporated it, like vBulletin. it was free to use and easy to learn, and it was painless to deply on virtually any platform.
I think it does have a lot to do with the name.
MySQL, maybe it is My-Ess-Que-Ell or maybe it is My-Sequel, but Postgresql? Postgr-ehz-Que-Ell? Postgreh-Sequel, Postgray-Que-Ell? (Does sound vaguely French.) Ugh! (Nothing against French.) Hate the name, but love the program. Although it seemed that there were more people choosing MySQL over Postgresql when I started evaluating the two, there were two key features that led me to choose Postgres(whatever) over MySQL
1) Views (How can you have a/an SQL database and not support views!)
2) Free license for corporate use
So, if I chose to work with MySQL I would have to give up using views. Also, if I wanted to use it at work, I would have to convince the boss to buy a license. On the other hand if I worked with Postgres(whatever), I got views, and did not have to persuade the boss to part with any money. So it was 2 minuses in the MySQL column, versus 2 pluses in the Postgres column and the Ayes have it. After MySQL changed their license, inertia kept me going forward with Postgres (and MySQL's lack of views and triggers).
Now that MySQL has a GPL version, it is less of an issue, but at first, it was free for non-profit use only (or so I understood), while Postgres was free for any use. It surprised me that so many would choose the non-free / less free license.
But no-one used that "HORRIFIC" web browser, except to download Netscape. At least util NN4, when Netscape shot themselves in the foot (and took off most of their leg in the same shot). After that (well, until recently) Internet Explorer was a better browser - far from "HORRIFIC".
PHP is a highly customizable, fast-rendering and highly scalable platform...
Things got interesting when I loaded all 2 million rows of data (one per file) into the poor POS Access DB. It took over 8 hours (I left it running and went home; it was still running when I got back. Lo and behold, it accepted every row. Trouble started when I discovered that trying to save a query or report would send the machine into la-la land. So, I had to dump the DB for every tweak of the report. After a week of messing around (time "well spent," as using Oracle/MS-SQL would have saved at least 4 days of waiting for row population), I finally got everything working, and turned in the report (something like a 500 page PDF).
Naturally, they wanted to change the criteria and group by something else. "Sorry, but today's my last day," I grinned. "And it takes at least one full day to make any changes, assuming you got it right the first time."
Suck. Ers.
Yeah, right.
As far as speed, both MySQL and Oracle have their place. MySQL has a good price/performance ratio, while Oracle scales well. There are situations where one server with a couple processors and lots of ram just isn't enough for a single database. It could take hundreds of servers, several processors each, sharing hundreds of disks, and Oracle can supposedly handle that fine while still guaranteeing transactional consistency and zero down-time when one of them bites the dust.
Are you running the same queries on both MySQL and Oracle (ie, not using subselects, not using precompiled procedures, etc)?
- don't know enough about databases to understand why they should be using a different tool
- members of the 'I have a hammer, therefore this problem is a nail' sect
- people making money from the first two groups
Finding someone using it and can give good technical reasons *why* they are using it is a rare find. Feel free to substitute Access, Visual Basic, Perl, C, Java, C# or C++, Windows or Bose for MySQL if you like.But Postgres has been a fully functional RDMBS for years, with the features a professional needs.
Both can be obtained for free (though mysql is dual licenced). Maybe mysql has better marketing or offers better support, while becoming the default database for PHP?
I call bullshit. In e-Week's tests, Oracle and MySQL were dead even under load.
My Greasemonkey scripts for Digg &
Pardon my ignorance, but what is it exactly that MySQL is good at that Postgresql isn't at least equal or better at? I'm all for using the right tool for the right job, but every time I've used at MySQL I've frequently encountered all sorts of crazy problems with no killer features to justify the change, that aren't already provided by both postgres and other databases. Maybe it's my application bigotry speaking, but I honestly can't see how MySQL is better at anything.
The only things I can think of are the familiarity aspect, for people who are already very knowledgable about MySQL not wanting to switch, and possibly some minor issues with moving database files around on the underlying file system.
the postgres origins are actually quite interesting - it's here.
"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."
I can easily think of a reason to go from Oracle to MySQL.
1. You don't have a database that needs Oracle.
2. Therefore downgrading will save you fat sacks of cash.
I've known someone who was fired for choosing Oracle. They suck an enormous amount of money into the project and it was far more database than they needed.
Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
I have a very similar story. Small company, big spending, decent business plan, very poorly implemented.
I went to talk to the guy in charge because he got in his head to buy Oracle. I was trying to convinve him to use MySQL because of cost. He thought Oracle was the only way a company could operate.
Here's what actually happened:
(1) We settled on Sybase
(2) Took forever to get plans worked out and the software in place (it would have taken a matter of hours for me to get MySQL in place...)
(3) We never moved off our "temporary development" system that was a flat text file[1]
(4) Investors realized nothing was making it to market and too much was being spent, and company went under.
[1] The flat text file -- 100's of MB -- was being read several times each time the front page of the company website was loaded. And no, nobody ever got sybase in place behind it. After all, details like that don't impress investors.
Disclaimer: I now use postgresql. At the time ('99) postgresql still had some rough edges, but now it's the best database out there for everything that I use an RDBMS for.
Social scientists are inspired by theories; scientists are humbled by facts.
The reason MySQL has been so successful is that it is NOT a relational DBMS. It doesn't have any of the features that a "real" database would have. That's the point.
MySQL is a glorified card catalog with a reduced-SQL interface. And for the vast majority of the projects that use it, that really is all it needs.
I say this as someone who has not written in any production SQL environments except for MS Access and MySQL. For small stuff, all I want is a card catalog with joins, and MySQL gives me that easily. I know the projects I've worked on aren't going to scale to a million rows, they're only in the few thousands, or in a few cases only a few hundred. If they start to get to the point that they're handling millions of transactions, then I'll be rewriting the whole thing anyway.
Tell me: WHY would I want to use Oracle or even PostgreSQL for a recipe book or web calendar when MySQL requires less mental overhead for me? I wouldn't. That's like using a Mac truck to drive to the grocery store and back.
When I start writing financial apps or systems that actually require complete integrity checking, good bye MySQL, hello Postgres. But for right now, MySQL is simple, my web host supports MySQL, and it's all these projects are going to need.
--GrouchoMarx
Card-carrying member of the EFF, FSF, and ACLU. Are you?
A tuned query set is pretty much unportable no matter what DBMS you are using. Once you start getting into maintenance tasks, vendor-specific performance boosting options (which are often the reason you've chosen a vendor), and basically anything beyound the most basic selects and inserts, you code becomes tied down to a server. Also the general disregard most servers have for ANSI means that it is only a standard in theory, not in practice.
This is not the greatest sig in the world, this is just a tribute.
17. Well it's MINE, innit? Says so in the name. _MY_ sql. Ya gotta like that!
Seriously, I think a good name is half the battle with acceptance. If Postgres had called themselves MySQL -- rather than "Huh?" as most people understood them to mean by their Ingres-derived title -- and then produced some half-decent documentation occassionally...
But they didn't.
You are missing the point. The point is that other databases, such as Postgresql, offer virtually all the SQL features of Oracle including a reasonably compatible PL/SQL language. Oracle is not a simple database. Developers tend to use its features. MySQL can't provide those features. Other databases can.
Suggesting a migration from Oracle specifically to MySQL is typical management bullshit along the lines of 'I have heard of both of those and they are both databases, so they must be the same'.
Unlike most of what MySQL folks say, this is really an honest difference of opinion. The "best practice" from MS or Sun would be to put the biz logic in an application server, and only use the DB for integrity. However, many people still prefer to put the rules in stored procs. And for your lil VB/web app, the rules are going to inevitably end up in the client just for cost/installation considerations.
:)
Of course, without nested transactions, you aren't going to get very far with MySQL & an appserver, and stored procs are obviously missing, so you know what the MySQL guys will say
Now _that's_ funny. I've worked with so many organisations who think that Excel is a database, and really don't see why they should change to something else, regardless of whether it's Access, MySQL, PostGre, Oracle, or whatever.
It's only once you've shown them a few things that are easier in anything other than Excel that they begin to understand - and in some ways that's why MySQL is useful, it provides a cheap/free alternative to investing in Oracle etc., and is useful for demonstrating the basics of why a DB is better than a spreadsheet.
I say we take off and nuke it from orbit. It's the only way to be sure...
Not trying to flame... talking about maturity of experience...
Lots of people didn't care. They just wanted to stick dynamic content on their pages.
Most of them didn't care about things like transactions. They either never heard of them in the first place, or figured they didn't need them.
Most of them didn't care about portability.
A few of them found that MySQL was fast when you don't care about these things, and that it was easier to install. The told others, and it became 'cool'...
I'm not knocking the above, most of them were probably self taught, and have learned a lot since. The MySQL userbase seems to have matured a lot, and as MySQL becomes more like a 'real' DBM, it's users are becoming more like 'real' SQL admins.
The only real competition at the time was postgres, and it was slower, and possibly more difficult to install. Those of us like me who cared about things like transactions took the extra time to make it work, because we wanted what MySQL didn't offer.
Vs lbh pna ernq guvf, ybt bss abj. Tb bhgfvqr. Syl n xvgr.
Everything you're saying is based on process-level protection provided by the OS.
Exactly. The OS is helping to ensure database integrity.
If the OS provides sufficently correct thread-level protection, then almost all of those issues become a dead heat.
Except, it's impossible for the OS to sufficently correct for thread-level protection while still providing the advantages in speed of thread level IPCs. So, it's safe to say, it's impossible for a threaded implementation to, "become a dead heat", with a process based implementation in that regard.
Also, it's not just spinning a thread vrs forking a process - process-level IPC is slower than thread-level IPC as well.
This is true. Just the same, thread level implementations tend to require more IPC synchronization, thusly, on average, the threading IPC speed advantages tend to become noise. This is because threaded implementations tend to have much higher levels of contention on shared resources. On average, I'd consider it to be a wash.
And process-level IPC is no safer than thread-level.
I'm sorry, but this doesn't entirely address the issues. Have a shared resource on the stack? IF you walk on the stack, you potentially just corrupted state for ALL threads and brought the state of the entire process into question. The same holds true for shared data segments.
If one of your processes corrupts and crashes during a write, your database is just as hosed as if a thread did it.
Maybe, maybe not. This is why we have transactions. If the corrupt transaction fails to complete, it's rolled back. Conistency is maintained. On the other hand, it's very possible, in a threaded implementation, to actually have the field value corrupted (it's length or value, etc), and have it still be written to disk. In otherwords, as I originally stated, a process implementation greatly reduces the chances for corruption. I did not state it eliminated it.
On Windows, at least, threading is far more performant - you _must_ thread for very fast IO, network or disk.
Because MS made the decision to bais threads over processes. On Linux, even with the old thread implementations, threads were really LWP and were not significantly faster at spawning than processes. That was because forking on Linux so fast compared to other platforms.
Now that linux has a non-crap thread library, that may end up being true there also.
Well, that addresses Linux and threads, nothing else. Remember, PostgreSQL runs on many more platforms than just Linux. It's always going to be a toss up on other Unix platforms to determine which is best (threads vs process). This is exactly why Apache 2.x implemented it's hybrid model. That is, so that they would be fast on MS' platform and fast on Unix platforms, allowing each to tune best for each unique platform.
The most reliable and performant databases in the world are threaded - thats a logical argument in favor of threading.
Bzzz. Popularity hardly makes right. Best of all, popularity hardly invalidates the issues which I put forth when contrasting the two models.
Bluntly, neither model is perfect. Just the same, it's far *easier* to maintain consistency, uptime, and reliability with a process implementation. Notice that none of those speak to performance. Even if you refuse to accept that threading is not inherently faster than processes, which is more important to you? ACID or speed?
That's definitely a big part of it, but not the whole story. PostgreSQL's lack of adequate software support extends to the client side as well. There are very few options for PGSQL front-ends now (although some of them are quite good), but four years ago the selection was downright threadbare. One thing that can be said of MySQL is that MySQL AB at least offers free GUI clients.
But, I think many people are swayed by the argument that MySQL has a much bigger grassroots support base. While technically that's true, look at the nature of the support base: thousands of redundant questions, many of which are directly related to the lack of features that supposedly makes MySQL great. We're not just talking about views and subselects here: until v4.x, MySQL even lacked UNIONs for god's sake. Fledgling developes may not be able to ask for these features by name, but that doesn't mean they don't feel the lack.
Since working with MySQL means developing with half of the SQL9x spec tied behind your back, and considering that MySQL's documentation is inadequate (and occasionally inaccurate or misleading), it's no wonder that such a huge support base is necessary.
Do they lose money if a comment disappears? No.
Are they liable for any consequences of losing data? No. Do they need to keep an audit trail? No.
None of these things have anything to do with how "big" a database is.
The kicker is, slashdot isn't very big at all! Can you come back to a story a few months later and comment on it, or even view it according to your preferences? No, it's been removed from the database because and put to static HTML because MySQL doesn't scale!
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!