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
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. |