Re: Seriously, WTF?

On 8/5/08 12:30, "Paul Makepeace" <paulmpaulm.com> wrote:

> Not that a good yarn isn't appreciated, but... Saying
"MySQL 3.1
> couldn't handle my incredibly complex queries" is
rather like saying
> "I switched from MS-DOS to Unix as the command
line tool weren't up to
> what I needed" -- a historic anecdote, and a
somewhat self-evident one
> at that. It doesn't really add anything to a modern
"Which RDBMS?"
> discussion. (Maybe you didn't intend it to; just
sayin').

 point
taken.

A colleague of mine looked up the bond.pm emails from the
time I was going
through this pain, and we just chatted about this a little
more...  I did
most of my work on this transition back in December 2005...

> MySQL 5.1 is great product and I'm quite certain these
days you
> wouldn't run into the problems you've talked about.

I *did* test out with MySQL 5 (which I believe was still
beta), and this was
executing the queries in question in 6s, but suffered from
exactly the same
scaling issues.  So if I deployed it I would still have had
the same
problems.  I needed a solution there and then...

Inevitably my tale will remain anecdotal - for it to be
anything but I'd
have to run a heap of benchmarks on both MySQL 5.1 and
PostgreSQL 8.3 with
all the old data.  I'm incredibly unlikely to find the time
to do that.
Given my experiences, I have my doubts that 5.1 will be much
better than 5.0
anyway for the use case I was putting it to.

For me MySQL is very much a case of once-bitten, twice shy,
as I'm sure it
is for many other people around here.

> An interesting story would be hearing how your company
handles
> redundancy, backups, and disaster recovery drills, with
Pg.

Unfortunately KarmaDownload didn't last beyond June 2006. 
It was always
*severely* resource constrained, so didn't have the
resources for any real
redundancy.  "pg_dump" was the backup tool...

Steve

Steve Sims wrote:
>> MySQL 5.1 is great product and I'm quite certain
these days you
>> wouldn't run into the problems you've talked
about.
> 
> I *did* test out with MySQL 5 (which I believe was
still beta), and this was
> executing the queries in question in 6s, but suffered
from exactly the same
> scaling issues.  So if I deployed it I would still have
had the same
> problems.  I needed a solution there and then...

The real issue with MySQL scalability is to do with which
backend engine 
one uses. If you were using 3.1 then you were using MySQL
native isam 
tables (there being no choice at the time) - these are OK
*provided* you 
have enough RAM to hold the whole index in memory. With
eight tables + 
indexes, I don't imagine this requirement held. Hence the
crappy 
performance.

This limitation is, IMHO, one of the reasons behind MySQL
going 
multi-backend. In effect you now have (at least) three
storage engines, 
each with a common front end. Each of these engines have
completely 
different scalability / speed characteristics and
tradeoffs.

Dirk