Migrate MySQL... or not...

[Christopher Browne]

On Mon, Aug 31, 2009 at 8:57 PM, tug<tug.williams-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org> wrote:
> The test cases that interest me personally are trivial - and as such I think
> both Postges and MySql are sufficiently sufficient.
> 1) Running a single (maybe dual) user phpBB
> 2) Using a simple set of tables for recording data and loading it into
> application memory for processing. (think historical market data, texts for
> writing style analysis)
> 3) etc... ?

Yes, for such cases, you're almost certainly right.  If your
requirements are sufficiently trivial, then there's little reason to
strongly prefer either option.

Indeed, I think both might even be overkill for a lot of "web
application" scenarios; for sufficiently simple systems that do not
require concurrency, SQLite is quite likely to be preferable to either
Postgres or MySQL(tm).

- DB in single file...
- Runs as a library added onto your app
- Intentionally sparse in overall functionality, but tends to be a bit
better than the "elderly MySQL(tm) releases" that used to be a common
"lowest common denominator"

> Other people may have slightly higher requirements of their databases I'm
> sure. :)

Yeah, and (to grouse a little :-)) if you're looking for a comparison,
then that suggests that you might be interested in the sorts of
characteristics that *would* distinguish between the systems.

If your needs are so modest that the distinguishing characteristics
don't matter, well, that's a little sad...

> Tests should benchmark databases from open source projects only so
> - everyone can know the database requirements,
> - someone else has to deal with database compatibility
> - if a given database performs poorly on a given engine due to suboptimal
> use, then the champions of "ugly suboptimal baby" can improve the
> application if they care enough
>
> Ideally this could be a live CD that could be used to automatically perform
> comparable tests on a wide variety of hardware.

The trouble is that this isn't necessarily in vendors' interests.

If you do this sort of thing with Oracle or Microsoft's port of
Sybase, you're liable to get *sued* because they don't want any
numbers published unless they release them.

It's also not necessarily in Oracle's interests (as apparent owners of
the MySQL trademark), as it doesn't necessarily allow their product
(they bought MySQL(tm) when they bought Sun) to be seen in the best
possible light.

Traditionally...

- Most benchmarks involving MySQL(tm) involved using single-user
non-concurrent, non-transactional loads, which is a kind of load where
MyISAM "plays best," and where nothing else looks nearly as good.

- On the other hand, a benchmark with more than about 4 concurrent
heavy-hitting update processes will grind MyISAM to a halt (table
locking's a problem!).

- Strangely, you see almost *no* benchmarks involving InnoDB (and
since Oracle has owned it for quite some time, you almost certainly
won't be allowed to publish one); note that this would be the
"concurrent load" optimization for MySQL(tm)

> Results - low hanging fruit...
> - Measures of performance.
> - Measures of reliability
> - ANSI compliance
> - etc?
>
> Subjective fruits...
> - ease of use / documentation
> - quality
> - future quality
> - etc...?

I'm a little curious as to what's falling out of all the MySQL(tm)
forks (e.g. - Drizzle, MariaDB, Percona, OurDelta, in addition to
MySQL(tm) and InnoDB).

The division of efforts is almost certainly a bad thing for MySQL(tm),
as it generally can't make use of any of the code contributed to the
others.

It'll be interesting to see what falls out after another year or so.
-- 
http://linuxfinances.info/info/linuxdistributions.html
Ted Turner  - "Sports is like a war without the killing." -
http://www.brainyquote.com/quotes/authors/t/ted_turner.html
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists