[Catalyst] Hypothetical Site and Scalability Planning

[Brian Kirkbride]

  wrote:
> At 21:58 2007-10-26, Mesdaq, Ali wrote:
>> I personally think that storing images in the DB is the best place to
>> start because if other better solutions are available later you can very
>> easily migrate. But if you start out with filesystem migration is a
>> little bit more cludgy in my opinion. I mean you have to go traverse
>> directories and copy/move/delete or whatever you have to do for the
>> migration.
> 
> I haven't tried serving images or large objects from a database this 
> way, but wouldn't reading this data totally blow the db cache for the 
> rest of the things the database needs to do? At least it's something I'd 
> investigate and create spike solutions for before deploying. It sounds 
> very much vendor and/or configuration dependent, so off to the manuals :)
> 
> One thing that could work though, letting each component do what it's 
> best at, is to let the db store and _manage_ the media assets, but to 
> write them to disk on first access (and clear out unused files in a 
> cache-like way) and let the web server _serve_ them efficiently.
> 
> 
> /J

If putting large media files in the DB is really helpful to you in 
managing / replicating your data, you definitely do want to cache in a 
filesystem to serve directly via a "dumb" webserver process.  Then 
it's up to your application to invalidate those cached files on update.

In my case, I've found that Apache's mod_rewrite using a -f 
RewriteCond is your friend here.  Just test for the file in a cache/ 
directory and serve it.  If not, fall through to Catalyst App and then 
save the file off in your end() action.