I'd like to point out a few things: * The added complexity of storing and synchronising files on disk with records in tables, especially in a load-balanced, high available situation, is much more work than any returns you'll ever get.
* Whether the emails are stored in the database or the filesystem (which is really just a database) is not going to be that much difference. Databases can be a bit inefficient for space at times but this is usually to increase speed. * I'd like to see 3 or 4 mailservers performing imap searches over an NFS share to get to the mailbox files or messages. Then we can really compare speed of the database vs filesystem in a networked environment * I'd like to see a system administrator easily recover all the emails for a mailbox since the last time cleanup was performed. Hint: update dbmail_messages set deleted_flag=0,status=0 where mailbox_idnr in (select mailbox_idnr from dbmail_mailboxes where owner_idnr IN (SELECT user_idnr from dbmail_users where userid='mail...@userdomain.com')); * I'd like to see fine-grained point-in-time recovery for the filesystem-based (or hybrid - scary) systems. Yes it would take a while for any system depending on mail size. * I'd like to see impact-free daily backups for filesystem-based systems. With dbmail, just have a slave replica you can pause replication on to get a perfect snapshot, with no impact on the live database during the backup duration. * Remember that with any mail system that has a huge amount of data, things are going to take time. Databases have more records to search through (although indexes can help speed this up). mbox are basically a crude database storing all the emails in one file so large mailboxes can take a very long time to work with. Maildir is good until the inbox gets so many small files that just the directory listing takes a long time. If you're going to have a large mail system, be aware that things will take time, or use multiple systems and a system like perdition to split up the mailboxes, or have an archive system for users to place old emails they want to keep in. * As for mail delivery speed statistics, take them all with a grain of salt. Our experience is the bottlneck for inbound mail is the antivirus and antispam stage, and with the huge amount of spam hitting our servers (90+% of all connections) it is actually faster to detect and reject spam than have the mail deliver into the mailboxes. Finally: * Mail systems that don't require high-availability, failover or networked environments for load balancing would probably be better to just use mbox or maildir, for simplicity. For mission-critical systems there are more items to consider before deciding which option to take. Josh On Thu, 2009-12-10 at 12:03 -0800, tabris wrote: > Reindl Harald wrote: > > Am 10.12.2009 20:23, schrieb Tomas Kuliavas: > > > >> Correct solution is not to store email data in DB. I think any sane DBA > >> could say you that. Don't store binary data in DB. > >> > > > > What stupid statement in context of DBmail > > > Only because dbmail already does hte opposite. Frankly, I don't think it > would be such a _terrible_ idea to design dbmail to keep the > dbmail_mimeparts as files, rather than part of the database. But I > certainly don't expect that change to come anytime soon, if ever. _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
