On 16/02/07, Wakko Warner <wakko@???> wrote: > Wouter Verhelst wrote:
> > On Fri, Feb 16, 2007 at 04:56:53AM +0800, W B Hacker wrote:
> > > Richard Pitt wrote:
> > > > SQL generally requires far
> > > > more resources for similar performance - especially with "blobs" of any
> > > > size.
> > >
> > > Not 'generally'. 'Always'. And by a large margin.
> > >
> > > At the end of the day any DB must *also* map to the underlying fs -
> > > and not just the raw data - but all of its own overhead, logs, checks
> > > and balances, bells and whistles.
> >
> > You're oversimplifying here. Kernels have the ability to switch off
> > caching (O_DIRECT, etc), metadata-updates, and similar, for specific
> > files, and database servers generally use those APIs.
> >
> > It's also perfectly possible in some cases to run a database directly on
> > a raw device ('/dev/XXX'), and bypass the filesystem entirely.
> >
> > Finally, if you run a mail store on a filesystem, you usually require
> > many files -- exim requires two files per mail in the mail store. Most
> > database systems dump all their tables in one file, so the stress on the
> > filesystem implementation isn't as extensive.
>
> Also, if implemented in a specific way, the exim spool when stored in SQL
> could save on disk writes when delivering locally, only 1 copy of the
> message is ever written. The user accounts could just point to the body
> part of the message as it was in the spool. It would be deleted when
> there's no more reference to it. Kind of like storing your mail spools in
> maildir format and every user who gets a copy of the same message is
> hardlinked to the same physical file.
'SQL', of course, is not a storage mechanism, it's a query language -
there is a multitude of RDBMSs available for the platforms on which
Exim runs, and many more for those on which it doesn't but will
interface with over some network, and each of those typically has a
wide varierty of underlying storage engines controlling how data is
physically laid out on disk, how its cached, how it can be optimized
given known access patterns, etc etc.
Any statements about how efficient/effective/resilient/etc 'SQL' is
need to be qualified by reference to a specific implementation of a
specific RDBMS in order to be useful. Even the single-instance storage
that Wouter refers to above (which MS Exchange has had since day 1, by
the way :-)) may not actually turn out to be more efficient in all
cases than a more straightforward filesystem mailstore.
