Hello,
I agree about splitting the message into parts that fit MIME/POP
standard queries. This will speed up the database.
Is there any alysis done on the mail system database query types?
Do we have any data on the typical message size?
The subject of storing part of the message as a file has been
covered a couple of months before.
The reason to stora an attachment as a file is performance.
On a web server with many hits will this drastically reduce the
load of the database/web server.
A mail server is a little bit different, you only access the
attachment a very few times, mostly only once.
How do you write the database code to keep track of the
individual files?
How many files can you store in one directory, earlier linux file
systems had a limit of 65535 files per directory. How long time
will it take to search such a heavy loaded directory. You know a
filesystem is just another slightly different optimized database.
I believe you actually will need to go to another file system
than ext2/ext3, i.e. XFS, to get a performance benefit compared
to a correctly indexed database.
To return to the web server images in file optimization,
remember, this is apache that is doing the file system lookup, in
a limited number of images.
Huge mail servers have signifantly more attachments.
Also, remember that the number of inodes on the disk is limited,
my 9GB partition has around 1.1 million inodes, this is typically
8kbyte data per inode.
Well, apache can use the sendfile syscall, and you can do that if
you have the data in separate files, but how much is the gain?
I strongly beleive that we shall follow the path of improving
functionality and keeping the source code as clean and simple as
possible using two different methods of storage increases the
code complexity with from my point of view a very small gain.
The small organisations don't need top notch performance.
Huge organisations can afford the required hardware.
just my SEK 0.16 (=approximately US$0.02)
/Magnus
Ricardo Andere de Mello wrote:
I have my two cents about these message storage ideas...
The message is now broke into many parts because some database concerns,
correct?
Why not broke into MIME parts, just like the messages are organized?
why not get out binary content from the database? I mean, an image does
not need to be "searched", so why not keep it as a simple file? the name
of the file coult use an id and the user name, and would save processing
power from the database.
In fact, I think any attachment can be out from the database. Can you
imagine a real world situation where you NEED to search inside an
attachment?
[]s, gandhi
