Hi Charles,
YouTube have very large files, which rarely get modified or deleted, and
the time to transfer between servers doesn't matter.
Email is very different. If an email comes in on one server, it needs to
be immediately available to all servers, including all the attachments.
The way that DBMail handles the emails is excellent in my opinion. It
uses constraints so that if an email is deleted, the attachments etc
also get deleted. So no messy code in the software to manage what
attachments are where.
The problem with having the data split between the database and the
filesystem is that you can't guarantee that any backup is valid unless
you shut the system down or use snapshots. And then you can't do
point-in-time recovery, so any restore from backup you do will lose data.
From my tests, the DBMail system is quite fast, not as fast at
delivering over network as NFS or locally as direct to the filesystem,
but definitely a lot faster when reading (which is what matters most) as
it can just pull the headers out without having to scan through files.
Regards,
Josh.
Charles A. Landemaine wrote:
I see your point. I was thinking about an architecture like YouTube
where each video is stored on one of the numerous servers they have
(not in a DB). When you delete a mail, the application could delete
the file on the SAN and send the SQL query to the DB. If anything goes
wrong (ie: data loss, data corruption...), you can restore the latest
backup. What do you think? By the way, do you think storing the
attachments in the database make it less fast?
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
