At 12:24 PM 11/9/2010, Sandeep Srinivasa wrote:
>There was an interesting post today on highscalability -
><http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html>http://highscalability.com/blog/2010/11/4/facebook-at-13-million-queries-per-second-recommends-minimiz.html
>
>T
>
>I wonder if anyone can comment on this - especially the part that PG
>doesnt scale as well as MySQL on multiple cores ?
The "multiple cores" part is unlikely to be very relevant in the
Facebook context.
Scaling over four or 8 cores is not a biggie nowadays right? From
what I've seen the Facebook, Google type companies tend to use LOTS
of cheap servers (dual core, quad core, whatever Intel or AMD can
churn out cheaply). I doubt they use >=32 core machines for their
public facing apps.
What's more important to such companies is the ability to scale over
multiple machines. There is no way a single server is going to handle
1 billion users.
So they have to design and build their apps accordingly, to not need
"massive serialization/locking". When you post something on Facebook,
nobody else has to wait for your post first. Nobody cares if their FB
friend/likes counter is "somewhat" wrong for a while (as long as it
eventually shows the correct figure). So scaling out over multiple
machines and "sharding" isn't as hard.
Whereas if you require all posts to have a globally unique ID taken
from an integer sequence that increases without any gaps, it becomes
a rather difficult problem to scale out over many machines. No matter
how many machines you have and wherever they are in the world, every
post has to wait for the sequence.
As for why they used mysql- probably the same reason why they used
php. They're what the original developers used. It doesn't matter so
much as long as the app is not that slow and can scale out without
too much pain.
Regards,
Link.