On Dec 26, 2007, at 6:58 PM, Suresh Ramasubramanian wrote:
J. Andrew Rogers [26/12/07 11:45 -0800]:
- The use of MySQL is based in fanboi-ism, not rational technology
selection. Google is as prone to this as any other tech
organization.
I am sorry but I have to disagree. We made an informed choice about
seven
or eight years ago to stick to mysql - for an email provider with 76
million ++ users, on the fly replication of userdb and such.
Oh, seven or eight years ago I would absolutely agree with you. At
that time there was no other choice worth considering if you could not
afford Oracle.
When you want blazing fast searches on a large db (but a simple one)
mysql's the db for you. [well it was then .. and if we change we'd
have to
rip the guts out of more than one system and migrate massive databases
over, so .. as it works quite fine, we'll stick with it]
These days, PostgreSQL is faster by almost any measure than MySQL,
even for simple queries, and comes with a number of benefits. That
10-20% speed increase with each PostgreSQL release compounded into
something interesting -- for OLTP it is getting very close to Oracle.
I think most of MySQL's popularity is legacy, and it is not very
portable as an environment. Migrations between Oracle and PostgreSQL
are easier than, say, PostgreSQL and MySQL.
My original comment was more that Google using MySQL -- even when an
inappropriate choice -- was not particularly based on merit as best as
I've ever been able to figure. Not my problem for sure, but it is
interesting to observe because some technologies they seem to change
on a whim. The PostgreSQL engine, to use it as the obvious counter-
example, has been hacked many times to support robust distributed
systems that are much larger than anything you see people doing with
MySQL, being a much more hackable system generally.
Given no legacy to support, I think Google would still choose MySQL.
The "why" is an interesting question of culture, and undoubtedly has
ramifications with respect to the success and failure of companies
over the long-term.
- Cringely pretty conclusively demonstrates in the article that he
has no idea what "cloud computing" actually is, what you can and
cannot do with it, or why it is important. Messy transaction
theoretic and latency issues do not magically disappear when Google
implements yet another compute cloud.
Well yes, I do cringe, quite a lot, when I read quite a lot of his
work.
But distributed systems work rather faster when most of them are on
the
same switch, in the same datacenter, I dare say?
Yes, definitely. Even between geographically separated data centers
there is likely to be more effective bandwidth than between any one
data center and an individual user. The interesting thing is that
most of these services currently are not distributed systems in the
classic sense, but merely high availability conventional services.
Even if you built a data center infrastructure that allows seamless
data/service integration across the data center, that only solves part
of the problem.
A bigger problem is that in many cases it is not possible, politically
or technically, to backhaul data to a single data center. How do you
optimize data and service integration in this case while maintaining
the illusion of the "cloud"? Literature contains most (but not all)
of the answers to this question, but no one seems to be thinking about
it much and it is an early architecture decision. Hell, most of these
cloud computing services are barely thinking about simple data
integration between unrelated applications at this point.
Cheers,
J. Andrew Rogers
