Alessandro Razeto wrote:
It's no problem to store a mail in the database instead of "1" but please think about the size of this file:
2.000 bytes per encrypted PIN mail 1.000.000 users --------------- 2 GB of data some overhead for the organization --------------- --> one single file which is greater than 2GB
From a thechical point of view one so large dbm file will be quite slow,
and I'm not really sure it will be better than several milion of inodes.
The overstress of the fs can be reduced using a fs optimized for fast
inode access, like in linux reiserfs. Using a postgresql server would be much better.
i think the main-problem with filesystems is the way how you get the content of an directory (not the inodes), since the directory is a single file with all entries... this would at least rise the ammount of used memory for the running script if its reading the dir-file...
since we have to dbm files per mailtype (one for imported and one for sended) one could think, lets take them, but in case of dbm we would have to access every time the imported and sended dbm to check if an id is in both or not, like we do it now with the directory and the sended-dbm, this isn't optimal at all, for single queries like, if this id in or not, it is ok, but if do something like: select id from imported where id is not in sended (to put it literarly) we get quite slow i think or is an query like this possible with two dbm files? at the moment we do this, but by hand with foreach loops of the directory-entries...
so there would a switch to a reals dbms a real speed improvement - i think (the dbm files are cached, so there is only one real fileaccess per dbm file, so this isn't a real problem)
i havn't tested this, but if we get into high amount areas it may be more stable and faster
and i also like olivers idea, and i don't see a problem with storing the emails/crin-mails in a blob in the database, this would be a clean and stable and scalable solution, much more independet from the used filesystem of the server at all...
A DBM file with BTree as datamodel is not slower than PostgreSQL which use the same technology. Nevertheless there is an open discussion in the
yes, thats what i thought too ,o) for a single query of one key
OpenCA group what we do in the future with our database backends because
so may we open a new thread for this?
greetings dalini -- Ives Steglich Email: [EMAIL PROTECTED] System Administration Tel.: +49 (0)3677 - 69 4382/4383 Fax: +49 (0)3677 - 69 4399
Fraunhofer Institute for Digital Media Technology Langewiesener Strasse 22 98693 Ilmenau Email (private): [EMAIL PROTECTED] Germany http://www.openca.org
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ OpenCA-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/openca-devel
