Thread: Interesting article, Facebook woes using MySQL

Dne 11.7.2011 21:50, Gauthier, Dave napsal(a):
> http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/
>
> How would PG stack up in a usage situation like this?

This article (and the slashdot discussion) was already mentioned in the
pg-advocacy list

  http://archives.postgresql.org/pgsql-advocacy/2011-07/msg00008.php

although it's mostly about the slashdot discussion - misconceptions,
falsehoods and flame baits presented there. I don't think the slashdot
it worth reading, it's full of nonsense (not a big surprise) and it's 48
hours old (which means 'dead' in slashdot terms).

Regarding the article itself, it contains very little information about
the "new SQL" - in short it just says three things:

 (1) It's difficult and expensive to build ACID-compliant distributed
     system using traditional RDBMS, especially if you don't know in
     advance you need to design it like that.

     This is where Stonebraker pokes into MySQL (or rather how Facebook
     used it), and I guess about the same could be true for PostgreSQL.

 (2) The NoSQL may help you to solve this problem when you don't need
     a relational storage and you have to respect the CAP theorem.

 (3) The "New SQL" is said to be the cure, i.e. SQL with advantages of
     NoSQL and without the disadvantages. As much as I respect
     Stonebraker, I doubt this can be done without breaking the CAP
     theorem but maybe I'm missing something ...

I personally see the article as a propagation of VoltDB, but that does
not mean it's a bad product. I guess it's time to play with it a bit.

regards
Tomas

On Mon, Jul 11, 2011 at 2:50 PM, Gauthier, Dave <dave.gauthier@intel.com> wrote:
> http://gigaom.com/cloud/facebook-trapped-in-mysql-fate-worse-than-death/

Well, Stonebraker is pitching (for the Nth time) a "revolutionary"
platform, VoltDB, which naturally brings up concerns about bias. For
example, it's not clear why 1,800 servers running mysql is necessarily
a 'fate worse than death'.  Reading the article I find myself asking,
'what is the problem that needs solving here?'.

I bet postgres would do just fine for facebook although it would take
a lot of tweaking to get maximal numbers.

merlin

On Mon, Jul 11, 2011 at 03:53:20PM -0500, Merlin Moncure wrote:

> example, it's not clear why 1,800 servers running mysql is necessarily
> a 'fate worse than death'.

Speaking personally, I find even one server running mysql (if it's my
responsibility) is pretty enervating.  I can imagine 1,800 could be
worse than death.

A

--
Andrew Sullivan
ajs@crankycanuck.ca

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

Hi all

2011/7/12 Chris Travers <chris.travers@gmail.com>:
> I am not convinced that VoltDB is a magic bullet either.  I don't

I have the chance to help preparing an interview with Mike
Stonebreaker to be published at www.odbms.org
I'd really like to know, if he is up-to-date how Postgres performs
these days and how he thinks how VoltDB overcame the overhead he
claims to exist in "old elephants".
Do you all have more questions to Mike?

--Stefan

On Tue, Mar 13, 2012 at 01:22:18AM +0100, Stefan Keller wrote:
> Hi all
>
> 2011/7/12 Chris Travers <chris.travers@gmail.com>:
> > I am not convinced that VoltDB is a magic bullet either.  I don't
>
> I have the chance to help preparing an interview with Mike
> Stonebreaker to be published at www.odbms.org
> I'd really like to know, if he is up-to-date how Postgres performs
> these days and how he thinks how VoltDB overcame the overhead he
> claims to exist in "old elephants".
> Do you all have more questions to Mike?

I'm curious what he thinks about the role of the optimiser. IME
postgresql wins for my workloads simply because PostgreSQL is smart
enough to perform the joins in the right order and use the right
indexes. MySQL seems to have some heuristics which are wrong just often
enough to be irritating.

Oh yeah, and it doesn't have CREATE INDEX CONCURRENTLY, that's *really*
annoying.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> He who writes carelessly confesses thereby at the very outset that he does
> not attach much importance to his own thoughts.
   -- Arthur Schopenhauer