Re: Interesting article, Facebook woes using MySQL

From: Chris Travers <chris(dot)travers(at)gmail(dot)com>
To: "Gauthier, Dave" <dave(dot)gauthier(at)intel(dot)com>
Cc: pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Interesting article, Facebook woes using MySQL
Date: 2011-07-12 01:18:08
Message-ID: CAKt_ZfuUL8UjFbR_cNFZ36R5Aqpp=GUw4J6GxF7UdrYt4dKJ5g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Jul 11, 2011 at 12:50 PM, Gauthier, Dave
<dave(dot)gauthier(at)intel(dot)com> wrote:
> http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/
>
>
>
> How would PG stack up in a usage situation like this?

My sense is that Pg would stack up no better. I suspect to make this
work at this scale you'd have to sacrifice a lot of RI checking etc.
and probably resort to similar tricks as with MySQL.

I am not convinced that VoltDB is a magic bullet either. I don't
think you can guarantee both consistency and speed across a database
of that size, so you end up having to sacrifice one or the other.
ACID compliance shouldn't generate nearly as much overhead on inserts
of facebook likes as just simple things like verifying that the post
one is liking actually exists, etc. In theory column-oriented
databases come out ahead on those reads, but I would expect more
overhead on writes (random seek for each field written?). So it might
solve some problems but whether it would create others and whether
there was a positive tradeoff is a good question.

Best Wishes,
Chris Travers

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Parker 2011-07-12 01:23:27 Alter Columns with Triggers
Previous Message hyelluas 2011-07-12 00:31:31 Concurrent read from a partition table.