Re: Interesting article, Facebook woes using MySQL - Mailing list pgsql-general

From Chris Travers
Subject Re: Interesting article, Facebook woes using MySQL
Date
Msg-id CAKt_ZfuUL8UjFbR_cNFZ36R5Aqpp=GUw4J6GxF7UdrYt4dKJ5g@mail.gmail.com
Whole thread Raw
In response to Interesting article, Facebook woes using MySQL  ("Gauthier, Dave" <dave.gauthier@intel.com>)
Responses Re: Interesting article, Facebook woes using MySQL
List pgsql-general
On Mon, Jul 11, 2011 at 12:50 PM, Gauthier, Dave
<dave.gauthier@intel.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

pgsql-general by date:

Previous
From: hyelluas
Date:
Subject: Concurrent read from a partition table.
Next
From: Craig Ringer
Date:
Subject: Re: Accidentally truncated pg_type