Question

I’m storing emails in a mysql-database and was wondering if it’s a good idea to use compress (https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html#function_compress) to store the fetched email-attachments in the database to reduce the size of the database.

Why I’m hesitating is, that most attachments are already compressed (like jpg). The other reason is that I couldn’t find anything about the efficence of the build-in compression-algo of MySql.

Answer 1

Given the additional information that you’ve given, it seems that (a) you don’t need to be able to search files, just retrieve them and (b) your DB is limited to 1GB. I would recommend that rather than storing the files in the DB at all, you simply store a ‘key’ to the file, which is probably just a unique filename.

In your database you can store the original user filename but write the attachment(s) to a filestore with a unique identifier (it could even be just a column ID or you could create a proper GUID.

This will keep your database small, and retrieving attachments from file will not take any longer than retrieving them from the DB. When you write the file back out on retrieval, pass the original filename rather than your renamed and unique one.

If you are expecting a lot of files then you could shard storage across directories so that they don’t get too large and eventually you could span across file systems if you needed.

If 1GB is the limit for both the DB and your storage then of course this probably doesn’t help a lot. In that case, yes you should compress the files, but as you’re already aware, you may not get a very good compression ratio on files that are already in a compressed format.

One final point in favour of keeping the files outside of the database is that it could help to keep the DB lean, and therefore faster for backup/restore or migration activity.