My company has 9 production MySQL servers.
Our company does:
over 4 billion queries a week -- an average of over 450,000 per machine, though in reality 2 servers do near 1 billion themselves, 5 do about the average, and 2 do much less (about 65k and 100k queries).
receive over 1380 GB (almost 1.35 TB!!) of data per week, an average of over 153 GB per server.
send out over 1400 GB of data per week, an average of 157 GB per server.
Our hardware is only somewhat beefy -- 64-bit architecture, 3.20 GHz Intel(R) Xeon(TM) CPU, 6GB of RAM in 4 of the 5 most-used servers (4GB in the others).
We make over USD $220,000 per week ($10 billion per year) in sales for our web application.
If we bought the highest level of service, Platinum, for all 9 production machines, the cost would be 0.40% of our sales. The cost would be less than the cost of a new IT person (even a junior IT person!), and the benefits that come with that include 72 hours of free consulting (8 hours per server).
What's 0.40% of your company's income? Would you be willing to spend that on buying MySQL Network, which not only includes the binary but *support*? How about willing to spend that on a great open source product and company?
What about 0.05% of your company's income? Because that's what the Basic Service Level would cost my company. What would it cost your company?
I'm not an employee of MySQL, so I can say things like "I am confident that the Community Edition is stable and reliable in enterprise-level production systems." This is my personal experience, and I stick by that statement. I've been using it for years in heavy-use systems. Yes, there have been times where we've had severe bugs with MySQL, but those were all solved with an upgrade -- minor version upgrade (ie, 4.1.14 to 4.1.19 solved our worst problem). (I'm not kidding -- all of our issues we've ever asked on a forum about were resolved with an upgrade).
Let me be clear:
MySQL is not making the promise that the Community Edition is reliable in enterprise-level systems.
However, the fact is that the Community Edition IS reliable in an enterprise-level system.
Regardless of any guarantees MySQL makes or does not make, the Community Edition is robust and reliable, and I do not see that going away. I have worked for organizations that buy support contracts for open source products on principle, regardless of requirement or need, because they felt they should pay something for a good product, and wanted to give back to a community.
Ask yourself this question: If your company is not willing to pay $600/year for a certified enterprise-level product for your core, why are you using the product for your core at all? Remember, that price includes support, so that $600 price tag is even more meager.
This is not Oracle vs. Oracle Express. The Community Edition is not an afterthought. It's the foundation.
My company has been running on MySQL for 6 years. Even if my company buys the Enterprise Edition, I will continue to use the Community Edition for not-for-profits, consulting gigs and my personal projects.
Folks who felt that MySQL was not robust enough for them stopped using it years ago, so what's the issue with having the same excellent Community Edition that's always been available to us?
I have yet to hear a valid complaint about this move. All I hear is "I don't wanna pay!" This is, in my opinion, a very ethical and legal move for MySQL to take. Go ahead, whinge about "there's a better version if you pay". But you are forgetting -- there's a completely excellent version for free. The free version works very well on enterprise-level systems, even though MySQL will not say that formally.
Well, I work for MySQL and
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 difference between Community and Enterprise versions isn't the core quality of the server. It's the wrapping that is intended to make life easier for the DBAs who are paid real money and always have other things they can be doing. That includes:
1. The new Network Monitoring and Advisory Service that regularly checks the servers and reports possible issues, from possible failures to possible performance-enhancing settings changes (depends on support contract level, you get the calss of feature for your level).
2. More frequent binary builds from MySQL, so you don't have to fiddle around with compile options and know we've done the post-build quality assurance work.
3. The Support team. Want to know that you have people behind you who've done real-world scaling from one box to a couple of billion queries per day? Two of the current Support team members are from Wikipedia and have. And the core developers behind us, available whenever we think it's helpful to send an email or pick up the phone. With an agreed service level and response times, not the more random quality you get from a forum or mailing list (not that those are bad, they just don't give guarantees, while the Support team does).
So, there are reasons for Enterprise. "What else can you or your DBAs be doing with the time it saves?" is perhaps the question to be asking.
huh, you're right.....I
huh, you're right.....I meant million. sigh. Computers do the calculations, but they don't translate to English for me.
Nice post, good point.
Nice post, good point. However, USD $220,000 per week won't make $10 billion per year, not even TWD $10 billion :)
Well, they went for 5 years
Well, they went for 5 years without a DBA. :)
And of course it's Production. If you're going to flame me, use the right terminology. You mean "Enterprise level".
And if a $10 billion a year website isn't enterprise-level, then honestly, I don't care about being enterprise-level.
Did I mention it's fast? You know, you can program around views, stored procedures, triggers, etc. You can have "good enough" backup solutions. But you can't get around sloth.
We'd love to have materialized views, but Oracle is just plain not fast enough for what my company needs, and without speed the customers leave.
"My company has been running
"My company has been running on MySQL for 6 years".
I see ... near 4 years and a half (almost five years) without: views, stored procedures, real referential integrity, triggers, a solid backup solution, a solid cluster solutions, etc, etc, etc. And you call this a 'Production Database Environment'?, LOL.
Yep, obviously your company don't need Oracle :).