[ic] MySQL is great with interhchange.

Boyd Lynn Gerber interchange-users@lists.akopia.com
Wed Jul 4 20:17:00 2001


Date: Wed, 4 Jul 2001 02:55:41 +0300 (EEST)
From: Michael Widenius <monty@mysql.com>
To: interch <interch@web3.valley-internet.com>


Hi!

Chris> As far as the database issue, mysql is great if you don't need
Chris> transactions, or if the data isn't mission critical.  I would feel much
Chris> safer with my data in postgresql than mysql.  I have had mysql eat data
Chris> files on several occasions on recent versions even.  It simply wasn't
Chris> designed for mission critical applications.  We have found that postgresql
Chris> also scales much better with a lot of concurrent accesses by multiple
Chris> users.
Chris>
Chris> Chris

Sorry for jumping into this discussion, but I feel that I need to
defend MySQL a bit here...

Chris, I have to disagree with your statements; MySQL was from the
start designed for mission critical applications and has over the
years proven over and over again that it's very good at handling
these. We have lots of users that uses MySQL in critical 24/7 systems
with millions of queries per day, with very good results.
(You can find a lot of well known names on our MySQL-users page)

I agree that MySQL have had problems with thread libraries from time
to time on different platforms, but as long as one uses a binary we
have made available at www.mysql.com, MySQL has generally been very
stable.  (The binaries at www.mysql.com are tested on the platforms
for which we provide them and includes patched thread libraries
for various platforms).  For example, if you are using Linux with
gcc 2.1 or before and are not using the Linux binary we have provided,
you will get performance problems when running with many threads.

As you should now, we have recently added transactions to MySQL, to
satisfy those users that require transactions in their applications.
For example the InnoDB table handler, have (according to what I know)
all the benefits that the transaction engine in PostgreSQL provides,
but without the serious limitations, like having to regularly use
vacuum, that makes PostgreSQL very hard to use in a 24/7 system.

By having the possibility to use both transactions safe and and non
transactional table handlers gives MySQL an edge that makes it real
hard for PostgreSQL to catch up.

I have also not seen a single repeatable open source benchmark that
would show that PostgreSQL is even remotely as fast as MySQL.  In most
common cases, MySQL is 3-8 times faster than PostgreSQL, even after we
have turned of the syncing to disk from PostgreSQL (after which it's
not ACID anymore).

You can find a lot more information about how we compare MySQL and
PostgreSQL at:
http://www.mysql.com/documentation/mysql/bychapter/manual_Comparisons.html#Compare_PostgreSQL

The MySQL benchmark page was also recently updated with a comparison
between the MySQL and the latest PostgreSQL version.  I had intended
to run the benchmarks with PostgreSQL with and without disk syncing,
but after PostgreSQL one time filled up a 4G disk with log files (this
shouldn't have happened in the context I used PostgreSQL) and another
time crashed all data in the database (non-recoverable, at least with
my knowledge about PostgreSQL), I wasn't able to run all different
versions of the benchmarks I had intended from the start.

Note that I don't with the above try to claim that PostgreSQL is
unreliable; It just has some strange bug that the benchmark suite
seems to trigger over and over again.  It's probably not that likely
to be trigger under normal use, as in this case the PostgreSQL
developers should have fixed this already.  It could also of course be
something in the new code for WAL files, but that should hopefully be
sorted out soon.

Chris, if you think you have found a bug or serious problem in MySQL,
I would recommend you to post a question to mysql@list.mysql.com about
this; I am sure you can get help in finding out what is causing your
problems.  To just state that MySQL has lost data without providing
any context, makes it real hard for me to offer any advice to you.

If you have any benchmarks that shows that PostgreSQL scales better
than MySQL I would really like to know about these; There is always a
change you are doing something wrong that MySQL can't handle
gracefully (One thing I saw recently was running a lot of queries with
tables without any indexes) or using some special feature that is
faster on PostgreSQL.  If the later is the case, I would certainly
like to know about this!

Note that I don't say that PostgreSQL isn't a good database; It's has
a lot of nice features that MySQL doesn't yet have (and vice versa)
and for users that critically needs the features only PostgreSQL
provides, PostgreSQL is probably a good choice.

When one has a need for speed, MySQL is however in most cases a much
better choice;  (As always this depends on the application;  The only
way to know for sure is to test both databases with a program that
simulates the application).

Regards,
Monty


On Tue, 3 Jul 2001, IC-Admin wrote:

>
> I am wondering if someone from the RedHat staff might give
> advice for longterm planning with regards to the best database
> to use with IC.
>
> I remember quite some heated discussion here some months ago
> about the pros and cons of MySQL and PostgreSQL for IC. Now
> with RedHat providing their own RedHat database based on
> PostgreSQL 7.1 would you advise some data-heavy, but cash-starved
> with IC-playing student to invest his learning time in PostgreSQL
> instead of MySQL, thinking that may be in the future you
> combine your services for the RedHat database with your services
> for IC ?
>
> Also, Mark Johnson said in another context with regards to the
> admin UI for GDBM and/or other relational databases:
>
> 	It's not for GDBM only; it also functions perfectly well with a
> 	relational db. The problem is that it fully supports the use of GDBM,
> 	and in order to do that, the feature set has to adhere to the lowest
> 	common denominator. Only if and when a decision is made not to support
> 	the GDBM data model will IC be able to use higher-level features of a
> 	generic RDBMS. Even still, you quickly run into variations that limit
> 	what can feasibly be done based on whichever database you use.
>
> Does that mean that you will eventually drop the support for the
> GDBM data model ? (not that I understand why, but I would regret it)
>
> In addition David Adams said once with regards to CCVS support :
> 	The integration of Interchange and CCVS should be a part of version 4.8 as
> 	planned.  The integration of CCVS and Interchange is not dependent on
> 	assistance from any CCVS engineers, original or otherwise.  The CCVS SDK
> 	is pretty straightforward.  Red Hat continues to support the CCVS
> 	product. There are still several potential scenarios for where
> 	CCVS will be heading in the future, though.
>
> Is the integration of CCVS still planned for version 4.8 ? Do you think
> that RedHat comes out with a newer version of RH Linux 7.1 before IC 4.8
> is ready ? Is there a compelling reason to wait for IC 4.8 and the next
> RH Linux version because of possible tighter integration of the RH
> database and CCVS with IC ? Thanks.