my 2c,

MySQL supports transactions. Supports everything needed even for large
scale projects, unless you plan to start a new Yahoo.com, *maybe*. Oh,
and last time I heard (which may not be accurate by now), Yahoo
Finance was using it.

It supports replication. If you're wise, you'll put the write
operations in ATA SCSI disks, **properly configured** via hdparms,
using a kernel optimized for that kind of operation. Splitting an
application reads through different servers helps as well. It's *easy*
to be done. Larga scale applications *should* split their requests, or
at least have this as a feature (off or on). The service scales
easily. It comes with the resources for that. It's a matter of using
it.

MySQL isn't different that most FOSS around: the vanilla package was
made to work in most scenarios. If you download it binary, run, and
expect it to handle billions of records, you have the wrong idea of
how stuff works in this world. Same logic as if you're dealing with,
say, Apache, or even Linux. There's a book around called "High
Performance MySQL", from O'Reilly. It isn't great only because all
that info can be found for free, but if you're not willing to search,
buy it, and put the knowledge in practice.

If you're willing to become the expert, do the same with kernel
optimizations. Then you'll eventually know how to shape an OS for
hosting a database for large scale projects. By that point, you'll
realize you don't need to pay licenses for commercial databases, who
actually do all the forementioned through wizards. If you're not
willing to become one, then get somebody to do it. I'm sure you'll
spend less than you would with a license for an Oracle db.

It *will* handle large scale projects.


On 7/19/05, Jamie Honan <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 19, 2005 at 11:20:22AM +1000, Peter Chubb wrote:
> > >>>>> "Howard" == Howard Lowndes <[EMAIL PROTECTED]> writes:
> > Howard> Can anyone provide pointers to good reading material on the
> > Howard> comparisons between the various Unix databases.
> 
> Peter Chubb:
> > I'm interested in this too.  The general impression I get from `real'
> > users is that Oracle is the only choice for a serious database app at
> > the moment.  Personally, I'd prefer to use an open-source engine; but
> > then you have Postgres as the only serious contender.  Msql and mysql,
> > SQlite, grokbase, etc., are fairly limited (although reasonably fast for
> > small-scale use).  At least, that's my impression.
> 
> For very large sites, expensive if things go wrong, I've seen Oracle
> and several years ago, Informix used. Informix especially on SCO.
> 
> Mysql would have been out of the question years ago, with no support
> for transactions. Now, I'm not so sure.
> 
> The impression I get with Oracle is that it is safe bet, and risk
> aversion is one of the priorities for many people.
> 
> The major thing that a database is used for, especially in web apps.
> is concurrancy control. This is a huge issue with the numbers of users
> and numbers of hits that large sites have.
> 
> This document, I think, gives a pretty good roundup of the kinds
> of sites that have grown up.
> http://homepages.inf.ed.ac.uk/wadler/Service%20Architectures.doc
> (Unfortunately the graphics don't scale properly in OpenOffice, but
> they are very worthwhile.) I hope to base some of my talk on
> Apache2, large sites and concurrancy on some of it.
> 
> The author makes the point that everyone starts off treating the db
> as a 'blackbox' sql engine, with interfaces such as perl dbi,
> but before long starts to integrate more and more into things like
> PL/SQL and embedding special constructs in their application code.
> That's been my experience too.
> 
> However, I despair of SQL databases. They don't have rich expressions,
> their performance is hopeless.
> 
> Many a warehouse, accounting and invoicing systems are still run on
> Pick/Universe.
> 
> As for small scale use, I think databases are often used when they shouldn't
> be. The filesystem is a pretty good database too,
> 
> Just my 2c.
> Jamie
> --
> SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
> Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
> 


-- 
Julio C. Ody
http://rootshell.be/~julioody
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html

Reply via email to