Re: Interesting article, Facebook woes using MySQL

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: Interesting article, Facebook woes using MySQL
Дата
Msg-id CAKt_ZfuUL8UjFbR_cNFZ36R5Aqpp=GUw4J6GxF7UdrYt4dKJ5g@mail.gmail.com
обсуждение исходный текст
Ответ на Interesting article, Facebook woes using MySQL  ("Gauthier, Dave" <dave.gauthier@intel.com>)
Ответы Re: Interesting article, Facebook woes using MySQL
Список 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 по дате отправления:

Предыдущее
От: hyelluas
Дата:
Сообщение: Concurrent read from a partition table.
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Accidentally truncated pg_type