BLOBs are variable length (at least in MySQL, blob storage requirements
). There are also MEDIUMBLOBs which hold up to 16MB and LONGBLOBS which hold up to 4GB, all as variable length fields requiring at most 4 bytes more than the data to store the length of the data.
If you happen to be fortunate to have a hosting account with MySQL v4.1.1 or greater you might be able to use the (de)compress() function
to (de)compress the data on the fly in MySQL. Or for that matter, you could just compress it using perl before inserting it in the table.
For searching, plucene is a really cool product but I've only used it in relatively small settings (i.e. indexes of under 30 MB). I've heard differing opinions
on plucene's speed so it my not be an acceptable option for your case. MySQL also offers full-text searching
functionality since v3.23.23 but that would prevent you from doing compression of the data.
As another alternative, I recently heard of another effort (still in alpha) that was inspired by Plucene but with the goal of overcoming Plucene's performance problems. It's called Kinosearch
. I have no actual experience with it but it appears to be promising (I'd be interested in hearing from anyone else that's actually used it).