* on the Thu, Feb 15, 2007 at 08:57:02AM -0800, Richard Pitt wrote:
> I can think of a couple of reasons to do this - and lots not to:
>
> for: scalable central store that multiple machines can address with
> better?(different) locking than NFS provides
> for: different security model from disk store
For: replication - "instant" "backups"
> against: performance - today's disk systems are essentially hierarchical
> file systems anyway - especially like Reiser. SQL generally requires far
> more resources for similar performance - especially with "blobs" of any
> size. RAM for SQL server takes away from RAM for disk caching.
Yeah. Don't forget the db doesn't need to be on the same box as the mail
server though.
> against: most messages don't hit the data store anyway if the system is
> working the way it is supposed to
> against: central database can't be replicated (potential for multiple
> deliveries of single message) so scalability is limited and means a
> single point of failure
Not sure what you mean here. I know it could scale well with MySQL5.
Especially with the recent clustering capability, and multi master
techniques. I'm assuming other db's will have their methods too...
> There are likely others
There's not a lot of point storing your mail in a database if there
isn't a pop/imap server that can access it.
Someone recently mentioned the possibility of abstracting the storage
out so multiple types of backend could be implemented. That's one
of the best ideas I've heard in a while.
