On Mon, 2003-07-28 at 19:32, Ed H wrote: > how is dbmail in terms of large user bases. ie, 20,000 or 50,000 or 100,000 > user base? > IC&S has deployed implementations of over 20,000 without problems I believe.
> Seems like putting all your eggs in one basket (dbase) is very risky. Not > only that but the access time would grow for larger databases. This is not > as critical for file system MTA's. > That's completely false. You're still storing it on a disk, so the reliability is the same, store your db on a raid5, or store flat files on a raid5.... its the same thing, raid5 loses more than one disk at a time and you're hosed either way, so the only way to be sure is to have archived backups, or hot systems (replicated db's). As for the access time, that's true, in part, but the second part of your statement is false. file system mta's with large numbers of users will suffer tremendously compared to a db. A db is an indexed, organized storage, flat files are sequential only. So when you have large mailboxes, a database will win over flat file for access time since it doesn't have to seek the whole file to search a message in the middle. Of course, if you're only running pop3 and your clients are behaving appropriately (downloading all messages every time) a flat file might show a performance benefit (since it is a sequential read and all the other indexing isn't needed). But some clients will skip messages they've already downloaded, requiring an expensive seek without an index as to where to look, and pop3 is becoming less popular as imap (as a direct protocol, or the backend of a webmail system) becomes more popular, which don't regularly do a sequential read. In addition, file access becomes increasingly slow when you have thousands of files in a directory, or thousands of directories in a directory with hundreds of files in those subdirectories... Flat files do not win in any scenario other than ease of installation on extremely small setups. Ryan Butler [EMAIL PROTECTED]
