I just read this post, thanks to the database log buffer:
http://marist89.blogspot.com/2006/11/where-am-i-deploying-mysql.html
I think the major point is subtle, and can be gotten by taken the first and last few sentences of the post:
“If cost were no object, I’d always deploy Oracle. I’m comfortable with Oracle technology and I think I have a pretty good idea how to implement and administer it….My company is sold on MySQL and as our confidence grows in the software, so will our installed base.”
He says that MySQL is an “80% solution” but he would not use it for “mission critical applications.” I will venture to say that this is because he is not familiar with MySQL. If he were, he would be more comfortable with the fact that MySQL is an enterprise-level, mission-critical solution. James Day recently commented on a blog post (http://sheeri.net/archives/141#comment-7043) saying,
“Well, I work for MySQL and I’m happy enough to say it: the Community Edition is fine for production systems with huge loads like Wikipedia, where two of the members of the MySQL Support team come from. Merely one of the top 20-30 web sites in the world, doing around a couple of billion queries a day.”
The article goes on to say where MySQL is good, which I actually appreciate. However, it basically says “MySQL is good as a database, but does not have as many ‘extras’ as other DBMS’s have.”
Take the first example:
The first [sweet spot of MySQL] is small to medium size OLTP databases (<100 GB) that are fronted by something like a java middle-tier. These applications typically control most of the business logic and authentication/authorization in the middle-tier (right or wrong) and use the database as a big storage bucket. These applications rely on the backend serving data as fast as it can and MySQL can serve data just as fast as the next guy.
Is there something wrong with expecting a database to be “a big storage bucket”? Isn’t that what it’s for? Isn’t that like saying “HTML is great, but it sucks for business logic.” That is the entire point — it’s the UI layer.
Similarly, databases are the storage layers. In a good theoretical model, databases are not supposed to have business logic embedded in them.
Sure, if the database does it faster, then put the business logic there. But know that you are doing that, make a conscious decision, and say “yes, we’re breaking from good theory for better performance”. Much like, say, denormalizing a table.
And MySQL isn’t “just as fast as the next guy”. It’s FASTER, otherwise why would people use it, because it’s much less featured than Oracle? This I’ll admit — however, you can code around features. No amount of code can make Oracle faster.
In the 2nd “sweet spot”, it says that MySQL excels at retrieving data. Hot damn, isn’t that what a database is supposed to do? Is Oracle not good at retrieving data? If Oracle is better at storing business logic than retrieving data, shouldn’t it be called a programming language, not a database?
In the third sweet spot, you say MySQL is good at stuffing lots of data into denormalized tables. I’ve been using MySQL for quite a long time, and I missed the part where stuffing lots of data into normalized tables is slow. It’s fast for stuffing lots of data into tables, period.
And yes, it’s snappy for retrieving data. So it’s good for putting data in and taking data out. I am not sure how this says “it is not good for mission critical applications.” It does everything a database is supposed to do. So does the blog post implying MySQL doesn’t have 24×7 reliability?
What’s your uptime with Oracle?
MySQL has fabulous uptimes, multi-threaded processing, etc. My company relies on MySQL, and we make > USD $220,000 per week.
Is it perfect? no. But is it reliable? Damn skippy.
To Jeff Hunter’s comment I say: Incremental backups exist — that’s what binary logs are.
I just read this post, thanks to the database log buffer:
http://marist89.blogspot.com/2006/11/where-am-i-deploying-mysql.html
I think the major point is subtle, and can be gotten by taken the first and last few sentences of the post:
“If cost were no object, I’d always deploy Oracle. I’m comfortable with Oracle technology and I think I have a pretty good idea how to implement and administer it….My company is sold on MySQL and as our confidence grows in the software, so will our installed base.”
He says that MySQL is an “80% solution” but he would not use it for “mission critical applications.” I will venture to say that this is because he is not familiar with MySQL. If he were, he would be more comfortable with the fact that MySQL is an enterprise-level, mission-critical solution. James Day recently commented on a blog post (http://sheeri.net/archives/141#comment-7043) saying,
“Well, I work for MySQL and I’m happy enough to say it: the Community Edition is fine for production systems with huge loads like Wikipedia, where two of the members of the MySQL Support team come from. Merely one of the top 20-30 web sites in the world, doing around a couple of billion queries a day.”
The article goes on to say where MySQL is good, which I actually appreciate. However, it basically says “MySQL is good as a database, but does not have as many ‘extras’ as other DBMS’s have.”
Take the first example:
The first [sweet spot of MySQL] is small to medium size OLTP databases (<100 GB) that are fronted by something like a java middle-tier. These applications typically control most of the business logic and authentication/authorization in the middle-tier (right or wrong) and use the database as a big storage bucket. These applications rely on the backend serving data as fast as it can and MySQL can serve data just as fast as the next guy.
Is there something wrong with expecting a database to be “a big storage bucket”? Isn’t that what it’s for? Isn’t that like saying “HTML is great, but it sucks for business logic.” That is the entire point — it’s the UI layer.
Similarly, databases are the storage layers. In a good theoretical model, databases are not supposed to have business logic embedded in them.
Sure, if the database does it faster, then put the business logic there. But know that you are doing that, make a conscious decision, and say “yes, we’re breaking from good theory for better performance”. Much like, say, denormalizing a table.
And MySQL isn’t “just as fast as the next guy”. It’s FASTER, otherwise why would people use it, because it’s much less featured than Oracle? This I’ll admit — however, you can code around features. No amount of code can make Oracle faster.
In the 2nd “sweet spot”, it says that MySQL excels at retrieving data. Hot damn, isn’t that what a database is supposed to do? Is Oracle not good at retrieving data? If Oracle is better at storing business logic than retrieving data, shouldn’t it be called a programming language, not a database?
In the third sweet spot, you say MySQL is good at stuffing lots of data into denormalized tables. I’ve been using MySQL for quite a long time, and I missed the part where stuffing lots of data into normalized tables is slow. It’s fast for stuffing lots of data into tables, period.
And yes, it’s snappy for retrieving data. So it’s good for putting data in and taking data out. I am not sure how this says “it is not good for mission critical applications.” It does everything a database is supposed to do. So does the blog post implying MySQL doesn’t have 24×7 reliability?
What’s your uptime with Oracle?
MySQL has fabulous uptimes, multi-threaded processing, etc. My company relies on MySQL, and we make > USD $220,000 per week.
Is it perfect? no. But is it reliable? Damn skippy.
To Jeff Hunter’s comment I say: Incremental backups exist — that’s what binary logs are.
Comments are closed.